commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Resisting the temptation
Date Fri, 10 May 2002 19:17:40 GMT


On Fri, 10 May 2002, Ceki Gülcü wrote:

> Date: Fri, 10 May 2002 20:43:45 +0200
> From: Ceki Gülcü <ceki@qos.ch>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> Subject: Re: Resisting the temptation
>
> At 13:17 10.05.2002 -0400, Geir Magnusson Jr. wrote:
>
> >The real problem is the digester dependency on logging, isn't it?
>
> It's one of the problems, perhaps the most interesting one but not
> the only one. Other problems are the increase in the number of
> necessary jar files, JDK compatibility issues and most importantly
> the increase in complexity of the logging setup.
>
> >A solution I can think of is for log4j to have a services entry in their
> >jar's META-INF to be the logger factory for logging.
>
> This is in line with Craig's suggestion about setting Log4jFactory
> in
>
> 1) META-INF/services/org.apache.commons.logging.LogFactory"
>
> 2) org.apache.commons.logging.LogFactory property in
> a "commons-logging.properties" file
>
> 3) org.apache.commons.logging.LogFactory in the system
> properties
>
> I think at the least the first 2 are needed because
> we might not be running under JDK 1.3.
>

Because the search algorithm is implemented inside
LogFactory.getFactory(), it's not dependent on JDK 1.3. -- The
META-INF/services search will work on any JDK.

>
> One simple question that pops up to my mind is the what
> will happen if for another jar does the same, for example
> logkit. It would be quite hilarious to have internal log4j
> messages to be output by logkit. :-)
>

:-)

If such a thing does happen, it goes back to the issue of "who's first on
the class path".

> 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 commons-logging.properties 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.

In a J2EE environment, per-EAR class loaders would let each enterprise
application define its own logging configuration independently, in the
same way.

> --
> Ceki
>

Craig


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message