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
