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 18:19:41 GMT
At 10:06 AM 4/24/2003 -0700, Costin Manolache wrote:

>The implementation of commons-logging for log4j creates a lot of problems if
>it is bundled with commons-logging, and log4j is in a different loader. Same
>thing would happen with any other API ( JDBC, JNDI, JAXP ) if you place the
>  implementation ( which in our case consists of log4j + adapters ) in
>different loaders.
>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.

> >>commons-logging-api contains only the logging API and things that don't
> >>depend on external packages. If you want to use log4j - you must deploy
> >>log4j and the adapter for log4j ( which currently means
> >>commons-logging.jar, the full package, since there is no standalone
> >>adapter ).
> >
> > If I understand correctly, JDK 1.4 logging is considered as internal
> > as opposed to external.  My goal is to understand your motivations and
> > technical reasoning in order to better answer user questions on
> > log4j-user@.
> >From a class loading perspective - JDK1.4 logging is allways in the parent

What prevents you from putting log4j.jar in $TOMCAT_HOME/common/lib of Tomcat?

>The problem is that having part of the implmentation in the same loader
>with the API, and part in a child loader doesn't work.
>For JDK1.4 - there are no problems.

There is no problem with JDK 1.4 because it's in the system class
loader. Placing log4j high in the hierarchy, in particular at or above
the common loader would work. Hint: just place log4j.jar in

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.

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?

Is there a case where the default factory (LogFactoryImpl) is selected
and where it erroneously decides to use log4j when log4j is not

>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...)

>You can easily fix the problem by taking ownership of the c-l adapter for
>log4j and bundling it with log4j. The only way we can fix the problem is to
>force the users to place them in the same loader.

Ceki  For log4j documentation consider "The complete log4j manual" 

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

View raw message