tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Why commons-logging-api.jar?
Date Thu, 24 Apr 2003 19:49:41 GMT

On Thu, 24 Apr 2003, Costin Manolache wrote:

> Date: Thu, 24 Apr 2003 12:26:04 -0700
> From: Costin Manolache <>
> Reply-To: Tomcat Developers List <>
> To:
> Subject: Re: Why commons-logging-api.jar?
> Craig R. McClanahan wrote:
> >
> >
> > On Thu, 24 Apr 2003, Costin Manolache wrote:
> >
> >>
> >> 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.
> >
> >
> > Won't this still work if the code in log4j-commons-logging uses the Thread
> > context class loader to load the Log4J classes?  That will pick up the
> > Log4J classes from the webapp, if they are there.
> Tried that - doesn't work.

Even with the current c-l code (1.0.3)?

> The code in log4j-commons-logging uses log4j classes directly - there is
> a Category field, etc. We could use introspection instead of using the log4j
> API directly - but that would slow everything down.
> > I recently added a bunch of unit tests in commons-logging to explore the
> > various class loader scenarios, and it appears to me that the Log4J
> > adapter in commons-logging.jar should now work correctly in a multi class
> > loader environment, with Log4J in either the child class loader or the
> > same class loader.
> I'll try this.
> Have you run the tests with JDK1.3 too ? I never got it to work - when
> Log4JLogger is loaded, it is loaded from the parent loader, and it needs the
> fields - of type org.apache.log4j.Logger, which are not in the same loader.

Haven't tried it under 1.3 because it is not relevant to my needs, but
that is an important use case for Tomcat in general.

> At least at the time I tried this, the class loader that loads Log4jLogger
> couldn't figure out that it has to use the thread loader.

OK, I'm starting with an assumption that the "log4j-commons-logging" code
we are talking about is classes like
org.apache.commons.logging.impl.Log4JLogger, which has references to
classes in org.apache.log4j, right?

If so, it looks like the key issue is in the constructor, where we say:

  public Log4JLogger(String name) {
    this.logger = Logger.getLogger();

and the question is where does org.apache.log4j.Logger get loaded from.
I'll bet we can deal with that via specifically loading this ourselves,
and using reflection to call the static method -- I'll try experiments
later this afternoon.

This still depends on Log4J internally doing things in a fashion that is
sensitive to thread context class loaders (i.e. the o.a.l.Logger class has
to be careful where *it* loads other Log4J classes from), but that is not
something that c-l can do anything about.

> Costin


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

View raw message