You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Gerry Woods <ge...@gmail.com> on 2011/05/20 03:59:21 UTC

Knarly classloading problem in Felix 3.0.5+ with JAXB

We have encountered a knarly classloading problem that appears to have been
introduce in Felix 3.0.5 and is still present in the upcoming 3.2.2
release.  Our scenario is that we are using Java 1.5 with JAXB 2.1.7.
Because of the well-known problems with JAXB using the thread context
classloader by default, the enterprising souls here modified the
javax.xml.bind bundle manifest to include "DynamicImport-Package: *", and
then the JAXBContext is created using:

  context = JAXBContext.newInstance(paths.toString(),
JAXBContext.class.getClassLoader());

Not the most elegant solution, but we've been getting by.  Until we tried to
upgrade to 3.2.1, when we started seeing:

Caused by: java.lang.NoClassDefFoundError
    at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:258)
    at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
    at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117)
    at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:188)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:585)
    at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:133)
    at javax.xml.bind.ContextFinder.find(ContextFinder.java:299)
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:372)
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:337)

We went all the way back to 3.0.4 before this error disappeared.  The
relevant lines in JAXBContextImpl in this particular version are shown
below.  It seems that the DatatypeConverter class might be the issue,
although that appears to be imported from javax.xml.bind.  Any insight you
guys can offer would be appreciated.  We're stuck on 3.0.4 until we can
resolve this (classloader humour).

254    *public* JAXBContextImpl(Class[] classes, Collection<TypeReference>
typeRefs,

255        Map<Class,Class> subclassReplacements, String defaultNsUri, *
boolean* c14nSupport,

256        @Nullable RuntimeAnnotationReader ar,
*boolean*xmlAccessorFactorySupport,
*boolean* allNillable) *throws* JAXBException {

257        // initialize datatype converter with ours

-> 258        DatatypeConverter.*setDatatypeConverter*(DatatypeConverterImpl
.*theInstance*);

259

230        *if*(defaultNsUri==*null*)      defaultNsUri="";    // fool-proof

231

232        *if*(ar==*null*)

233            ar = *new* RuntimeInlineAnnotationReader();

Re: Knarly classloading problem in Felix 3.0.5+ with JAXB

Posted by "Richard S. Hall" <he...@ungoverned.org>.
Can you create a scenario to send me that recreates the situation?

-> richard

On 5/19/11 21:59, Gerry Woods wrote:
> We have encountered a knarly classloading problem that appears to have been
> introduce in Felix 3.0.5 and is still present in the upcoming 3.2.2
> release.  Our scenario is that we are using Java 1.5 with JAXB 2.1.7.
> Because of the well-known problems with JAXB using the thread context
> classloader by default, the enterprising souls here modified the
> javax.xml.bind bundle manifest to include "DynamicImport-Package: *", and
> then the JAXBContext is created using:
>
>    context = JAXBContext.newInstance(paths.toString(),
> JAXBContext.class.getClassLoader());
>
> Not the most elegant solution, but we've been getting by.  Until we tried to
> upgrade to 3.2.1, when we started seeing:
>
> Caused by: java.lang.NoClassDefFoundError
>      at
> com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:258)
>      at
> com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
>      at
> com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117)
>      at
> com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:188)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>      at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:585)
>      at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:133)
>      at javax.xml.bind.ContextFinder.find(ContextFinder.java:299)
>      at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:372)
>      at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:337)
>
> We went all the way back to 3.0.4 before this error disappeared.  The
> relevant lines in JAXBContextImpl in this particular version are shown
> below.  It seems that the DatatypeConverter class might be the issue,
> although that appears to be imported from javax.xml.bind.  Any insight you
> guys can offer would be appreciated.  We're stuck on 3.0.4 until we can
> resolve this (classloader humour).
>
> 254    *public* JAXBContextImpl(Class[] classes, Collection<TypeReference>
> typeRefs,
>
> 255        Map<Class,Class>  subclassReplacements, String defaultNsUri, *
> boolean* c14nSupport,
>
> 256        @Nullable RuntimeAnnotationReader ar,
> *boolean*xmlAccessorFactorySupport,
> *boolean* allNillable) *throws* JAXBException {
>
> 257        // initialize datatype converter with ours
>
> ->  258        DatatypeConverter.*setDatatypeConverter*(DatatypeConverterImpl
> .*theInstance*);
>
> 259
>
> 230        *if*(defaultNsUri==*null*)      defaultNsUri="";    // fool-proof
>
> 231
>
> 232        *if*(ar==*null*)
>
> 233            ar = *new* RuntimeInlineAnnotationReader();
>

Re: Knarly classloading problem in Felix 3.0.5+ with JAXB

Posted by David Jencks <da...@yahoo.com>.
I ran into a similar problem (same stack trace I think) with java 6 and jaxb 2.2.  I thought that the problem was that jaxb was loading classes from the java 6 jaxb implementation instead of the bundlieized 2.2 implementation using boot delegation until someone pointed out to me that the packages were different in the two implementations.    Even though it doesn't seem possible that it could make a difference, I stopped having this problem after I changed the boot delegation property to include all the com.sun.* packages other than com.sun.xml.bind and the similar package for the jdk built-in jaxb.

I hope someone can figure out what is going on.... I ran out of time to spend on this.

During some of my investigations it looked like the 
> com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:258)
was looking in the framework classloader rather than the jaxb bundle classloader but I couldn't figure out why.  Perhaps this suggests that something changed in boot delegation and not all NoClassDefFoundErrors are getting handled appropriately.

thanks
david jencks

On May 19, 2011, at 6:59 PM, Gerry Woods wrote:

> We have encountered a knarly classloading problem that appears to have been
> introduce in Felix 3.0.5 and is still present in the upcoming 3.2.2
> release.  Our scenario is that we are using Java 1.5 with JAXB 2.1.7.
> Because of the well-known problems with JAXB using the thread context
> classloader by default, the enterprising souls here modified the
> javax.xml.bind bundle manifest to include "DynamicImport-Package: *", and
> then the JAXBContext is created using:
> 
>  context = JAXBContext.newInstance(paths.toString(),
> JAXBContext.class.getClassLoader());
> 
> Not the most elegant solution, but we've been getting by.  Until we tried to
> upgrade to 3.2.1, when we started seeing:
> 
> Caused by: java.lang.NoClassDefFoundError
>    at
> com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:258)
>    at
> com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
>    at
> com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117)
>    at
> com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:188)
>    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>    at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>    at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>    at java.lang.reflect.Method.invoke(Method.java:585)
>    at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:133)
>    at javax.xml.bind.ContextFinder.find(ContextFinder.java:299)
>    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:372)
>    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:337)
> 
> We went all the way back to 3.0.4 before this error disappeared.  The
> relevant lines in JAXBContextImpl in this particular version are shown
> below.  It seems that the DatatypeConverter class might be the issue,
> although that appears to be imported from javax.xml.bind.  Any insight you
> guys can offer would be appreciated.  We're stuck on 3.0.4 until we can
> resolve this (classloader humour).
> 
> 254    *public* JAXBContextImpl(Class[] classes, Collection<TypeReference>
> typeRefs,
> 
> 255        Map<Class,Class> subclassReplacements, String defaultNsUri, *
> boolean* c14nSupport,
> 
> 256        @Nullable RuntimeAnnotationReader ar,
> *boolean*xmlAccessorFactorySupport,
> *boolean* allNillable) *throws* JAXBException {
> 
> 257        // initialize datatype converter with ours
> 
> -> 258        DatatypeConverter.*setDatatypeConverter*(DatatypeConverterImpl
> .*theInstance*);
> 
> 259
> 
> 230        *if*(defaultNsUri==*null*)      defaultNsUri="";    // fool-proof
> 
> 231
> 
> 232        *if*(ar==*null*)
> 
> 233            ar = *new* RuntimeInlineAnnotationReader();