Kodo class/resource loading approach will be a problem in managed environment.

Question

Hello,
Kodo does not work with Apache Tomcat 3 and 4 unless Kodo jars and my
persistent classes loaded by the same class loader. Kodo uses
Class.forName() and class.getResources() on class loader which loaded Kodo
classes thus it is not able to find system.prefs or package.jdo (and even if
it was able to find system.prefs how would it handle multiple system.prefs
from multiple contexts each managed by its own class loader?)
The problem as I see it is that web containers usually have container
classloader(s) and a class loader per web context. Desired configuration
would be to share Kodo classes among all contexts and implement jndi factory
to provide PersistentManagerFactory lookup in each web container
environment. According to Tomcat specs I placed Kodo jars in
$tomcat_home/lib (class loader shared among all contexts) and deployed my
persistent classes along with system.prefs and *.jdo files to my context
WEB-INF/lib directory. As a result Kodo would not find system.prefs resource
and eventually fail with error - required resource db/url could not be
loaded. I tried to place Kodo jars into together with my persistent classes
in WEB-INF/lib it did not help (this was really strange since all classes
should have been loaded by the same context class loader) The only
configuration that works is when I put Kodo and my persistent classes in
tomcat's common directory or on system class path. Which is of course not a
right way to go as context specific classes such as my persistent classes
should be shared
Without source code it is hard to figure out what is going on and how
resources get loaded, so could somebody look into it. It is quite important
for us to resolve this issue as we are planning to use Kodo with tomcat.
Also I am not sure that system.prefs is a good idea. As I mentioned when
integrated with appserver/web container environment jndi it is up to jndi
factory to create and configure PersistentManagerFactories. Different
PersistentManagerFactories will be bound to different jndi names often in
different contexts under common or separate class loaders and they should
not be in my opinion dependent on common system.prefs
I would greatly appreciate your suggestion on proper use of Kodo in web
container environment
Thank you very much in advance
Alex Roytman

Answer 1

I want to add that even if we put both Kodo jars and persistent classes jar
in WEB-INF/lib to be loaded by context class loader it does not work due to
following piece of code in Prefs.java:
private static synchronized void loadSystem() {
try {
Enumeration enumeration =
(com.techtrader.util.app.Prefs.class).getClassLoader().getResources("system.
prefs");
Object obj = null;
Object obj1 = null;
InputStream inputstream;
for (; enumeration.hasMoreElements(); inputstream.close()) {
URL url = (URL)enumeration.nextElement();
inputstream = url.openStream();
_cache.parse(inputstream, url.toString(), "");
catch (Exception exception) {
throw new ParseException(exception);
however if we replace it with following it will work:
private static synchronized void loadSystem() {
try {
Object obj = null;
Object obj1 = null;
URL url =
(com.techtrader.util.app.Prefs.class).getClassLoader().getResource("system.p
refs");
InputStream inputstream = url.openStream();
_cache.parse(inputstream, url.toString(), "");
inputstream.close();
catch (Exception exception) {
throw new ParseException(exception);
"Alex Roytman" <[email protected]> wrote in message
news:[email protected]...
Hello,
Kodo does not work with Apache Tomcat 3 and 4 unless Kodo jars and my
persistent classes loaded by the same class loader. Kodo uses
Class.forName() and class.getResources() on class loader which loaded Kodo
classes thus it is not able to find system.prefs or package.jdo (and evenif
it was able to find system.prefs how would it handle multiple system.prefs
from multiple contexts each managed by its own class loader?)
The problem as I see it is that web containers usually have container
classloader(s) and a class loader per web context. Desired configuration
would be to share Kodo classes among all contexts and implement jndifactory
to provide PersistentManagerFactory lookup in each web container
environment. According to Tomcat specs I placed Kodo jars in
$tomcat_home/lib (class loader shared among all contexts) and deployed my
persistent classes along with system.prefs and *.jdo files to my context
WEB-INF/lib directory. As a result Kodo would not find system.prefsresource
and eventually fail with error - required resource db/url could not be
loaded. I tried to place Kodo jars into together with my persistentclasses
in WEB-INF/lib it did not help (this was really strange since all classes
should have been loaded by the same context class loader) The only
configuration that works is when I put Kodo and my persistent classes in
tomcat's common directory or on system class path. Which is of course nota
right way to go as context specific classes such as my persistent classes
should be shared
Without source code it is hard to figure out what is going on and how
resources get loaded, so could somebody look into it. It is quiteimportant
for us to resolve this issue as we are planning to use Kodo with tomcat.
Also I am not sure that system.prefs is a good idea. As I mentioned when
integrated with appserver/web container environment jndi it is up to jndi
factory to create and configure PersistentManagerFactories. Different
PersistentManagerFactories will be bound to different jndi names often in
different contexts under common or separate class loaders and they should
not be in my opinion dependent on common system.prefs
I would greatly appreciate your suggestion on proper use of Kodo in web
container environment
Thank you very much in advance
Alex Roytman