> 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
