It seems that there are a number of other JAXB RI implementation classes
being used as well as this one. The BeanXMLStreamReaderImpl class pulls
in the following imports:
import
com.sun.xml.bind.v2.model.annotation.RuntimeInlineAnnotationReader;
import com.sun.xml.bind.v2.model.core.Ref;
import com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder;
import com.sun.xml.bind.v2.model.runtime.RuntimeClassInfo;
import com.sun.xml.bind.v2.model.runtime.RuntimePropertyInfo;
import com.sun.xml.bind.v2.model.runtime.RuntimeTypeInfoSet;
import com.sun.xml.bind.v2.runtime.IllegalAnnotationsException;
import com.sun.xml.bind.v2.runtime.JAXBContextImpl;
I don't know enough about JAXB to say whether the use of all these
implementation classes can be replaced by JAXB API calls. If it is
possible to change to API calls, I think this would be very desirable
so that Tuscany is not tied to a specific implementation of JAXB.
This isn't just a theoretical possibility. We can't run Tuscany with
JDK 6 "out of the box" because the JAXB implementation in JDK 6 is not
compatible with Tuscany, producing exceptions like this:
java.lang.LinkageError: JAXB 2.0 API is being loaded from the
bootstrap classloa
der, but this RI (from
jar:file:/C:/Documents%20and%20Settings/nash/.m2/reposito
ry/com/sun/xml/bind/jaxb-impl/2.1.5/jaxb-impl-2.1.5.jar!/com/sun/xml/bind/v2/mod
el/impl/ModelBuilder.class) needs 2.1 API. Use the endorsed directory
mechanism
to place jaxb-api.jar in the bootstrap classloader. (See
http://java.sun.com/j2s
e/1.5.0/docs/guide/standards/)
at
com.sun.xml.bind.v2.model.impl.ModelBuilder.<clinit>(ModelBuilder.jav
a:172)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContex
tImpl.java:422)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.ja
va:286)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:
139)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:
117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:210)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:368)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBC
ontext(JAXBContextHelper.java:59)
at
org.apache.tuscany.sca.databinding.jaxb.JAXB2Node.transform(JAXB2Node
.java:40)
at
org.apache.tuscany.sca.databinding.jaxb.JAXB2Node.transform(JAXB2Node
.java:33)
Because Tuscany is using the 2.1 JAXB RI and not the 2.0 JAXB
implementation
that's part of JDK 6, the JAXB 2.0 API that's part of JDK 6 needs to be
replaced by a 2.1 API. This can be done, but it's a nuisance to require
all JDK 6 users to make these tweaks to their JDK installation.
To solve the JDK 6 problem, we would need to not only change Tuscany
to use
the JAXB APIs but also restrict ourselves to using APIs that are in both
JAXB 2.1 and JAXB 2.0. I don't know what difficulties this would cause,
and any pointers would be appreciated. If it's possible for Tuscany to
tolerate the 2.0 API set, I'm willing to help with implementing this.
Simon
Scott Kurz wrote:
I noticed class,
org.apache.tuscany.sca.databinding.jaxb.BeanXMLStreamReaderImpl is
invoking
a constructor of com.sun.xml.bind.v2.runtime.JAXBContextImpl:
JAXBContextImpl context =
new JAXBContextImpl(classes, null, Collections.<Class,
Class>
emptyMap(), null, false, reader, false, false);
RuntimeModelBuilder builder =
new RuntimeModelBuilder(context, reader, Collections.<Class,
Class> emptyMap(), null);
Is there really a need to use the JAXB RI impl classes here?
I don't understand yet what the code is doing, but isn't it bad to
create a
dependency on a specific version of the JAXB impl, rather than the
API in
the JAXB spec?
(I didn't see a discussion on this in searching the mailing list..
only some
details about a build break that had happened at one time.)
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]