9:09 a.m.
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/608323#608323
--------------------------------------------------------------
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/docs/DOC-16722
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
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/608323#608323]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
9:10 a.m.
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/608325#608325
--------------------------------------------------------------
Ah, the serviceref error in the AS7 demo is expected, feature not completed yet.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/608325#608325]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
11:04 p.m.
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&...]
1:27 a.m.
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/608459#608459
--------------------------------------------------------------
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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/608459#608459]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
3:40 a.m.
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,
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.
--------------------------------------------------------------
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&...]
3:44 a.m.
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
--------------------------------------------------------------
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.
--------------------------------------------------------------
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&...]
3:46 a.m.
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/608483#608483
--------------------------------------------------------------
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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/608483#608483]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
4:05 a.m.
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/608487#608487
--------------------------------------------------------------
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 :-)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/608487#608487]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
4:26 a.m.
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
--------------------------------------------------------------
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.
--------------------------------------------------------------
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&...]
12:15 p.m.
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
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 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&...]
5:26 a.m.
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/609161#609161
--------------------------------------------------------------
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 https://issues.jboss.org/browse/JBWS-3309
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/609161#609161]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
4731
days inactive
4737
days old
jboss-dev-forums@lists.jboss.org
10 comments
2 participants
participants (2)
-
Alessio Soldano -
Andrew Dinn