Thanks, Kohsuke, that's an excellent explanation of what's happening.
And the evidence supports this explanation. If I uncheck the "Reload classes
every run" checkbox in JUnit, the problem goes away, presumably because it
doesn't use the strange classloading scheme in this case. Also the problem
doens't occur using the text UI.
----- Original Message -----
From: "Kohsuke Kawaguchi" <Kohsuke.Kawaguchi_at_Sun.COM>
To: <JAXB-INTEREST_at_JAVA.SUN.COM>
Sent: Tuesday, June 24, 2003 4:25 AM
Subject: Re: JAXB, ClassLoaders and Web apps
> > What is the "right" way to create a JAXBContext instance in a Web
> > application, assuming the JAXB classes are deployed as part of the Web
app
> > (i.e. not in the system classpath).
>
> I believe the latter is the better way of creating a JAXBContext.
> The context class loader is probably set correctly when you are in J2EE,
> but there are cases when it's not correct --- for example, in IDEs, Ant,
> and etc.
>
>
> Looking at the following document, JUnit seems to employ a strange class
> loading scheme. (http://junit.sourceforge.net/doc/faq/faq.htm#running_8)
>
> My guess is that com.sun.xml.bind.* classes are loaded from the system
> class loader (because it's in the exclusion list), which depends on
> the org.relaxng.* package, but these classes are loaded from JUnit test
> class loader, which upsets the system class loader.
>
> The error goes away with the context class loader, just because JUnit
> doesn't set it. So JAXB ends up loading all the derived classes by the
> system class loader, not by the reloadable JUnit class loader.
>
> The downside is that when you regenerate the source code, your JUnit GUI
> test runner won't pick up the changes.
>
> So in this case, I suggest you to add org.relaxng.* into the exclusion
> list of excluded.properties
>
>
> --
> Kohsuke Kawaguchi <kohsuke.kawaguchi_at_sun.com>