BrokerImpl using thread class loader?

[Dain Sundstrom <da...@iq80.com>]

The BrokerImpl class initializes the _loader to Thread.currentThread 
().getContextClassLoader() when constructed (when an EM is  
constructed).  This cl is used while loading the mappings file.  This  
causes the entity classes to be loaded from the thread context class  
loader instead of the class loader specified in the PersistenceUnit.   
Is this expected behavior?

In the mean time, I'll code around it.

-dain

Re: BrokerImpl using thread class loader?

[Marc Prud'hommeaux <mp...@apache.org>]

Dain-

Note that in many cases, we track the thread's context class loader,  
but only use it as an auxiliary loader to check when searching for  
classes: typically, class loading will go happen via the  
Configuration's getClassResolverInstance().

That isn't to say that there aren't potential problems with our class  
loading, but if we were only using global class loaders, then we  
wouldn't be working with EJBs deployed in application servers (which  
we clearly are).

Maybe if you could provide some stack traces and more information on  
the environment in which class loading is being seen to fail, we can  
investigate more thoroughly.



On Jan 3, 2007, at 12:29 AM, Dain Sundstrom wrote:

> The BrokerImpl class initializes the _loader to Thread.currentThread 
> ().getContextClassLoader() when constructed (when an EM is  
> constructed).  This cl is used while loading the mappings file.   
> This causes the entity classes to be loaded from the thread context  
> class loader instead of the class loader specified in the  
> PersistenceUnit.  Is this expected behavior?
>
> In the mean time, I'll code around it.
>
> -dain