It is probably specific to classes already loaded by IntelliJ more than
those specific to rt.jar... Although they will usually be the same, chance
are that it would work for some class that they have not yet loaded.
If it did, then that would show the the parent classloader is returning that
it has already loaded the class (which is the documented case for
classloaders)... If not, then that would show that the parent classloader is
being asked to resolve it when it shouldn't (should only resolve if it isn't
found by current classloader)
The expectation would be that if you put the jsr173 jar into the
bootclasspath in the bat file (temporarily) then the IDE would load from it
instead of from rt.jar... that would show whether it is hardcoding where it
is loading it from.
Malachi
On 3/23/06, Kirill Grouchnikov <kirillcool_at_yahoo.com> wrote:
>
> Malachi,
>
> First - IDEA source is closed, so i don't really have a chance to check
> the logic of PluginClassLoader. In the debugger i see that it has a list of
> ZipClassLoaders, each one pointing at a different JAXB 2.0 jar.
>
> However, since the LinkageError disappears as soon as QName is removed
> from jsr173_1.0_api.jar, i can assume that the below is only correct for
> non-JRE classes.
>
>
> Kirill
>
> *Malachi de �lfweald <malachid_at_gmail.com>* wrote:
>
> hmmm...
>
> from the docs:
>
>
> Plugin Class Loaders For loading the classes of each plugin, IDEA uses a
> separate class loader. This allows each plugin to use a different version of
> some library, even if the same library is used by IDEA itself or another
> plugin.
> By default, the classes not found in the plugin class loader are loaded
> through the main IDEA class loader. However, it is possible to use the
> depends element in plugin.xml to specify that a plugin depends on one or
> more other plugins. In this case, the class loaders of those plugins will be
> used for classes not found in the current plugin. This allows a plugin to
> reference classes from other plugins.
>
> This seems to say that it should only be loading it from the parent
> classloader if your plugins classloader failed to locate it. Can you verify
> that your plugin, when asked to load a class using the CURRENT classloader
> in fact loads it from the parent classloader?
>
>
> Also, obviously not a good option for distribution, but for debugging you
> might consider editing this line in idea.bat/sh:
> set REQUIRED_IDEA_JVM_ARGS=-Xbootclasspath/p:%IDEA_HOME%/lib/boot.jar
> %IDEA_PROPERTIES_PROPERTY%
>
>
>
> Malachi
>
>
>
> On 3/23/06, Kirill Grouchnikov <kirillcool_at_yahoo.com> wrote:
> >
> > Malachi,
> >
> > The same order here. It's not the build that fails, the exception is at
> > runtime. I guess it's something to do with the PluginClassLoader that is
> > used for plugin code (which could be different from regular
> > IdeaClassLoader).
> >
> > Kirill
> >
> >
> > *Malachi de �lfweald <malachid_at_gmail.com >* wrote:
> >
> > Have you checked what order they are in in your IntelliJ module?
> >
> > File | Settings | Modules | (select your module) | Order/Export | (HERE)
> >
> > mine is:
> > JDK 1.6
> > <Module Source>
> > <other dependant modules>
> > JAXB
> >
> > However, I am using Maven to actually build, not IntelliJ.
> >
> >
> > Malachi
> >
> > On 3/21/06, Kirill Grouchnikov <kirillcool_at_yahoo.com > wrote:
> > >
> > > 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
> > > <http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=39174/*http://photomail.mail.yahoo.com>makes
> > > sharing a breeze.
> > >
> >
> >
> > ------------------------------
> > Yahoo! Messenger with Voice.
> > <http://us.rd.yahoo.com/mail_us/taglines/postman3/*http://us.rd.yahoo.com/evt=39666/*http://beta.messenger.yahoo.com+%0A>PC-to-Phone
> > calls for ridiculously low rates.
> >
>
>
> ------------------------------
> New Yahoo! Messenger with Voice.<http://us.rd.yahoo.com/mail_us/taglines/postman4/*http://us.rd.yahoo.com/evt=39666/*http://beta.messenger.yahoo.com%0A>Call regular phones from your PC for low, low rates.
>
>