]
Eric B commented on JBWS-3260:
------------------------------
I'm running into a similar problem with JBoss 7.0.2. Is this still a bug?
modifySOAPAddress = true ends up rewriting WSDLS for WebServiceClient
code as well
----------------------------------------------------------------------------------
Key: JBWS-3260
URL:
https://issues.jboss.org/browse/JBWS-3260
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: jbossws-cxf
Environment: Linux x64, Java 6
Reporter: borfnorton22 borfnorton22
Assignee: Alessio Soldano
Fix For: jbossws-cxf-4.0.0.Beta1
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.
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?O...
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.
We edited 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.
@ see
http://community.jboss.org/thread/164507
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: