Bizzare host re-write in JAX-WS client on JB6

[borfnorton22]

We recent upgraded from Jboss 4.22 to Jboss 6.

The code I am describing below works fine on 4.2.2.

a) We have a JAX-WS generated client

b) The generated client code is configured to talk to a remote webservice and it calls a method on it as follows.

URL url = new URL("http://bass01.stage.fishing89k41.com:80/Netter/NetterSyncQ.nsf/NetterWS?OpenWebService?WSDL");
NetterService netterService = new NetterService(url);
netterService.getNetterServicePort().isNetAvailable("someNetName");

The remote web-services WSDL exposes its service endpoint address as follows:

<service name="NetterService">
<port binding="impl:NetterServicePortSoapBinding" name="NetterServicePort">
<wsdlsoap:address location="http://bass01.stage.fishing89k41.com:80/Netter/NetterSyncQ.nsf/NetterWS?OpenWebService"/>
</port>
</service>

c) When this is running on Jboss 4.2.2 it works fine and has for quite some time. When the code executes on our JB6 server we see this is the logs which is absolutely bizzarre! Something in JB6 (cxf AddressRewritingEndpointInfo) is re-writing the hostname portion of the endpoint out client needs to talk to to a different host. This totally fails as when it trys to make a call we get a 404. Help! as we are sort of screwed.

11:02:38,377 INFO  [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] Creating Service {urn:DefaultNamespace}NetterService from WSDL: http://bass01.stage.fishing89k41.com:80/Netter/NetterSyncQ.nsf/NetterWS?OpenWebService?WSDL

11:02:38,378 INFO  [org.jboss.wsf.stack.cxf.transport.AddressRewritingEndpointInfo] Setting new service endpoint address in wsdl: http://ws-stage.fishing89k41.com/Netter/NetterSyncQ.nsf/NetterWS   

11:02:38,394 INFO  [org.jboss.wsf.stack.cxf.transport.AddressRewritingEndpointInfo] Setting new service endpoint address in wsdl: http://ws-stage.fishing89k41.com/Netter/NetterSyncQ.nsf/NetterWS   

11:02:38,406 WARN  [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor for {urn:DefaultNamespace}NetterService#{urn:DefaultNamespace}isNetAvailable has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: Could not send Message.
        at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64) [:2.3.1]
        at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255) [:2.3.1]
        at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516) [:2.3.1]
        at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313) [:2.3.1]
        at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265) [:2.3.1]
        at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) [:2.3.1]
        at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124) [:2.3.1]
        at $Proxy302.isNetAvailable(Unknown Source)   at some.service.SomeService.

[borfnorton22]

We found this file: deployers/jbossws.deployer/META-INF/stack-agnostic-jboss-beans.xml

and turned this OFF (rewrite to false)

<property name="modifySOAPAddress">false</property>

Once we did this the above rewrite went away, however isn't this a bug?? The documentation @ http://community.jboss.org/wiki/JBossWS-UserGuide under (Address Rewrite). It states this configuration is for deployed services. This is not a deployed service but a ws client. We are seeing this do rewrites for endpoints defined in remotely retrieved WSDLS for WebServiceClient code.....as shown above.

Are we missing something here???

[asoldano]

Yes, this is likely a bug, I'm analizying it too right now.

Can you please share more info on your client? is is called by class that in turn is a ws endpoint or in any way run inside a ws endpoint? I suspect some kind of issue related to the Apache CXF thread local bus association.

[borfnorton22]

Yes the client is itself (albiet in a different class) is in the thead of execution that was started by a WS endpoint on the jboss server executing it.

Posted a issue @ https://issues.jboss.org/browse/JBAS-9166

[benze]

I'm having the same issue with JBoss 7.0.2 Final.  Any way to determine which version of the CXF stack that JBoss 7.0.2 Final was shipped with?

Thanks,

Eric

[asoldano]

The JBossWS-CXF version is printed on the console during the boot. You can however check the version of the components by looking into the modules dir of the AS. org/apache/cxf/main has the Apache CXF libs, org/jboss/ws/** has the JBossWS(-CXF) libs.