commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Resisting the temptation
Date Mon, 13 May 2002 21:40:50 GMT
On Mon, 13 May 2002, Ceki Gülcü wrote:

> Date: Mon, 13 May 2002 23:09:14 +0200
> From: Ceki Gülcü <>
> Reply-To: Jakarta Commons Developers List <>
> To: Jakarta Commons Developers List <>
> Subject: Re: Resisting the temptation
> At 12:17 10.05.2002 -0700, Craig McClanahan wrote:
> >For Tomcat 4 specifically (and generically for 2.3-based servlet
> >containers), the webapp class loader is allowed to look locally first for
> >things before delegating.  Thus, the current implementation in LogFactory
> >allows you to put commons-logging.jar and a logging implementation, with a
> >default logging configuration, into common/lib -- but still allow a webapp
> >to configure its own loggers differently if it wants to (either by
> >including a JAR file with the right services entry in WEB-INF/lib, or by
> >including a file in WEB-INF/classes).  Per-JSP
> >class loaders (if the container uses them) will have the webapp class
> >loader as the parent, so these JSP pages will see the same logging
> >configuration.
> Per Section 9.7.2 (last paragraph) of the spec 2.3. Thanks for the light...
> On the other hand, doesn't the current classloading implementation(s) of
> Tomcat give precedence to whatever is in common/lib/, common/classes,
> or jre/lib/ext/?

For review, the class loader hierarchy in a standard Tomcat 4 environment
(i.e. you use the standard scripts to start it) is as follows:

      Bootstrap (could be several depending on JVM.  Includes jre/lib/ext)
        System (the CLASSPATH that is set up by
        Common (common/classes and common/lib)
       /      \
      /        \
     /          \
 Catalina        Shared (classes and lib in 4.0,
 (server/classes     \   shared/classes and shared/lib in 4.1)
  server/lib)         \
                     Webapp (WEB-INF/classes and WEB-INF/lib)

All of these class loaders, *except* the Webapp class loader, follow the
standard Java delegation model.  In effect, that means that the class
loaders are searched from the top of the tree down to the class loader you
originally asked to load a class for you (i.e. if you've got a class in
the shared class loader, and you say "new Foo()", it searches Bootstrap,
System, Common, and Shared in that order for Foo.class).

The webapp class loader is the exception to the rule -- it searches
locally (in WEB-INF/classes and WEB-INF/lib) first, and only *then* goes
to the top of the list and works back down.  There are protections built
in to the class loader implementation to avoid security problems like
spoofing a java.* or javax.servlet.* class.

The answer to which classes (for ClassLoader.loadClass()) and resources
(for ClassLoader.getResource() and ClassLoader.getResourceAsStream()) are
given preference depends, first of all, on which class loader you use to
do the lookup.  If you put commons-logging.jar into the common class
loader (as a default 4.1 build does), then the normal process would look
only in Bootstrap, System, and Common for configuration information.

However, the J2EE/1.3 (which means servlet 2.3) servlet containers are
also required to make the webapp class loader visible to application code
running on a request processing thread (or during things like init() to a
servlet), via a call to:


(Although 2.2 containers are not required to support this, most of them in
fact do so as well.)

The commons-logging factory search algorithm takes advantage of this to
ask the webapp class loader (if one can be found) to do the configuration
resource lookup.  That way, a resource (or a
META/INF/services entry in a JAR file) that is inside the webapp will
still take precedence (for that webapp only) over anything configured in

> >Craig
> --
> Ceki
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message