users@jaxb.java.net

Re: Technical Help Required in configuring JAXB in WebApp

From: Tom Amiro <tom.amiro_at_sun.com>
Date: Fri, 09 May 2003 11:06:37 -0400

Kohsuke,

This is a great document. Found a little grammatical problem with

>With some applications, things get even more complicated when the
>JAXB-generated code can be loaded by either of classloader.

Probably want to strike the "of" between "either" and "classloader".

Tom

Kohsuke Kawaguchi wrote:

>Let me know if the following document helps (or even better, let me know
>how I can improve this document.)
>
>I'm wondering if there's any value in making this document publicly
>available. Your case is probably what I'm trying to cover, so I'd like
>to know whether you find it useful or not.
>
>regards,
>--
>Kohsuke KAWAGUCHI 408-276-7063 (x17063)
>Sun Microsystems kohsuke.kawaguchi_at_sun.com
>
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> Q. I'm seeing "Unable to locate jaxb.properties for package aaa.bbb.ccc."
> Q. I can't cast the unmarshalled object into the generated type.
>
> When you invoke JAXBContext.newInstance("aaa.bbb.ccc"), it tries to
> load a property file called jaxb.properties from each package, using
> the same classloader used to load the JAXBContext class itself. This
> classloader may be different from the classloader which was used to
> load your application (see the picture). In this case, you'll see the
> above error. This problem is often seen with application servers, J2EE
> containers, Ant, JUnit, and other applications that use sophisticated
> class loading mechanisms.
>
> With some applications, things get even more complicated when the
> JAXB-generated code can be loaded by either of classloader. In this
> case, JAXBContext.newInstance("aaa.bbb.ccc") will work but the JVM
> ends up loading two copies of the generated classes for each class
> loader. As a result, unmarshalling works but an attempt to cast the
> returned object into the expected type will fail, even though its
> getClass().getName() returns the expected name.
>
> The solution for both situations is to pass your curent class loader
> like this:
>
> JAXBContext.newInstance( "aaa.bbb.ccc", this.getClass().getClassLoader() );
>
>
> In general, if you are writing code that uses JAXB, it is always
> better to explicitly pass in a class loader, so that your code will
> work no matter where it is deployed.
>
>