You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Scott Kurz <sc...@gmail.com> on 2008/01/04 20:00:03 UTC
use of JAXB impl classes in databinding-jaxb
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
Re: use of JAXB impl classes in databinding-jaxb
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
>>
>> 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
>
+1 as well for option (2), if possible.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: use of JAXB impl classes in databinding-jaxb
Posted by Simon Nash <na...@hursley.ibm.com>.
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" <na...@hursley.ibm.com>
> To: <tu...@ws.apache.org>
> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: use of JAXB impl classes in databinding-jaxb
Posted by Raymond Feng <en...@gmail.com>.
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.
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.
Thanks,
Raymond
----- Original Message -----
From: "Simon Nash" <na...@hursley.ibm.com>
To: <tu...@ws.apache.org>
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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: use of JAXB impl classes in databinding-jaxb
Posted by Simon Nash <na...@hursley.ibm.com>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org