db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Bengtson <e...@jpox.org>
Subject Re: Minutes: JDO TCK Conference Call Friday, Nov 10, 9 am PST
Date Sat, 11 Nov 2006 09:23:19 GMT
> 2.  Suggestion for new PMF setting javax.jdo.ClassLoader
>
>  From Erik: When a JDBC driver is not loaded by the classloader ruled
> by JDO, there is no standard trick to make it work besides
> implementing the object factory (DriverManager is not designed for
> complex classpath). In JPOX, we have implemented a PMF setting where
> users can specify a ClassLoader for general use (it is the last one
> in search order). Do you think we could make this in the standard?
>
> javax.jdo.ClassLoader which takes a java.lang.ClassLoader as value.
>
> We assume that the intended use is for applications that specify the
> property javax.jdo.javax.jdo.option.ConnectionDriverName and
> class.forName on this property value results in class not found. So
> the jdbc driver is never registered with DriverManager.
>

This is the most common case I remember that needs to lookup to the user defined
classloader.

> Questions: Why doesn't the ContextClassLoader work?

Here is the scenario:

ClassLoader A loads libraries like JDBC drivers.

ClassLoader B loads persistent classes.

ClassLoader C loads persistent code. (delegates to B, C and D) (has a reference
to A)

ClassLoader D loads libraries like JDO.

ClassLoader E loads JPOX. (delegates to D)

ClassLoader F is used by GUI .

App starts with Thread 1 that uses classloader F, it switch to class loader C
(creates the pmf), but quickly falls back to F. After that, the current context
loader is F. The only workaround is giving the reference of A to the PMF when
created.

> usage in a managed environment?

No, this is not the main case. Here people should use the datasource provided by
the app servers





Mime
View raw message