On Tue, 7 Aug 2001, D. Jay Newman wrote:
> If you're using Java 1.2+ you should be able to put these sorts of shared
> jars in the $JAVA_HOME/jre/lib/ext directory.
>
> It works for me.
>
Here are a few things to think about with this approach.
* Tomcat 3.2 (and above) let you run web apps under the control of a
Java security manager, so you can grant fine-grained access to system
facilities to your apps. Any JAR files that are placed in the Java
extensions directory ($JAVA_HOME/jre/lib/ext) receive the same
permissions as all the core JDK classes -- something you may or may not
want for application classes.
* (This issue applies to JARs in $TOMCAT_HOME/lib as well). Not all
JAR files will work when installed in a shared directory. In general,
containers will create a classloader that makes these classes visible,
and then make that classloader a parent of the classloader for each
webapp (the one that loads classes from /WEB-INF/classes and
/WEB-INF/lib). The problem happens when the shared JAR needs to create
a new object of a class that is in your webapp's classloader -- unless
it is programmed specifically to deal with this situation, the shared
class will get ClassNotFoundException errors.
* In some environments, web apps need to use different versions of the
same classes (for example, different versions of the same XML parser
or JDBC driver) within the same VM. Placing JAR files here makes it
difficult or impossible to support different versions.
* If you are developing web apps to be packaged and deployed as WARs,
you should prefer to include all required JARs inside (so that it is
self contained). This will minimize install hassles for your users.
Depending on the user to also install external JARs in the right place
makes life harder for them.
* On the other hand, if you need these classes in more than one web app,
placing the JARs in $TOMCAT_HOME/lib or the extensions directory
does save a little bit of memory.
Everything in life is a tradeoff ... there's no free lunch :-)
Craig
