Understanding Tomcat and Class Loaders

Tomcat builds on the standard Java class loaders by adding its own to the class loader hierarchy, as shown in Figure 8-1. They’re the common class loader, the server class loader, the shared class loader, and the Web application class loader. These are the class loaders you saw in

image from book
Figure 8-1: Tomcat’s class loaders in the class loader hierarchy

As you can see, it’s not the same model of direct delegation. The server class loader delegates to the common class loader, as do the shared and Web application class loaders. This means the shared and Web application class loaders don’t have access to server internal classes, but the server class loader does.

Tomcat and the System Class Loader

Tomcat uses the default system class loader but clears the CLASSPATH environment variable in its startup file. In its place, Tomcat sets the CLASSPATH to the following:

  • CATALINA_HOME/bin/bootstrap.jar

  • CATALINA_HOME/bin/commons-logging-api.jar

  • JAVA_HOME/lib/tools.jar

At the time of writing, commons-logging-api.jar is added only to the Linux startup files. However, it’s added to the bootstrap classpath on all systems because of its presence in the CATALINA_HOME/bin directory (see the next section for details).

You’ll recall that the system class loader searches the CLASSPATH, but since Tomcat sets the CLASSPATH to the previously listed files, the system CLASSPATH variable is ignored for the duration of Tomcat’s life cycle. This is an unending source of problems with Web applications. As long as you remember that Tomcat has its own classpath that’s separate from the system classpath, and that you can add classes to Tomcat’s classpath by using the directories listed in the “Tomcat’s Common Class Loader” section, you won’t have any problems.

The bootstrap.jar file contains those classes necessary for Tomcat to start, and the tools.jar file contains the javac compiler, which is used to compile JSP pages into class files at run time. commons-logging-api.jar is used in Tomcat’s bootstrap logging.

Tomcat and the Extension Class Loader

On startup, Tomcat sets the Endorsed Standards Override Mechanism to point to the following directories, rather than the default ones mentioned earlier: CATALINA_HOME/bin and CATALINA_HOME/common/endorsed. The net result is that Tomcat’s XML parser is preferred to the one shipped with Java when using JDK 1.4. Tomcat 5.5 without the compatibility patch uses JDK 5’s XML parser, as described in Chapter 2.

Tomcat’s Common Class Loader

Next in the hierarchy is Tomcat’s common class loader that loads those classes available to Tomcat and all Web applications. It loads these class files from the following locations:

  • CATALINA_HOME/common/lib/: For JAR files

  • CATALINA_HOME/common/classes/: For class files

  • CATALINA_HOME/common/i18n/: For class files relating to internationalized messages (Tomcat 5.5 only)

Tomcat includes a number of JAR files in CATALINA_HOME/common/lib/, as shown in Table 8-1.

Table 8-1: The Contents of CATALINA_HOME/common/lib/

JAR File

Description

ant.jar

The popular Apache Ant build and deploy tool. Tomcat 5.0.x only.

ant-launcher.jar

Tomcat can be started using an Ant task, and this library is part of the process. Tomcat 5.0.x only.

commons-collections.jar

The Jakarta Commons library of general-purpose code; the collections component adds features to the standard J2SE collections framework. Tomcat 5.0.x only.

commons-dbcp.jar

As mentioned in Chapter 7, the Commons database connection pooling (DBCP) mechanism provides database and object pooling services. Tomcat 5.0.x only.

commons-el.jar

The JSP 2.0 specification includes the JSP Expression Language (EL) for the first time. This library enables the EL.

commons-pool.jar

Another object pooling service. Tomcat 5.0.x only.

jasper-compiler.jar

The Jasper compiler, which turns JSP files into servlets.

jasper-compiler-jdt.jar

Tomcat 5.5 uses the Eclipse compiler. This file allows Tomcat to run with just a JRE as opposed to a JDK. Tomcat 5.5 only.

jasper-runtime.jar

More Jasper files—these execute JSP pages that have compiled into servlets.

jsp-api.jar

The JSP API classes. Versions of Tomcat 5 separate these from the Servlet API classes. Older Tomcat versions don’t.

naming-common.jar

JNDI implementation—used to provide the default JNDI naming context as mentioned in Chapter 4.

naming-factory.jar

More JNDI support files—these are object factories exposed via the default JNDI context.

naming-factory-dbcp.jar

JNDI object factories based on the Jakarta Commons DBCP connection pooling technology. Tomcat 5.5 only.

naming-java.jar

More JNDI support files. Tomcat 5.0.x only.

naming-resources.jar

JNDI directory context implementation—provides interface for retrieving static resources.

servlet-api.jar

The Servlet API classes. Note that the JSP-specific classes are in jsp-api.jar.

Although developers can reference all these APIs, you shouldn’t allow them to place their own classes or JARs in CATALINA_HOME/common/lib. If developers need classes and JAR files to be visible to all Web applications, you should place them where the shared class loader can see them. Note that this doesn’t apply to well-known third-party libraries such as database drivers because Tomcat often needs to have access to these classes, especially if you’re providing JDBC data sources.

Putting custom classes in the common class loader path is to be discouraged for at least two reasons:

  • The custom classes could conceivably cause compatibility problems with Tomcat. For example, if you placed your own XML parser in this directory and it wasn’t tested with Tomcat, it could introduce hard-to-fix bugs. The same would be true if you introduced an older version of the Servlet API into these paths.

  • It’s easy to forget which classes/JAR files belong to developers and which belong to Tomcat. Maintenance is therefore tricky, especially for others who wouldn’t expect user classes to be in those locations.

Tomcat’s Server Class Loader

Tomcat uses the server class loader to load the server-specific classes that aren’t available to Web applications, as specified in the Servlet specification. They’re stored in CATALINA_HOME/server/lib and CATALINA_HOME/server/classes (see Table 8-2).

Table 8-2: The Contents of CATALINA_HOME/common/lib/

JAR File

Description

catalina.jar

Catalina servlet container classes.

catalina-ant.jar

Support files that enable easy deployment via Ant.

catalina-cluster.jar

Support for Tomcat clustering.

catalina-i18n-XX.jar

Internationalization classes for Tomcat in Spanish, French, and Japanese. Tomcat 5.0.x only. These have been moved into CATALINA_HOME/common/i18n in Tomcat 5.5.

catalina-optional.jar

Classes for Tomcat features that aren’t part of an official specification. For example, these include the valves and session managers discussed in Chapter 7.

commons-beanutils.jar

Easy-to-use wrappers for the Java reflection and introspection APIs. Thus, Tomcat can work with JavaBeans. Tomcat 5.0.x only. Tomcat 5.5 doesn’t have any use for these classes, though the admin application uses them.

commons-digester.jar

A digester for XML-to-Java mapping commonly used for parsing XML configuration files. Tomcat 5.0.x only. Tomcat 5.5 doesn’t have any use for these classes, though the admin application uses them.

commons-fileupload.jar

A file-upload facility. Tomcat 5.0.x only. Tomcat 5.5 doesn’t have any use for these classes, though the admin application uses them.

commons-modeler.jar

A mechanism to create MBeans compatible with the Java Management Extensions (JMX) specification.

jakarta-regexp-1.3.jar

Jakarta’s well-known Java regular expression implementation. Used by the request filter valves for one. Tomcat 5.0.x only. Tomcat 5.5 doesn’t have any use for these classes.

jkconfig.jar

Configuration classes for the JK connector. Tomcat 5.0.x only. Replaced with tomcat-ajp.jar in Tomcat 5.5.

jkshm.jar

Configuration classes for the JK connector. Tomcat 5.0.x only. Replaced with tomcat-ajp.jar in Tomcat 5.5.

servlets-XXX.jar

Some of Tomcat’s basic services, such as using SSI, using CGI, and serving static content, are provided by servlets. These JAR files contain such servlets.

tomcat-ajp.jar

JK connector classes. Tomcat 5.5 only.

tomcat-coyote.jar

Coyote connector classes.

tomcat-http.jar

HTTP/1.1 connector classes. Tomcat 5.5 only.

tomcat-http11.jar

HTTP/1.1 connector classes. Tomcat 5.0.x only. Replaced by tomcat-http.jar in Tomcat 5.5.

tomcat-jk.jar

JK connector classes. Tomcat 5.0.x only. Replaced with tomcat-ajp.jar in Tomcat 5.5.

tomcat-jk2.jar

JK2 connector classes. Tomcat 5.0.x only. Replaced with tomcat-ajp.jar in Tomcat 5.5.

tomcat-jni.jar

Classes for working with the Java Native Interface. Tomcat 5.0.x only.

tomcat-util.jar

Shared classes for the various and sundry Tomcat connectors.

Tomcat’s Shared Class Loader

Unlike the common class loader, developers can place their own classes and JAR files into the shared class loader directories. These classes are available to all Web applications. The shared class loader looks in CATALINA_HOME/shared/lib and CATALINA_HOME/shared/classes.

Tomcat’s Web Application Class Loader

Each Web application also has its own class loader, which looks in CATALINA_HOME/webapps/[webapp]/WEB-INF/lib and /WEB-INF/classes for JARs and class files. Two things make the Web application class loader unique. First, each Web application has its own instance of this class loader, which means that Web applications can’t see other people’s class files.

Second, the Web application class loader doesn’t use the delegation pattern that class loaders are encouraged to use. Instead, it tries to load classes first, before delegating the request to the other class loaders. This behavior makes it easy for Web applications to override classes in the shared and common class loaders on a per–Web application basis.

Note that this doesn’t mean the Web application class loader can override Java base classes. It can’t.

The other exception is that the Web application class loader will always delegate the following class patterns:

  • javax.*

  • org.xml.sax.*

  • org.w3c.dom.*

  • org.apache.xerces.*

  • org.apache.xalan.*

If a parent class loader doesn’t load these patterns, then the Web application class loader will attempt to load them.

Revisiting Class Loader Order

To review how these various Tomcat class loaders work together, you’ll now see what happens when an individual application requests a class. The following is a list of class loaders that will look for a class in the order attempted to find it:

  1. The bootstrap class loader looks in the core Java classes.

  2. The system class loader looks in the following places:

    • CATALINA_HOME/bin/bootstrap.jar

    • CATALINA_HOME/bin/commons-logging-api.jar

    • JAVA_HOME/lib/tools.jar

  3. The Web application class loader looks in CATALINA_HOME/webapp/[webapp]/WEB-INF/classes and CATALINA_HOME/webapp/[webapp]/WEB-INF/lib.

  4. The common class loader looks in CATALINA_HOME/common/classes, CATALINA_HOME/common/endorsed, and CATALINA_HOME/common/lib (and CATALINA_HOME/common/i18n for Tomcat 5.5).

  5. The shared class loader looks in CATALINA_HOME/shared/classes and CATALINA_HOME/shared/lib.

Dynamic Class Reloading

As discussed earlier, once a class loader has loaded a class, it caches the class. This means that future requests for the class always receive the cached copy; thus, if the class on the file system is changed while the JVM is running, the new class will be ignored.

However, because Tomcat uses its own class loader to load each Web application, it can accomplish dynamic class reloading simply by halting the Web application and then reloading it using a new class loader. The Web application’s original class loader is then orphaned and thus garbage collected at the JVM’s convenience. This eliminates the need to restart the JVM when new versions of classes are deployed.

You have two mechanisms for instructing Tomcat to reload a Web application.

  • You can configure Tomcat to scan WEB-INF/classes and WEB-INF/lib for changes.

  • You can explicitly reload the Web application with the Tomcat manager application.

Tomcat doesn’t direct its class loaders to dump their caches and reload from disk, but, rather, when it detects a change or receives an explicit reload instruction, it reloads and restarts the entire Web application.



Pro Jakarta Tomcat 5
Pro Apache Tomcat 5/5.5 (Experts Voice in Java)
ISBN: 1590593316
EAN: 2147483647
Year: 2004
Pages: 94

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net