commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: commons-logging & classloading
Date Mon, 13 Oct 2003 22:17:51 GMT
Will Jaynes wrote:

> Yoav,
> I, too, use log4j directly in my own classes. But we all use 
> components that use commons-logging, so we have to deal with it.
> No one has yet described for me a use case where the current 
> commons-logging classloading strategy is necessary or even correct. 
> Whereas I have described a use case where it clearly fails, and have 
> implemented a code change that fixes the problem for my use case.

If your webapp has its own private implementations of Log or LogFactory, 
you definitely need the current class loadng design.

Before you say "nobody should need that", this feature can be critically 
important when integrating enterprise scale applications together.  A 
couple of illustrative examples might help you understand the reasoning:

* Large scale shop has different conventions for logger names than
  the typical Jakarta pattern (fully qualified class name == logger name),
  and wants all installed apps to follow the shop standards.

* App server hosting lots of webapps, and wants the actual logger names
  to include the webapp name so that they can be physically separated.

Either of these is pretty easy to deal with by creating a custom 
LogFactory implementation, and shipping it inside your webapp.  The nice 
thing about this approach is that the change is transparent to the 
actual code that does the logging -- the only visible impact is the need 
to configure (in /WEB-INF/classes) to select 
the custom implementation.

> As far as I can tell, commons-logging is just plain broken. But I have 
> a lot of respect for the developers here, and clearly they have 
> thought about this issue a lot. So I'm left wondering what I'm missing.
> Is it an excepted implementation fact that components that use 
> commons-logging can't be shared at the web app server level?

No.  As others have pointed out, you can do this (and Tomcat already 
does this).

> Will 


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

View raw message