commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <>
Subject Re: Resisting the temptation
Date Fri, 10 May 2002 22:24:43 GMT
At 12:17 10.05.2002 -0700, Craig R. McClanahan wrote:

> > Another, much more serious worry that I have is the fact that the 
> LogFactory
> > class keeps track of LogFactories by classloader.  What will happen in an
> > environment with multiple classloader per application, eg. EAR classloader
> > parent of WAR classloader, parent of JSP classloader, as is the case in
> > WebLogic and WebSphere? Doesn't Tomcat and other Servlet containers
> > pose the same problem, with to classloaders, the WAR classloader and
> > the JSP classloader? Wouldn't multiple LogFactories, that is multiple 
> logging
> > environments be loaded in a single application?
> >
> > What am I missing here?
> >
>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

I did not know that the 2-3 spec allowed changes to the classloading 
model. Is it nevertheless accurate to say that each classloader even within
the same application will have its own LogFactory implemenation?



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

View raw message