Millies, Sebastian wrote:
The stack trace suggests it happens on the client side:
Exception in thread "main" java.lang.ExceptionInInitializerError
at
com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:107)
at
com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
at $Proxy31.getExchangeRate(Unknown Source)
at
scatours.CurrencyConverterWSClient.main(CurrencyConverterWSClient.java:40)
Caused by: java.lang.ClassCastException:
com.sun.xml.bind.v2.runtime.JAXBContextImpl cannot be cast to
com.sun.xml.internal.bind.api.JAXBRIContext
at
com.sun.xml.internal.ws.fault.SOAPFaultBuilder.<clinit>(SOAPFaultBuilder.java:533)
... 5 more
I have no previous version of JDK 1.6.0, but I can try to get hold of a few...
I think the problem is caused by an incorrect setting of the client's
classpath. On JDK 6 there is no need for the jars from %TUSCANY_HOME%\lib
to be on the client's classpath, as the client isn't using Tuscany.
From the stack trace it appears that you're running a modified version
of the travel sample currency converter example. Are you using the
antdefs.xml file from the travel sample to set the client's classpath?
It appears that there is some faulty logic in antdefs.xml that puts
%TUSCANY_HOME%\lib on the client's classpath for JDK 6. (It's necessary
to do this for JDK 5 becase JDK 5 doesn't contain JAXB.)
The presence of %TUSCANY_HOME%\lib on the client's classpath doesn't
cause any problems when running the travel sample because the
travel sample currency converter doesn't throw business exceptions.
The reason you are seeing this problem is that you have extended this
code to throw a business exception.
I will look at how to rework the logic in antdefs.xml to set the
classpath correctly in all cases. Can you work around the problem
for now by removing %TUSCANY_HOME%\lib from the client's classpath?
As a side note, I'm surprised that the JAXB version in %TUSCANY_HOME%\lib
isn't compatible with JDK 1.6.0_18, and I'd be interested in looking
into this further, but this seems to be a secondary issue rather than
the primary cause of the problem.
Simon
-- Sebastian
-----Original Message-----
From: Simon Nash [mailto:[email protected]]
Sent: Tuesday, September 07, 2010 5:54 PM
To: [email protected]
Subject: Re: JAXB 2.1 incompatibilty between Tuscany 1.6 and JDK
1.6.0_18
Millies, Sebastian wrote:
Hello there,
when I run a JAX-WS client (not SCA component) that accesses a remote
SCA service (in a different JVM)
which offers a binding.ws, I get a ClassCastExceptions in the innards
of JAXB:
Caused by: java.lang.ClassCastException:
com.sun.xml.bind.v2.runtime.JAXBContextImpl cannot be cast to
com.sun.xml.internal.bind.api.JAXBRIContext
at
com.sun.xml.internal.ws.fault.SOAPFaultBuilder.<clinit>(SOAPFaultBuilde
r.java:533)
... 5 more
The ClassCastException occurs only when the service throws an
application specific exception which
must be mapped to a web fault.
I am using JDK 1.6.0_18 and Tuscany 1.7 snapshot. The client side
artefacts get generated with JDK's
built-in wsimport tool.
The exception goes away when I remove jaxb-impl-2.1.7.jar from
%TUSCANY_HOME%\lib.
So I suppose the jaxb library included in Tuscany is incompatible
with what is
included in the rt.jar of JDK 1.6.0_18.
-- Sebastian
Does the problem occur on the client side or the SCA service side?
Are you able to try this on older version of JDK 1.6? Knowing which
JDK release introduced the problem might be helpful in identifying
its cause.
Simon
