This issue is related to RESTEASY-1132.
There are 2 servers that have some shared components. One of components implements interface Manager:
The interface is implemented by class ManagerImpl. This class is a Spring bean and annotated with @Path (via interface) and therefore is exposed as REST service by SpringBeanProcessor.
But 2 mentioned servers have be able to connect to Manger of each other.
We are using RestClient for this. This is the reason that JAX-RS annotations are written on interface instead of class.
The application is Spring based and it is very convenient to create REST clients as beans:
This causes ambiguity. There are 2 beans that implement the same interface Manager. They can be distinguished using qualifier (see @Remote qualifier used to mark rest client bean. But both beans are also marked using annotation @Path and therefore are exposed as REST service. When REST request is being processed both beans match and there is a chance that the request will be routed to the client that may cause unexpected result. In our case the system remained blocked on read() of SocketInputStrem.
This issue relates to RESTEASY-1132 that I also created but is not duplicate. RESTEASY-1132 asks to prevent exposing ambiguous beans as a REST web server. Current issue asks to ignore beans that indeed implement interface marked as @Path but in fact are rest client proxies.
I found a work around that worked for me. I remove annotation @Path from interface and modified @Path on methods to refer to full path:
Then I marked ManagerImpl with @Path annotation:
So, the rest clients are not marked by @Path and therefore ignored by SpringBeanProcessor, ManagerImpl is exposed as REST API and rest client works correctly because full path is written in @Path annotations that annotate methods.
However IMHO the framework should do this service for me automatically.