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();
