Update jar class loading

Tomcat's class loading follows the model for J2EE Application
Containers and Servlet's. Each release of Tomcat has modified it's
class loading in some respect. Usually the class loading modifications
have been in the service of encouraging best practice. Typically this
means keeping web applications which may be running in the same tomcat
instance completely isolated from each other such that they can't
interfere with one other. In essence this means classes which are
loaded by a specific web application should only be visible to that
web application. Sharing classes/jars between web applications is to
avoided to the greatest extent possible. Best practice suggests only
"framework" classes (e.g. tomcat's servlet API's) should be
shared. Class visibility and sharing is controlled by a hierarchy of
class loaders. The topic of class loading, and specifically in the
context of servlet containers, has been extensively written about. For
those interested in the topic a search of the web will produce a
wealth of material. I found the following documents useful:

"Understanding The Tomcat Classpath Common Problems
And How To Fix Them"
http://www.mulesoft.com/tomcat-classpath

"Class Loaders"
http://datadisk.co.uk/html_docs/java_app/tomcat6/tomcat6_classloaders.htm

"Apache Tomcat 6.0 Class Loader HOW-TO"
http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html

"Java programming dynamics, Part 1:
Java classes and class loading"
http://www.ibm.com/developerworks/java/library/j-dyn0429/

"Taxonomy of class loader problems encountered when
using Jakarta Commons Logging"
http://articles.qos.ch/classloader.html

In particular one needs to have a firm understanding of the class
loading delegation model, parent-first vs. child-first, as this
differs between standard Java and Servlet Containers.

We attempt to follow best practice to the greatest extent possible so
that the jars we need are visible only the to appropriate class
loader.

We do have one significant exception which requires violating the
isolation principle. tomcatjss and jss are both required by the tomcat
framework and by our web application. This occurs because we specify
the catalina connector (Coyote) we wish to use for our server
SSL/TLS connections are jss instead of the default SSL/TLS connectors
in tomcat, thus tomcat needs to load tomcatjss and jss. Our web
application also utilizes tomcatjss and jss, the most obvious example
being the CrypoManager which must be a singleton instance. There is an
additional issue, jss is a JNI native library written in C. JVM's have
a restriction which prevents loading a JNI library by more than one
class loader. The fact the CryptoManager is a signleton and that jss
is JNI means jss (and tomcatjss) must only be loaded by exactly one
class loader in the JVM. Thus tomcatjss and jss must be loaded by the
tomcat common class loader which is shared between the tomcat servlet
framework and loaded web applications.

Normally tomcat ships with a catalina.properties configuration file
which enforces the best practice class loading separation. However, in
recognition that is sometimes too restrictive the catalina.properties
file can be edited to support other class loading configurations. We
take advantage of this by establishing a "common" class loading
location specific to the tomcat instance
(e.g. $CATALINA_BASE/common/lib). The tomcat common class loader via
the catalina.properties file is directed to also search this
directory. We install tomcatjss, jss and jakarta-commons-logging in
this common location. All other jars follow best practice and are
isolated in the web applications library
(e.g. $CATALINA_BASE/webapps/<webapp_name>/WEB-INF/lib).

The reason why jakarta-commons-logging is also installed in common
along with tomcatjss and jss is because it is a dependency of
tomcatjss and is not otherwise available because tomcat uses another
logging package.

When we install the tomcat instance we don't actually copy jar files
into the library directories under $CATALINA_BASE because we want to
use the system supplied jar files and if they are updated because of
bug fixes, security fixes, etc. we want to immediately take advantage
of the updated version of the jar file. Thus we "install" symbolic
links in the library directories which point to the system supplied jar
files. This also reduces disk usage by avoiding multiple copies of the
same file.

This patch implements the above by doing the following:

Makes catalina.properties a "template file" which is processed by our
templating facility. The only substitution at the moment is the common
class loader location.

Establishes the paths to each of our required jar files as supplied by
the system package manager.

Creates symbolic links the to jar files in the instance library
directories.


The following diagram illustrates the class loading described above:

                          +--------------------+
                          |     Bootstrap      |
                          |    Class Loader    |
                          +--------------------+
                                    |
                                    V
                          +--------------------+
                          |     Extension      |
                          |    Class Loader    |
                          +--------------------+
                                    |
                                    V
                          +--------------------+
                          |      System        |
                          |    Class Loader    |
                          +--------------------+
                                    |
                                    V
                      +---------------------------+
                      |          Common           |
                      |        Class Loader       |
                      | $CATALINA_BASE/common/lib |
                      |       (see note 1)        |
                      +---------------------------+
                                    |
                    +---------------+--------------------+
                    |                                    |
                    V                                    V
+---------------------------------------+   +-------------------------+
|                CA Web App             |   |        Web App 2        |
|               Class Loader            |   |      Class Loader       |
| $CATALINA_BASE/webapps/ca/WEB-INF/lib |   | (for illustration only) |
|              (see note 2)             |   |                         |
+---------------------------------------+   +-------------------------+

[1] Common loader loads these jars:

    jakarta-commons-logging
    jss
    tomcatjss

[2] CA Web App loader loads these jars:

    certsrv
    cms
    cmsbundle
    cmscore
    cmsutil
    jakarta-commons-collections
    kra
    ldapjdk
    nsutil
    osutil
    velocity
    xerces-j2


git-svn-id: svn+ssh://svn.fedorahosted.org/svn/pki/trunk@1554 c9f7a03b-bd48-0410-a16d-cbbf54688b0b

0 files changed, 0 insertions, 0 deletions