Tomcat Web Hosting Blog - Java, JSP, EJB, Hibernate

Chapter 9: Class Loaders Unfortunately, under Java 1.4, Tomcat must share the same version of the Xerces XML parser as its Web applications (as well as the same version of Xalan, an XSLT engine). Tomcat relies on the Endorsed Standards Override Mechanism for the version of Xerces it requires, and as discussed previously, the Web application class loader delegates to this mechanism under all conditions (see the section Web Application Class Loader Details, earlier in this chapter). This is likely not a problem unless a Web application relies on an old version of Xerces/Xalan for a particular behavior. Or, it is possible that a version of Xerces/Xalan that is newer than the one that shipped with Tomcat is required for a Web application (the version of Xerces/Xalan shipped with Tomcat can be determined by checking the MANIFEST.MF file in the Xerces JAR). In such circumstances, the only alternative is to change the parser in the $CATALINA_HOME/endorsed directory and hope that such a change doesn t break Tomcat. Of course, these parser version issues really apply only if the Apache family of XML parsers is used. If you use another JAXP implementation whose classes are in entirely different package names, all of the issues just described are eliminated. However, Xerces is by far the world s most popular JAXP implementation. Summary To conclude this chapter on class loaders, let s review some of the key points we have discussed: . Class loaders abstract the process of loading class files before the first instantiation and make them available for use. Java s default class loaders support loading classes from the local file system and from a network. Java also provides developers with a facility to create their own custom class loaders. The three basic class loaders discussed are the bootstrap, extension, and system class loaders. . Class loaders use the delegation model. Every class loader passes a request to load a class to its parent until the bootstrap class loader is reached. Each class loader looks for the class, and if it can t be found, the request goes back down the chain. Implementing the delegation model is optional, but class loaders are basically useless if they don t delegate to the bootstrap class loader at some point. Every class loader has a unique namespace. . The Java security model prevents the misuse of custom class loaders by allowing only the bootstrap class loader to load classes that start with java.*. By using the SecurityManager, an application can forbid the use of custom class loaders. . Tomcat has two different class loaders: common, and Web application. This is in addition to the standard Java classloaders bootstrap, extension, and system. . Classes and resource files specific to a Web application should be placed under the Web application s WEB-INF/classes directory. Similarly, JAR files specific to a Web application should be placed under the Web application s WEB-INF/libdirectory. Chapter 10 examines the first of the Tomcat Connectors: HTTP Connectors.

For reliable and cheap web hosting services please check cheap web hosting website.