Millies, Sebastian wrote:
JDK 1.6.0 up to update 03 did not include JAX-WS 2.1. Therefore I have tested 
with 1.6.0_04
and also with the newest update 1.6.0_21. The problem already existed in 04 and 
continues
to exist in 21.

Perhaps it has escaped attention because (a) it only occurs when an exception 
is thrown,
and (b) only if a native Java (non-SCA) webservice client is used.

As for (a), the underlying cause may be that the com.sun.xml.internal.ws.fault.SOAPFaultBuilder from the rt.jar imports classes from com.sun.xml.INTERNAL…, whereas the jaxb-impl-2.1.7.jar in
the Tuscany 1.x distribution contains com.sun.xml… (without the “internal”).

Thanks for this, it narrows down the cause of the incompatibility.

It looks like the JAXBContext used by the client is being created as
  com.sun.xml.bind.v2.runtime.JAXBContextImpl
instead of
  com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl

What's puzzling me is that both JAX-WS and JAXB are part of the
JDK and I would have expected the built-in versions to be picked up
by the client code in preference to anything on the classpath.
There must be some code somewhere that's creating a JAXBContext by
looking on the classpath.  I'll try to figure out where the
JAXBContext is getting created.

  Simon

-- Sebastian

-----Original Message-----
From: Millies, Sebastian [mailto:[email protected]]
Sent: Tuesday, September 07, 2010 7:41 PM
To: [email protected]
Subject: FW: JAXB 2.1 incompatibilty between Tuscany 1.6 and JDK
1.6.0_18

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(SyncMethodH
andler.java:107)
        at
com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodH
andler.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>(SOAPFaultBuilde
r.java:533)
        ... 5 more

I have no previous version of JDK 1.6.0, but I can try to get hold of a
few...

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


Reply via email to