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 bloatesque. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
