tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <>
Subject Re: Why commons-logging-api.jar?
Date Thu, 24 Apr 2003 20:17:19 GMT
At 11:33 AM 4/24/2003 -0700, you wrote:
>Ceki Gülcü wrote:
> >>The "right" solution for commons-logging is to have a jar that has only
> >>the API, and have the implementation ( log4j + Log4J-common-logging ) in a
> >>separate package. It would be best if log4j jar would include the support
> >>for commons-logging - but since this doesn't happen, we need workarounds.
> >
> > Why do you think putting log4j + Log4J-common-logging in one jar file
> > would make any difference? It is far from obvious to me. See also below.
>What matters is having log4j and log4j-commons-logging loaded by the same
>loader. Or at least having log4j loaded by a parent class, and
>log4-commons-logging in a child ( that's why JDK1.4 logging works ).
>What doesn't work is having log4j.jar in a child loader, and
>log4j-commons-logging in a parent loader. That's because classes in
>log4j-commons-logging are using log4j classes.

That much is clear.

Why would having commons-logging in a parent loader and
log4j+log4j-commons-logging work? The answer is below.

> > What prevents you from putting log4j.jar in $TOMCAT_HOME/common/lib of
> > Tomcat?
>That would work too. The only concern is the fact that log4j would be then
>shared by all classes - and it may break the app isolation and allow apps to
>mess with the server logs.
>At that time we didn't even have the code to do app logging isolation.

I have a lot to say on logging isolation problem but that's for a different 


> > As indicated above, I do not see why putting log4j +
> > Log4J-common-logging together in one jar file, say log4j.jar, would be
> > of any help. If commons-logging cannot access log4j.jar the problem
> > remains, right? Consider the following scenario.
>The API will use the thread loader first to load the log4j adapter.
>The adapter implements commons-logging, so there is no problem
>making the calls and casts.
> > Let us assume that the user set some property forcing the
> > use of Log4jFactory by commons-logging and that loading log4j classes
> > fails because inaccessibility to the class loader in question, then
> > the same or similar failure will occur if Log4jFactory and log4j were
> > in the same jar file because now both Log4jFactory and log4j would be
> > inaccessible. Putting log4j+log4j-common-logging just displaces the
> > point of failure but does not eliminate it. Wouldn't you agree?
>No. Or at least I've seen no failure so far - as long as the adapter
>and log4j are in the same loader.

I think I am (slowly) beginning to understand. While to load the
appropriate log factory the code in o.a.c.l.LogFactory class uses the
TCL, the code in o.a.c.l.impl.Log4jFactory class just uses "new" to
load log4j loggers.

Have you considered using the TCL to load log4j classes in
Log4jFactory too?

> >>Log4j works with c-l in a hierarchical loader environment only if it is in
> >>the same loader with the c-l adapter.
> >
> > Why? (for the third time...)
>Because the adapter uses classes from log4j. If the adapter is in parent,
>log4j in child - it won't work.
>Adapter and log4j must be in the same loader, or log4j in a parent - that
>The API can be in a parent loader, and the logger+adapter in a child.

This is just a repetition of the above, so I won't comment.


Ceki  For log4j documentation consider "The complete log4j manual" 

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

View raw message