Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 25752 invoked from network); 13 May 2002 21:41:17 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 13 May 2002 21:41:17 -0000 Received: (qmail 29130 invoked by uid 97); 13 May 2002 21:41:03 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 29087 invoked by uid 97); 13 May 2002 21:41:02 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 29037 invoked by uid 98); 13 May 2002 21:41:02 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Date: Mon, 13 May 2002 14:40:50 -0700 (PDT) From: "Craig R. McClanahan" To: Jakarta Commons Developers List Subject: Re: Resisting the temptation In-Reply-To: <5.1.0.14.0.20020513230159.01cd8448@mail.qos.ch> Message-ID: <20020513142011.D8983-100000@icarus.apache.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Rating: localhost 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Mon, 13 May 2002, Ceki G=FClc=FC wrote: > Date: Mon, 13 May 2002 23:09:14 +0200 > From: Ceki G=FClc=FC > 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 fo= r > >things before delegating. Thus, the current implementation in LogFactor= y > >allows you to put commons-logging.jar and a logging implementation, with= a > >default logging configuration, into common/lib -- but still allow a weba= pp > >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 commons-logging.properties file in WEB-INF/classes). Per-JS= P > >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.= =2E. > 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 catalina.sh/catalina.bat) | | | 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: Thread.currentThread().getContextClassLoader() (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 commons-logging.properties 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 common/lib. > >Craig > > > -- > Ceki > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: