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).