Comments inline.

  Simon

Raymond Feng wrote:

Hi,

I just came back from vacation and saw this discussion. I think there are two separate issues here.

1) Usage of SUN JAXB implementation classes

The class that Simon pointed out is actually a hacky experiment to render JAXB objects as XMLStreamReader. I was looking into the reflection capability. There is a project at https://jaxb2-reflection.dev.java.net/ which provides similar reflection layer independent of the JAXB-impl. We could use it. So the bottom line is that we can remove the dependency on a particular version of SUN JAXB RI.

Thanks, Raymond.

2) Coexisence of different versions of JAXB with JDK 6

We have already encountered this issue a while ago and Sebastien figured out a way to override the JDK6 JAXB (2.0) by using the endorsed directory. IMO, it's feasible to force every applications to use JAXB 2.0 to be run with JDK6.

I'm not sure which of the following you are saying:
1) Tuscany should require JAXB 2.1.  When running on Sun JDK 6, this
   requires the Sun JDK6 version of JAXB (2.0 implementation and 2.0 API)
   to be overridden with a 2.1 version of both the implementation and
   the API, because Tuscany needs something that is only in 2.1, not 2.0.
   This overriding can be done using the endorsed standards menchanism.
2) Tuscany should tolerate both JAXB 2.0 and JAXB 2.1.  It is up to
   applications to decide which version they need and use the endorsed
   standards overriding if they wish.  Tuscany supports this overriding,
   but does not require it.

Currently the position is 1).  If possible, I'd prefer it to be 2).  Are
there any technical issues with changing it to 2)?

  Simon

Thanks,
Raymond


----- Original Message ----- From: "Simon Nash" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, January 07, 2008 1:03 AM
Subject: Re: use of JAXB impl classes in databinding-jaxb


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]







---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to