[JBoss JIRA] (JBWS-3260) modifySOAPAddress = true ends up rewriting WSDLS for WebServiceClient code as well
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3260?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on JBWS-3260:
---------------------------------------
This should be fixed in 7.0.2.Final. If you have problems please either open a thread on the forum with some description or fill in a new jira with clear reproduction info. Thanks!
> 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?O...");
> 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?O..."/>
> </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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (JBWS-3260) modifySOAPAddress = true ends up rewriting WSDLS for WebServiceClient code as well
by Eric B (JIRA)
[ https://issues.jboss.org/browse/JBWS-3260?page=com.atlassian.jira.plugin.... ]
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?O...");
> 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?O..."/>
> </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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (JBWS-3490) Fix org.jboss.test.ws.jaxws.as3581.AS3581TestCase
by Alessio Soldano (JIRA)
Alessio Soldano created JBWS-3490:
-------------------------------------
Summary: Fix org.jboss.test.ws.jaxws.as3581.AS3581TestCase
Key: JBWS-3490
URL: https://issues.jboss.org/browse/JBWS-3490
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Reporter: Alessio Soldano
Assignee: Richard Opalka
Fix For: jbossws-cxf-4.1
The org.jboss.test.ws.jaxws.as3581.AS3581TestCase shows intermittent failures on Hudson. The reason is likely that the test first call a @Oneway method to have a static class member initialized with a given value and the it invokes a req-res method on another endpoint to get the current value of the previously initialized static member. The problem is likely that the member initialization might have not been completed by the time the req-res invocation is performed, given the first invocation is basically fire & forget being @Oneway.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (JBWS-3507) Investigate WSTrustTestCase regression
by Richard Opalka (JIRA)
Richard Opalka created JBWS-3507:
------------------------------------
Summary: Investigate WSTrustTestCase regression
Key: JBWS-3507
URL: https://issues.jboss.org/browse/JBWS-3507
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Reporter: Richard Opalka
Assignee: Alessio Soldano
Fix For: jbossws-cxf-4.1.0.Beta1
After WSS4J upgrade from 1.6.5 to 1.6.6 the CXF integration
test **/jaxws/samples/wsse/policy/trust/WSTrustTestCase
started to fail :(
---
10:47:09,123 WARNING [org.apache.cxf.sts.token.provider.SAMLTokenProvider] (http-localhost/127.0.0.1:8080-47) : java.lang.IllegalArgumentException: InputStream cannot be null
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:120) [rt.jar:1.6.0_32]
at org.opensaml.xml.parse.BasicParserPool$DocumentBuilderProxy.parse(BasicParserPool.java:671)
at org.opensaml.xml.parse.BasicParserPool.parse(BasicParserPool.java:215)
at org.opensaml.xml.XMLConfigurator.load(XMLConfigurator.java:141)
at org.opensaml.DefaultBootstrap.initializeXMLTooling(DefaultBootstrap.java:199)
at org.apache.ws.security.saml.ext.OpenSAMLBootstrap.bootstrap(OpenSAMLBootstrap.java:77) [wss4j.jar:1.6.6]
at org.apache.ws.security.saml.ext.OpenSAMLUtil.initSamlEngine(OpenSAMLUtil.java:61) [wss4j.jar:1.6.6]
at org.apache.ws.security.saml.ext.AssertionWrapper.<init>(AssertionWrapper.java:214) [wss4j.jar:1.6.6]
at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createSamlToken(SAMLTokenProvider.java:328) [cxf-services-sts-core.jar:]
at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createToken(SAMLTokenProvider.java:126) [cxf-services-sts-core.jar:]
at org.apache.cxf.sts.operation.TokenIssueOperation.issueSingle(TokenIssueOperation.java:145) [cxf-services-sts-core.jar:]
at org.apache.cxf.sts.operation.TokenIssueOperation.issue(TokenIssueOperation.java:70) [cxf-services-sts-core.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_32]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_32]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_32]
at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_32]
at org.apache.cxf.ws.security.sts.provider.SecurityTokenServiceProvider.invoke(SecurityTokenServiceProvider.java:227) [cxf-rt-ws-security.jar:2.6.1]
at org.apache.cxf.ws.security.sts.provider.SecurityTokenServiceProvider.invoke(SecurityTokenServiceProvider.java:60) [cxf-rt-ws-security.jar:2.6.1]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_32]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_32]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_32]
at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_32]
at org.jboss.ws.common.invocation.AbstractInvocationHandlerJSE.invoke(AbstractInvocationHandlerJSE.java:111)
at org.jboss.wsf.stack.cxf.JBossWSInvoker._invokeInternal(JBossWSInvoker.java:181)
at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:127)
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58) [cxf-api.jar:2.6.1]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_32]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_32]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_32]
at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) [cxf-api.jar:2.6.1]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:107) [cxf-api.jar:2.6.1]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) [cxf-api.jar:2.6.1]
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:122) [cxf-api.jar:2.6.1]
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:211) [cxf-rt-transports-http.jar:2.6.1]
at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:91)
at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:169)
at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:187) [cxf-rt-transports-http.jar:2.6.1]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:110) [cxf-rt-transports-http.jar:2.6.1]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:135)
at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi.jar:2.1.0-SNAPSHOT]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.16.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.16.Final.jar:]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.16.Final.jar:]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.16.Final.jar:]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.16.Final.jar:]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final.jar:]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final.jar:]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final.jar:]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.16.Final.jar:]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.16.Final.jar:]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final.jar:]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_32]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months