Kohsuke,
With the class loader being com.intellij.ide.plugins.cl.PluginClassLoader (not much i can do here) and four (!) versions of QName class in the classpath:
jar:file:/H:/IntelliJ%20IDEA%205.1/jre/lib/rt.jar!/javax/xml/namespace/QName.class
jar:file:/C:/Documents and Settings/Owner/.IntelliJIdea50/sandbox/plugins/jaxbw-plugin/lib/jsr173_1.0_api.jar!/javax/xml/namespace/QName.class
jar:file:/H:/IntelliJ IDEA 5.1/lib/xml-apis.jar!/javax/xml/namespace/QName.class
jar:file:/H:/IntelliJ IDEA 5.1/lib/ant/lib/xml-apis.jar!/javax/xml/namespace/QName.class
it's obviously a complete disaster.
Moreover, the LinkageError is thrown not always. On one computer it's thrown on simple schema, on another it's not thrown on the same schema but is thrown on FPML / HRXML / VoiceXML. The IDEA version is the same in both cases.
I have tried using the user classpath option and point to the rt.jar, but the XJC driver fails nonetheless. Any option that comes to your mind?
Kirill
Kohsuke Kawaguchi <Kohsuke.Kawaguchi_at_Sun.COM> wrote: Kirill Grouchnikov wrote:
> The jsr173_1.0_api.jar contains the version of QName without
> serialVersionUID (in package javax.xml.namespace). The rt.jar of JDK
> 5.0_06 contains QName (in the same package) with serialVersionUID.
When you have a conflict between a class in rt.jar and a class in a jar
file on your classpath, rt.jar always wins, by the default Java class
loader delegation rule.
So when you see a loader constraints violated like this, it must be that
you are setting up a classloader that doesn't follow the parent-first
delegation rule. Such a classloader usually allows certain classes to be
loaded from the parent (for example you need to get java.lang.String
from rt.jar), and if so, you can usually fix them by tweaking that list
to include javax.xml.namespace.
> As i understand, the JAXB 2.0 compiled classes use the former version,
> while at runtime the class loader may decide to use the JRE version
> instead - i think this is what causes the LinkageError.
Compiling classes against one version of QName and using it against
another version of QName is not an issue, unless we generate code that
relies on serialVersionUID, which we don't.
Even if this is an issue, you'll get a different error, not "loader
constraints violated" error.
> Any reason why the QName classes are different and why JAXB 2.0 is not
> compiled against the JDK version? I know there's little time left until
> FCS but this seems like a serious issue.
I don't think the compilation vs the runtime difference is the problem,
for the reason I mentioned. JAXB RI is compilied against JDK 5.0 (in
fact it's very difficult not to!)
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com
---------------------------------
Yahoo! Mail
Bring photos to life! New PhotoMail makes sharing a breeze.