From: Robert Lowe <rmlowe_at_rmlowe.com>
Date: Sat, 10 May 2003 04:53:39 +0800

Yes, I too found this document very helpful. I've encountered similar problems and this explains what's going on very clearly.


  ----- Original Message -----
  From: Tom Amiro
  To: JAXB-INTEREST_at_JAVA.SUN.COM
  Sent: Friday, May 09, 2003 11:06 PM
  Subject: Re: Technical Help Required in configuring JAXB in WebApp


  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.