Andrew Dinn [http://community.jboss.org/people/adinn] created the discussion "Re: Problem with faults and classloaders in AS7" To view the discussion, visit: http://community.jboss.org/message/608448#608448 -------------------------------------------------------------- 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. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/608448#608448] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Alessio Soldano [http://community.jboss.org/people/asoldano] created the discussion "Re: Problem with faults and classloaders in AS7" To view the discussion, visit: http://community.jboss.org/message/608482#608482 -------------------------------------------------------------- I don't think so, but I'd probably need to see more details / the code to better understand. 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. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/608482#608482] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Andrew Dinn [http://community.jboss.org/people/adinn] created the discussion "Re: Problem with faults and classloaders in AS7" To view the discussion, visit: http://community.jboss.org/message/608493#608493 -------------------------------------------------------------- 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. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/608493#608493] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Alessio Soldano [http://community.jboss.org/people/asoldano] created the discussion "Re: Problem with faults and classloaders in AS7" To view the discussion, visit: http://community.jboss.org/message/608480#608480 -------------------------------------------------------------- Hi Andrew, 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. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/608480#608480] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Alessio Soldano [http://community.jboss.org/people/asoldano] created the discussion "Re: Problem with faults and classloaders in AS7" To view the discussion, visit: http://community.jboss.org/message/608553#608553 -------------------------------------------------------------- Following up even if you're now on holiday... at least we keep track of progressions First of all, I created https://issues.jboss.org/browse/JBWS-3306 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). -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/608553#608553] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]