tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benson Margulies" <>
Subject RE: DO NOT REPLY [Bug 31883] - Better JNI support
Date Tue, 26 Oct 2004 00:46:44 GMT
I'm supporting a number of JNI-related things in Tomcat, and I just
don't see the point of this idea.

A JNI class is inevitably a per-JVM resource. Giving a web-app a
backdoor way to push the classes up to the common level seems like a
security problem. What if two webapps try to load dueling versions of
some JNI?

My solution here has been to work with the J2EE JNDI support. I load the
classes in common\lib, and I have bean classes that manage the resource.
This requires tomcat-specific configuration.

Perhaps there would be more appetite for a discussion of a feature to
make it easier to manage 'common' classes. This might also be purely

I'd love to be able to package up some JAR files, the information for
the global JNDI resources, and the ResourceLink for the default context
in a lump. As it is, I have to give customers a rather elaborate set of
instructions. Or an application that automagically edits xml files..

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message