I think that JNI is the only counter-example. Forgive me if the following is well know but seen as unimportant to all concerned.
There is a JVM restriction: any given class with native members can only be loaded into one classloader of a JVM. So, if two webapps both try to include a native class, the second fails. If you load a webapp with a native class, and then reload it later during development, you are likely (at least, you used to be very likely) to fail and have to restart tomcat. I confess I haven't tried this lately. So, if you have a class library with native classes, and you want to use it in more than one webapp, you are, as far as I know, stuck with the common directory. Using JNDI to coordinate the use of this sort of thing just seemed to me to be an example of using the materials at hand. If tomcat wanted to take the design approach that 'we're not a J2EE container, we don't have any support for shared resources, go find a big fat J2EE container if you want that', you'd get no squeaking from me, whatever difference that makes. I am, however, stuck with the practical problem of JNI, and more than willing to lend a hand to an alternative scheme. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
