11 Replies Latest reply on Jun 8, 2011 6:26 AM by asoldano

    Problem with faults and classloaders in AS7

    adinn

      I managed to run some of the XTS tests in AS7 and basic JaxWS calls work ok. However, I ran into problems with tests which threw a SOAPFault. The fault manifested with an error on the client side which was caused by a classloader load failure. The server side ran ok, probably because of how I was deploying my endpoint implementation and the underlying classes which it employs. However, a subsequent experiment with  the JBossWS example in the AS7 demos directory shows that there are other classloader issues on the server side.

       

      My test code is deployed as an ear which contains a war and several jars located in the ear lib. The test code makes a call to one of the XTS services using a request-reply JaxWS invocation. In some of the scenarios the server throws a javax.xml.ws.soap.SOAPFaultException.

       

      00:40:19,294 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (http--127.0.0.1-8080-3) Application {http://docs.oasis-open.org/ws-tx/wscoor/2006/06}ActivationService#{http://docs.oasis-open.org/ws-tx/wscoor/2006/06}CreateCoordinationContextOperation has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault: Sender
          at org.jboss.wsf.stack.cxf.AbstractInvoker.createFault(AbstractInvoker.java:225)
          at org.jboss.wsf.stack.cxf.AbstractInvoker._invokeInternal(AbstractInvoker.java:189)
          at org.jboss.wsf.stack.cxf.AbstractInvoker.invoke(AbstractInvoker.java:117)
          at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
          at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_21]
          at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_21]
          at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_21]
          at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
          at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106)
          at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
          at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:118)
          at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:208)
          at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:88)
          at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:159)
          at org.jboss.wsf.stack.cxf.CXFNonSpringServletExt.invoke(CXFNonSpringServletExt.java:86)
          at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:184)
          at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:107)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
          at org.jboss.wsf.stack.cxf.CXFNonSpringServletExt.service(CXFNonSpringServletExt.java:134)
          at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:138) [jbossws-spi-2.0.0.Beta2.jar:2.0.0.Beta2]
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285)
          at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261)
          at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.Beta4-SNAPSHOT.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:658) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
      Caused by: javax.xml.ws.soap.SOAPFaultException: Sender
          at com.arjuna.wsc11.messaging.ActivationCoordinatorProcessorImpl.createCoordinationContext(ActivationCoordinatorProcessorImpl.java:104) [ws-c11.jar:]
          at com.arjuna.webservices11.wscoor.sei.ActivationPortTypeImpl.createCoordinationContextOperation(ActivationPortTypeImpl.java:51) [classes:]
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_21]
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_21]
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_21]
          at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_21]
          at org.jboss.ws.common.invocation.AbstractInvocationHandlerJSE.invoke(AbstractInvocationHandlerJSE.java:108)
          at org.jboss.wsf.stack.cxf.AbstractInvoker._invokeInternal(AbstractInvoker.java:169)
          ... 34 more
      

       

      The XTS service endpoint implementation class, ActivationPortTypeImpl, is deployed in a war which explicitly imports various modules via it's manifets Dependencies property:

       

      Dependencies: org.jboss.jts,org.jboss.ws.api,javax.xml.ws.api,org.jboss.xts

       

      The class which creates and throws the exception, ActivationCoordinatorProcessorImpl, is exposed via a module (this is simulating the conditons for when XTS is actually embedded into AS7) which also includes various ws-related dependencies:

       

          <dependencies>
              <module name="org.jboss.jts"/>
              <module name="org.jboss.ws.api"/>
              <module name="org.jboss.logging"/>
              <module name="javax.xml.soap.api"/>
              <module name="javax.xml.ws.api"/>
              <module name="javax.xml.stream.api"/>
              <!-- this is needed to get javax.xml.namespace.QName but it woudl be better if it were exposed on its own -->
              <module name="javax.api"/>
              <!-- this is needed because our endpoints are not in a normal deployment and we need to be able
                  to resolve the javax.jws.WebService annotation attached to them. presumably an endpoint
                  found in a deployment gets this package auto-added to its module loader
                  -->
              <module name="javax.jws.api"/>
          </dependencies>
      
      

       

      When the service throws a fault it appears to be handled ok by JBossWS andeventuallty gets propagated back to the client side through the http back channel (this is not the case for the other test I mentioned but we will come to that later).  However, the client does not manage to deserialize and process the incoming fault. It throws an exception as follows:

       

      00:40:19,318 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (JUnit Runner Thread) Interceptor for {http://docs.oasis-open.org/ws-tx/wscoor/2006/06}ActivationService#{http://docs.oasis-open.org/ws-tx/wscoor/2006/06}CreateCoordinationContextOperation has thrown exception, unwinding now: java.lang.RuntimeException: XPathFactory#newInstance() failed to create an XPathFactory for the default object model: http://java.sun.com/jaxp/xpath/dom with the XPathFactoryConfigurationException: javax.xml.xpath.XPathFactoryConfigurationException: No XPathFactory implementation found for the object model: http://java.sun.com/jaxp/xpath/dom
          at javax.xml.xpath.XPathFactory.newInstance(XPathFactory.java:101) [:1.6.0_21]
          at org.apache.cxf.helpers.XPathUtils.<init>(XPathUtils.java:37)
          at org.apache.cxf.helpers.XPathUtils.<init>(XPathUtils.java:41)
          at org.apache.cxf.interceptor.ClientFaultConverter.setStackTrace(ClientFaultConverter.java:237)
          at org.apache.cxf.interceptor.ClientFaultConverter.handleMessage(ClientFaultConverter.java:81)
          at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
          at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:104)
          at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69)
          at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34)
          at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
          at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:736)
          at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1563)
          at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1448)
          at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1356)
          at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
          at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:614)
          at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
          at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
          at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:484)
          at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:414)
          at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:317)
          at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:269)
          at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
          at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
          at $Proxy95.createCoordinationContextOperation(Unknown Source)    at com.arjuna.webservices11.wscoor.client.ActivationCoordinatorClient.sendCreateCoordination(ActivationCoordinatorClient.java:85) [ws-c11.jar:]
          at com.arjuna.wsc11.ActivationCoordinator.createCoordinationContext(ActivationCoordinator.java:77) [ws-c11.jar:]
          at com.arjuna.wsc11.tests.junit.ActivationServiceTestCase.testUnknownCoordinationType(ActivationServiceTestCase.java:71) [classes:]
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_21]
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_21]
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_21]
          at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_21]
          at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit-4.8.2.jar:]
          at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit-4.8.2.jar:]
          at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit-4.8.2.jar:]
          at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit-4.8.2.jar:]
          at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79) [junit-4.8.2.jar:]
          at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71) [junit-4.8.2.jar:]
          at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49) [junit-4.8.2.jar:]
          at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) [junit-4.8.2.jar:]
          at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) [junit-4.8.2.jar:]
          at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) [junit-4.8.2.jar:]
          at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) [junit-4.8.2.jar:]
          at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) [junit-4.8.2.jar:]
          at org.junit.runners.ParentRunner.run(ParentRunner.java:236) [junit-4.8.2.jar:]
          at org.junit.runners.Suite.runChild(Suite.java:128) [junit-4.8.2.jar:]
          at org.junit.runners.Suite.runChild(Suite.java:24) [junit-4.8.2.jar:]
          at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) [junit-4.8.2.jar:]
          at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) [junit-4.8.2.jar:]
          at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) [junit-4.8.2.jar:]
          at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) [junit-4.8.2.jar:]
          at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) [junit-4.8.2.jar:]
          at org.junit.runners.ParentRunner.run(ParentRunner.java:236) [junit-4.8.2.jar:]
          at org.junit.runners.Suite.runChild(Suite.java:128) [junit-4.8.2.jar:]
          at org.junit.runners.Suite.runChild(Suite.java:24) [junit-4.8.2.jar:]
          at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) [junit-4.8.2.jar:]
          at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) [junit-4.8.2.jar:]
          at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) [junit-4.8.2.jar:]
          at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) [junit-4.8.2.jar:]
          at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) [junit-4.8.2.jar:]
          at org.junit.runners.ParentRunner.run(ParentRunner.java:236) [junit-4.8.2.jar:]
          at org.junit.runner.JUnitCore.run(JUnitCore.java:157) [junit-4.8.2.jar:]
          at org.junit.runner.JUnitCore.run(JUnitCore.java:136) [junit-4.8.2.jar:]
          at org.junit.runner.JUnitCore.run(JUnitCore.java:117) [junit-4.8.2.jar:]
          at com.arjuna.qa.junit.TestRunnerServlet$RunnerThread.run(TestRunnerServlet.java:523) [xts-test-servlet.jar:]
      

       

      Note that both the client ear and the client war specify the following dependencies in their manifest:

       

      Dependencies: org.jboss.jts,org.jboss.ws.api,javax.xml.ws.api,org.jboss.xts,org.dom4j,org.junit

       

      I debugged this in the debugger and found that the call to XPathFactory.newInstance was failing because the module classloader used when trying to load the factory was failing to find a factory implementation. It tries to locate various resources which might define an implementation class and, when they don't turn up, calls loadclass with the hard wired class name com.sun.org.apache.xpath.internal.jaxp.XPathFactoryImpl. This fails, causing the error.

       

      The classloader used when trying all this mullarkey is the loader for the client war embedded in the ear -- the name is "ModuleClassLoader for Module "deployment.ws-c-tests.ear.ws-c11-tests.war:main" from Service Module Loader". I assume the problem is happening because the war loader is failing to find either a resource to redirect the XPathFactory class load or failing to find the hard-wired XPathFactory implementation class. Is this a failure to auto-inject some necessary WS dependencies?

       

      Anyway, in order to provide a simple test case I decided I would try to modify the ws example in the AS7 demo directory to throw a fault. However, when I ran the example I got  errors on the server side even without modification.

       

      06:49:20,677 INFO  [org.jboss.as.demos.ws.archive.SimpleServlet] (http--127.0.0.1-8080-2) Received request
      06:49:20,685 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/ws-example].[SimpleServlet]] (http--127.0.0.1-8080-2) Servlet.service() for servlet SimpleServlet threw exception: java.lang.ClassNotFoundException: org.jboss.wsf.stack.cxf.client.serviceref.CXFServiceObjectFactoryJAXWS from [Module "org.jboss.as.webservices:main" from local module loader @3d3e58d4 (roots: /home/adinn/jboss/jbossas/git/jboss-as/build/target/jboss-7.0.0.Beta4-SNAPSHOT/modules)]
          at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:188) [:1.0.0.CR3-SNAPSHOT]
          at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358) [:1.0.0.CR3-SNAPSHOT]
          at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330) [:1.0.0.CR3-SNAPSHOT]
          at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307) [:1.0.0.CR3-SNAPSHOT]
          at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101) [:1.0.0.CR3-SNAPSHOT]
          at org.jboss.as.webservices.deployers.WebServiceRefAnnotationParsingProcessor$WebServiceRefValueSource.getValue(WebServiceRefAnnotationParsingProcessor.java:259)
          at org.jboss.as.naming.ValueManagedReferenceFactory$1.getInstance(ValueManagedReferenceFactory.java:63) [jboss-as-naming-7.0.0.Beta4-SNAPSHOT.jar:7.0.0.Beta4-SNAPSHOT]
          at org.jboss.as.ee.component.ManagedReferenceMethodInjectionInterceptor.processInvocation(ManagedReferenceMethodInjectionInterceptor.java:72)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
          at org.jboss.as.ee.component.ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptor.java:53)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
          at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
          at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:63)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
          at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
          at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
          at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:156)
          at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:79)
          at org.jboss.as.ejb3.component.stateless.StatelessSessionComponent$1.create(StatelessSessionComponent.java:62)
          at org.jboss.as.ejb3.component.stateless.StatelessSessionComponent$1.create(StatelessSessionComponent.java:59)
          at org.jboss.ejb3.pool.AbstractPool.create(AbstractPool.java:65)
          at org.jboss.ejb3.pool.strictmax.StrictMaxPool.get(StrictMaxPool.java:145)
          at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:48)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
          at org.jboss.as.ejb3.component.session.ComponentTypeIdentityInterceptorFactory$ProxyTypeEqualsInterceptor.processInvocation(ComponentTypeIdentityInterceptorFactory.java:71)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
          at org.jboss.as.ejb3.component.session.ComponentTypeIdentityInterceptorFactory$ProxyTypeEqualsInterceptor.processInvocation(ComponentTypeIdentityInterceptorFactory.java:71)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
          at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
          at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
          at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
          at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
          at org.jboss.as.demos.ws.archive.SimpleStatelessSessionLocal$$$view1.echo(Unknown Source)
          at org.jboss.as.demos.ws.archive.SimpleServlet.doGet(SimpleServlet.java:59) [classes:]
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285)
          at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261)
          at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.Beta4-SNAPSHOT.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:658) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
      
      06:49:22,383 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (http--127.0.0.1-8080-2) Interceptor for {http://archive.ws.demos.as.jboss.org/}EndpointService has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault: Error reading XMLStreamReader.
          at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:237)
          at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:60)
          at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
          at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:118)
          at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:208)
          at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:88)
          at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:159)
          at org.jboss.wsf.stack.cxf.CXFNonSpringServletExt.invoke(CXFNonSpringServletExt.java:86)
          at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:184)
          at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:107)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
          at org.jboss.wsf.stack.cxf.CXFNonSpringServletExt.service(CXFNonSpringServletExt.java:134)
          at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:138) [jbossws-spi-2.0.0.Beta2.jar:2.0.0.Beta2]
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285)
          at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261)
          at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.Beta4-SNAPSHOT.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:658) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
          at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
      Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog
       at [row,col {unknown-source}]: [1,0]
          at com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOF(StreamScanner.java:677)
          at com.ctc.wstx.sr.BasicStreamReader.handleEOF(BasicStreamReader.java:2104)
          at com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2010)
          at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1102)
          at com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1125)
          at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:138)
          ... 28 more
      

       

      It looks like this is also a classloader configuration issue. I assume this used to work and has now been broken because of updates to WS?

        • 1. Re: Problem with faults and classloaders in AS7
          asoldano

          To sum up what we said on IRC, before going deep into details (sorry) here are some general suggestions regarding classloading in AS7 and WS:

          - take a look at http://community.jboss.org/wiki/JBossWS-AS7FAQ ; [to other readers: while some entries there might seem trivial, pretty much everything in there can help to avoid going crazy with classloading issue]

          - consider setting dependencies on org.jboss.ws.jaxws-client or org.jboss.ws.cxf.jbossws-cxf-client to get all the ws stuff

          - remember the "services" option when setting dependencies; as a rule of thumb, if the jars in the module you're setting a dependency to do contain stuff in META-INF/services (and/or export modules dependencies for which the same applies), you need that option unless you really know what you're doing and want to control the ServiceLoader behaviour in a custom way

          • 2. Re: Problem with faults and classloaders in AS7
            asoldano

            Ah, the serviceref error in the AS7 demo is expected, feature not completed yet.

            • 3. Re: Problem with faults and classloaders in AS7
              adinn

              Hi Alessio,

               

              I tried including both 'org.jboss.ws.jaxws-client services export' and 'org.jboss.ws.cxf.jbossws-cxf-client services export' in the dependences list but neither resolved the problem I had on the client side. When I looke dfurther into ti I realised that there is no service.xml override for the XPathFactory in the jbossws and cxf jars. The client fault handling code relies upon loading the hardwired fallback implementation class, com.sun..org.apache.xpath.internal.jaxp/XPathFactory, which is in rt.jar. This means that one of the jbossws or cxf modules needs to inport and then re-export it. I patched myrelease by adding the following to the dependencies set in module.xml file in modules/org/jboss/ws/jbossws-cxf-client/main

               

                      <module name="system" export="false">
                          <imports>
                              <include-set>
                                  <path name="com/sun/org/apache/xpath/internal/jaxp"/>
                              </include-set>
                          </imports>
                          <exports>
                              <include-set>
                                  <path name="com/sun/org/apache/xpath/internal/jaxp"/>
                              </include-set>
                          </exports>
                      </module>
              

               

              This ensures that ClientFaultConverter can see the hard-wired XPathFactory implementation.

               

              This now means that all the XTS unit tests are running correctly which is great. I still have to get the XTS interop tests (our client against our server) and XTS demo to work but it's looking very good so far so I'm hoping they will present no further hurdles.

              • 4. Re: Problem with faults and classloaders in AS7
                adinn

                I found another glitch in the XTS interop demo which is als a package problem but it was masked by not seeing an exception on the client side. The interop tests creates a JaxWS proxy for the test Participant service which drives XTS and then asks it to run a test. In some cases it passes transaction details using a handler to serialise them into the message. My handler was failing with an NPE but the client proxy did not receive any exception. Is this normal behaviour?

                 

                The NPE was because the handler failes to create a JaxB context - the call is JAXBContext.newInstance(pkgname); The call throws an exception whose detail message is "Provider com.sun.xml.internal.bind.v2.ContextFactory not found" I assume this is because of a service lookup problem. I'll see if I can work out thow to fix this.

                • 5. Re: Problem with faults and classloaders in AS7
                  asoldano

                  Hi Andrew,

                  Andrew Dinn wrote:

                   

                  Hi Alessio,

                   

                  I tried including both 'org.jboss.ws.jaxws-client services export' and 'org.jboss.ws.cxf.jbossws-cxf-client services export' in the dependences list but neither resolved the problem I had on the client side. When I looke dfurther into ti I realised that there is no service.xml override for the XPathFactory in the jbossws and cxf jars. The client fault handling code relies upon loading the hardwired fallback implementation class, com.sun..org.apache.xpath.internal.jaxp/XPathFactory, which is in rt.jar. This means that one of the jbossws or cxf modules needs to inport and then re-export it. I patched myrelease by adding the following to the dependencies set in module.xml file in modules/org/jboss/ws/jbossws-cxf-client/main

                   

                          <module name="system" export="false">
                              <imports>
                                  <include-set>
                                      <path name="com/sun/org/apache/xpath/internal/jaxp"/>
                                  </include-set>
                              </imports>
                              <exports>
                                  <include-set>
                                      <path name="com/sun/org/apache/xpath/internal/jaxp"/>
                                  </include-set>
                              </exports>
                          </module>
                  

                   

                  This ensures that ClientFaultConverter can see the hard-wired XPathFactory implementation.

                   

                  OK, so th CXF XPathUtils needs to see a XPathFactory implementation. I have two concerns regarding your proposed solution:

                  • I don't think it's correct to force the default impl; afaik we do have custom implementation from Xalan module; btw there should be a javax.xml.jaxp-provider module in AS7 for this. Can you try setting the dependency on that module and see if works too?
                  • I'm not really sure this dependency should live in the org.jboss.ws.cxf.jbossws-cxf-client module, as this seems quite a common need (any standard client might suffer from this problem, regardless of it using cxf/jbossws-cxf customizations or not). This is probably something for the org.jboss.ws.jaxws-client module, which is automatically loaded by the JAXWS Provider. On this topic, there's something I'd like to verify: you should be going through the org.jboss.wsf.stack.cxf.client.ProviderImpl implementation of JAXWS Provider when doing the call from client; that provider is supposed to set the TCCL in createServiceDelegate(..) so that it use or delegate as fallback to the modular classloader for org.jboss.ws.jaxws-client (that's why adding the dependency in there should be the solution for every client). Btw, this is required because the XPathUtils (as well as many other 3rd party code) relies on TCCL for loading stuff.
                  • 6. Re: Problem with faults and classloaders in AS7
                    asoldano

                    Andrew Dinn wrote:

                     

                    I found another glitch in the XTS interop demo which is als a package problem but it was masked by not seeing an exception on the client side. The interop tests creates a JaxWS proxy for the test Participant service which drives XTS and then asks it to run a test. In some cases it passes transaction details using a handler to serialise them into the message. My handler was failing with an NPE but the client proxy did not receive any exception. Is this normal behaviour?

                     

                    I don't think so, but I'd probably need to see more details / the code to better understand.

                     

                    The NPE was because the handler failes to create a JaxB context - the call is JAXBContext.newInstance(pkgname); The call throws an exception whose detail message is "Provider com.sun.xml.internal.bind.v2.ContextFactory not found" I assume this is because of a service lookup problem. I'll see if I can work out thow to fix this.

                    This looks like a problem with dependencies on a JAXB Impl module. Can you check what classloader is set as TCCL / is being used for resolution in JAXBContext.newInstance(..) when that's called by your handler? I guess a dependency on com.sun.xml.bind (with services=import) is missing somewhere.

                    • 7. Re: Problem with faults and classloaders in AS7
                      asoldano

                      Alessio Soldano wrote:

                       

                      This looks like a problem with dependencies on a JAXB Impl module. Can you check what classloader is set as TCCL / is being used for resolution in JAXBContext.newInstance(..) when that's called by your handler? I guess a dependency on com.sun.xml.bind (with services=import) is missing somewhere.

                      Btw I see that the org.jboss.ws.cxf.jbossws-cxf-client module has <module name="com.sun.xml.bind" services="import"/>, we might even evaluate to re-export the services declaration in there, so that users depending on that see them (<module name="com.sun.xml.bind" services="export"/>) without having to add another dependency.

                      • 8. Re: Problem with faults and classloaders in AS7
                        adinn

                        Hi Alessio,

                         

                        Just caught me before I disappear on holiday for 2 weeks :-)

                        Alessio Soldano wrote:


                        OK, so th CXF XPathUtils needs to see a XPathFactory implementation. I have two concerns regarding your proposed solution:
                        • I don't think it's correct to force the default impl; afaik we do have custom implementation from Xalan module; btw there should be a javax.xml.jaxp-provider module in AS7 for this. Can you try setting the dependency on that module and see if works too?
                        • I'm not really sure this dependency should live in the org.jboss.ws.cxf.jbossws-cxf-client module, as this seems quite a common need (any standard client might suffer from this problem, regardless of it using cxf/jbossws-cxf customizations or not). This is probably something for the org.jboss.ws.jaxws-client module, which is automatically loaded by the JAXWS Provider. On this topic, there's something I'd like to verify: you should be going through the org.jboss.wsf.stack.cxf.client.ProviderImpl implementation of JAXWS Provider when doing the call from client; that provider is supposed to set the TCCL in createServiceDelegate(..) so that it use or delegate as fallback to the modular classloader for org.jboss.ws.jaxws-client (that's why adding the dependency in there should be the solution for every client). Btw, this is required because the XPathUtils (as well as many other 3rd party code) relies on TCCL for loading stuff.

                         

                        I'm agnostic on the second point and tend to agree with you that jaxws-client probably ought to expose it. If you look at the (second) client-side exception trace in my first message you will see that ClientFaultConverter is tyingto load the XPathFactory when processing a reply under the proxy method invoke. I checked in the debugger and the class load was being done using the war classloader.

                         

                        As for point one, I don't tink my solution forces a specific load. It just allows the default, hard-wired class to be visible in case no META-INF/services override is supplied. Anyway, if you can think of a better way to do this please feel free to implement it. I was just trying to make sure my tests ran so I could see if there were any bugs in the pipeline before I disappeared :-)

                        • 9. Re: Problem with faults and classloaders in AS7
                          adinn

                          Alessio Soldano wrote:

                          Andrew Dinn wrote:

                           

                          I found another glitch in the XTS interop demo which is als a package problem but it was masked by not seeing an exception on the client side. The interop tests creates a JaxWS proxy for the test Participant service which drives XTS and then asks it to run a test. In some cases it passes transaction details using a handler to serialise them into the message. My handler was failing with an NPE but the client proxy did not receive any exception. Is this normal behaviour?

                           

                          I don't think so, but I'd probably need to see more details / the code to better understand.

                          Nothing much to see. It's a classic "I'll fix this later cock-up". Here's the code.

                           

                              public boolean handleMessage(SOAPMessageContext context) throws ProtocolException
                              {
                                  final boolean outbound = (Boolean)context.get(MessageContext.MESSAGE_OUTBOUND_PROPERTY);
                                  if (outbound) {
                                      return handleMessageOutbound(context);
                                  } else {
                                      return handlemessageInbound(context);
                                  }
                              }
                          
                              protected boolean handleMessageOutbound(SOAPMessageContext context) throws ProtocolException
                              {
                                  try {
                                      CoordinationContextType coordinationContext = CoordinationContextManager.getThreadContext();
                                      if (coordinationContext != null) {
                                          final JAXBContext jaxbCtx = getJaxbContext();
                          
                                          // insert a header into the current message containing the coordination context
                                          final SOAPMessage soapMessage = context.getMessage();
                                          final SOAPEnvelope soapEnvelope = soapMessage.getSOAPPart().getEnvelope();
                                          SOAPHeader soapHeader = soapEnvelope.getHeader() ;
                                          if (soapHeader == null)
                                          {
                                              soapHeader = soapEnvelope.addHeader() ;
                                          }
                                          . . .
                                          SOAPHeaderElement headerElement = soapHeader.addHeaderElement(getDummyQName());
                                          Marshaller marshaller = jaxbCtx.createMarshaller();
                                          marshaller.marshal(coordinationContext, headerElement);
                                          . . .
                                      }
                          
                                  } catch (Exception se) {
                                      throw new ProtocolException(se);
                                  }
                          
                                  return true;
                              }
                          

                           

                          and here's the code which returns the null pointer

                           

                              private static JAXBContext jaxbContext;
                              private synchronized JAXBContext getJaxbContext()
                              {
                                  if (jaxbContext == null) {
                                      try {
                                          jaxbContext = JAXBContext.newInstance("org.oasis_open.docs.ws_tx.wscoor._2006._06");
                                      } catch (JAXBException e) {
                                          // TODO log error here
                                      }
                                  }
                          
                                  return jaxbContext;
                              }
                          

                           

                          I would have expected the ProtocolException to have resulted in an exception thrown from the client proxy method invocation but the proxy call just returned normally.

                           

                          Once again the classloader used to resollve the load under JAXBContext.newInstance was the war classloader. I worked round this by adding 'com.sun.xml.bind services export' to the dependencies in the war manifest.mf. However, I think it would be better if the modules which import it (both jaxws-client and jbossws-cxf-client) also exported it. It might be good if all the dependencies weer scrutinised to see whether they need re-exporting.

                          • 10. Re: Problem with faults and classloaders in AS7
                            asoldano

                            Following up even if you're now on holiday... at least we keep track of progressions

                            Andrew Dinn wrote:

                             

                            Hi Alessio,

                             

                            Just caught me before I disappear on holiday for 2 weeks :-)

                            Alessio Soldano wrote:


                            OK, so th CXF XPathUtils needs to see a XPathFactory implementation. I have two concerns regarding your proposed solution:
                            • I don't think it's correct to force the default impl; afaik we do have custom implementation from Xalan module; btw there should be a javax.xml.jaxp-provider module in AS7 for this. Can you try setting the dependency on that module and see if works too?
                            • I'm not really sure this dependency should live in the org.jboss.ws.cxf.jbossws-cxf-client module, as this seems quite a common need (any standard client might suffer from this problem, regardless of it using cxf/jbossws-cxf customizations or not). This is probably something for the org.jboss.ws.jaxws-client module, which is automatically loaded by the JAXWS Provider. On this topic, there's something I'd like to verify: you should be going through the org.jboss.wsf.stack.cxf.client.ProviderImpl implementation of JAXWS Provider when doing the call from client; that provider is supposed to set the TCCL in createServiceDelegate(..) so that it use or delegate as fallback to the modular classloader for org.jboss.ws.jaxws-client (that's why adding the dependency in there should be the solution for every client). Btw, this is required because the XPathUtils (as well as many other 3rd party code) relies on TCCL for loading stuff.

                             

                            I'm agnostic on the second point and tend to agree with you that jaxws-client probably ought to expose it. If you look at the (second) client-side exception trace in my first message you will see that ClientFaultConverter is tyingto load the XPathFactory when processing a reply under the proxy method invoke. I checked in the debugger and the class load was being done using the war classloader.

                             

                            As for point one, I don't tink my solution forces a specific load. It just allows the default, hard-wired class to be visible in case no META-INF/services override is supplied. Anyway, if you can think of a better way to do this please feel free to implement it. I was just trying to make sure my tests ran so I could see if there were any bugs in the pipeline before I disappeared :-)

                             

                            First of all, I created JBWS-3306 and modified another testcase to cover this usecase too; we didn't discover this issue before because the JBossWS testsuite did not have any client getting soap faults while running in-container (ie. under a modular classloader in AS7).

                             

                            I've been thinking a bit about the issue and basically came to the conclusion that the problem is not really a WS problem only. You should be able to successfully get an XPathFactory instance regardless of you being in a WS call or not. So, your fix should always apply, not added on a ws module. I've chatted a bit with David and Jason on #jboss-as7 IRC and it seems there's a glitch in the default fallback for that xpath factory (the jaxp stuff is treated in a special way in AS7 modules). So Jason is probably going to solve this.

                             

                            This said, a note on what I wrote regarding the ProviderImpl which is not correct; that's not valid here becase the provider is passed through when building the service delegate, but once that's done, the delegate (a ServiceImpl instance when CXF is being used) is back seeing the original TCCL when its getPort() is called; the TCCL is the loader for the deployment module (which is enriched by whatever dependency you declare for the deployment - org.jboss.ws.cxf.jbossws-cxf-client in your case).

                            • 11. Re: Problem with faults and classloaders in AS7
                              asoldano

                              Once again the classloader used to resollve the load under JAXBContext.newInstance was the war classloader. I worked round this by adding 'com.sun.xml.bind services export' to the dependencies in the war manifest.mf. However, I think it would be better if the modules which import it (both jaxws-client and jbossws-cxf-client) also exported it. It might be good if all the dependencies weer scrutinised to see whether they need re-exporting.

                               

                              https://issues.jboss.org/browse/JBWS-3309