After version 0.97 (I believe) of OJB, WebSphere started to require full server resert in order to get OJB to catch up on the reloaded classes. I sent a note to IBM tech support and here's what they came up with. I hope this information is usable to you guys.
Following is the update from our L3 team: Action taken: Has been gathering logs/traces to investigate the problem. So far, have narrowed the problem arises at place where there's a programmatically class loading using forname in ConfigurationAbstractImpl.java which behave differently after class change and web module reloading. Action plan: Will check to see if that's caused by the WAS classloader and work on a patch to fix the problem if necessary. After looking this problem for awhile, I have found out 2 Class.forName() call are causing the problem in the Apache OJB library "db-ojb-1.0.rc1.jar". I've got the application working after making 2 changes: (1) ConfigurationAbstractImpl.java in org/apache/ojb/broker/util/configuration/impl change the forName call to like: clazz = Thread.currentThread().getContextClassLoader().loadClass(className); (2) ClassHelper.java in org/apache/ojb/broker/util change the forName call to like: return Thread.currentThread().getContextClassLoader().loadClass(className); However, since that function in ClassHelper.java is also used to load the Oracle JDBC driver too, you will need to make a special case to let it still use forName() when loading the JDBC driver. By the way, this approach of loading JDBC driver yourself is not recommended on WebSphere. First, you are on your own to handling all the low level JDBC connection details and skipping the nice pooling and datasource DB connection features available and managed by WebSphere. Also, this approach could pose a scalability issue. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]