How @WebServiceRef injection works with multiple @WebEndpoint

[grossetieg]

Hi,

I know this is a edge case but we are experiencing "random" behavior when using multiple @WebEndpoint (with the same class).

WebService client :

@WebServiceClient
public class TestEndpointService extends Service {

  // ....

 @WebEndpoint(name = "TestEndpointPort")
 public TestEndpoint getTestEndpointPort() {
   return (TestEndpoint) super.getPort("TestEndpointPort", TestEndpoint.class);
 }


  @WebEndpoint(name = "TestEndpointPort12")
  public TestEndpoint getTestEndpointPort() {
    return (TestEndpoint) super.getPort("TestEndpointPort12", TestEndpoint.class);
  }
}

TestEndpointPort stands for SOAP/HTTP 1.1

TestEndpointPort12 stands for SOAP/HTTP 1.2

Injection :

@WebServiceRef(TestEndpointService.class)
private TestEndpoint testEndpoint;

Recently the second @WebEnpoint was injected instead of the first (we noticed because the port name was wrong and the call failed) but we don't have a rational explanation.

I know that we need to remove one method or to specify which port the container should use but I'm curious, how the container resolves this situation ? Is this resolved at runtime ? at deployment time ?

We are using JBoss EAP 6.2.0.

Thanks,

Guillaume.

[asoldano]

Hi Guillaume,

generally speaking, the resolution might be simply not deterministic if you do not specify the require port QName in the web service ref metadata. The ws stack has no way to know which wsdl port you actually need and hence picks the first obtained method returned when introspecting the service class through reflection.

You could specify a port-component-ref block in your jboss-web.xml and set the port qname in there... but unfortunately there's a bug preventing that to work; I've just filled in the jira and committed a fix upstream: [JBWS-3798] @WebEndpoint name not considered when building up webservicerefs - JBoss Issue Tracker . There's also a testcase addition you might want to have a look to see how to see how to set the port-component-ref.

The simplest solution / workaround for you now is to avoid having those two methods at the same time in the service class.

Thanks for having reported the issue, I appreciate that!

[grossetieg]

Hi Alessio,

Thanks for your detailed reply.

We removed the duplicate declaration and it's all good now