After thinking about this some more I have a proposal to change the 
Tomcat 4 class loading.

The class loaders that Catalina uses are organized as follows, where
the parent class loader is above the child class loaders:

                        Bootstrap
                            |
                          System
                            |
                          Common
                       /    |    \
               Catalina  Webapp1  Webapp2  ...


Bootstrap - This class loader contains the basic runtime classes 
provided by the Java Virtual Machine, such as the java.* classes.  
Depending on how your particular JVM is organized, this may 
actually be more than one class loader, or may not exist at all.  
It is generally not referenced directly.

System - This class loader is initialized from the contents of the 
CLASSPATH environment variable.  The standard Catalina startup scripts 
assemble the following repositories for the system class path:

   $CATALINA_HOME/system/lib/bootstrap.jar - The Bootstrap class
   that is used to initialize the Catalina server, and the class
   loader implementation classes it depends on.

   $CATALIA_HOME/system/lib/servlet.jar - The Servlet and JSP
   API classes, placed here so that they are shared between Catalina
   and the web applications that run under it.

   $CATALIA_HOME/system/lib/naming.jar</code> - The JNDI implementation
   used by Tomcat 4.

   $JAVA_HOME/lib/tools.jar - Contains the Java compiler used to 
   compile the servlets generated from JSP pages.

Common - This class loader is where common Java API's shared by
web applications and by Catalina are stored.  For example, this is
where a JDBC driver could be installed so that both web applications
and catalina have access to it. Catalina may need to access the JDBC driver 
if you configure a JNDI JDBC DataSource in your server.xml and a web
application may need access if the JNDI JDBC DataSource is configured
in the web apps web.xml file. This class loader is initialized 
to include all JAR files in the $CATALINA_HOME/common/lib directory, and 
$CATALINA_HOME/common/classes.

Catalina - This class loader is initialized to include all JAR files in the
$CATALINA_HOME/server/lib directory, which should contain Catalina itself 
(i.e. all classes whose fully qualified names begin with org.apache.catalina.), 
and any JAR files that it depends on, and $CATALINA_HOME/server/classes.  
Because these classes are loaded from a  separate class loader, which is 
not visible to the Webapp class loader, they are not visible to web applications.

Webapp - A class loader is created for each web application that is 
installed in Catalina, and initialized to include the WEB-INF/classes 
directory (if it exists), plus all JAR files in the WEB-INF/lib 
directory, for this web app.  Because of the parentage hierarchy, 
web applications can indirectly see (and therefore load classes from) 
the Common, System, and Bootstrap class loaders, but not from the
Catalina class loader.


The above changes remove one class loading layer from a web app,
allows Common classes to use property files and resources, and cleans 
up the directories where jar files and classes are located.

Comments?

Regards,

Glenn

Glenn Nielsen wrote:
> 
> I was looking at the classloader documentation in cvs at
> catalina/docs/dev/classloaders.html and comparing it to
> how Tomcat 4 actually sets up the classloaders.  I found
> some discrepancies.
> 
> According to the docs the System class loader (CLASSPATH)
> has bin/bootstrap.jar and $JAVA_HOME/lib/tools.jar.  But in
> catalina.sh bin/servlet.jar and bin/naming.jar are also added.
> 
> According to the docs the Common class loader includes
> bin/servlet.jar and bin/naming.jar, but these are already in
> the System classpath.  What need is their to create another
> layer of class loading using the Common class loader if it
> is duplicating jar files already in the class path.  Perhaps
> the Common class loader could be removed?
> 
> In the docs the Server class loader includes all jar files in
> /server, but when the class loader is created, it also adds
> /classes if it exists.
> 
> The Shared class loader includes all jar files in /lib, as documented.
> 
> Question?
> 
> What if I have some API I want to install that is shared by web
> applications, but this API needs to use a properties file?  There
> is no place to install it.  Perhaps we could remove /classes from
> the Server class loader and add it instead to the Shared class loader.
> 
> Regards,
> 
> Glenn
> 
> ----------------------------------------------------------------------
> Glenn Nielsen             [EMAIL PROTECTED] | /* Spelin donut madder    |
> MOREnet System Programming               |  * if iz ina coment.      |
> Missouri Research and Education Network  |  */                       |
> ----------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

-- 
----------------------------------------------------------------------
Glenn Nielsen             [EMAIL PROTECTED] | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to