On that topic, is there a reason that Tomcat 5.0.x still uses
commons-logging-api.jar instead of commons-logging.jar? If you're putting
this jar in common/lib, you'd avoid the need for webapps to have to
include commons-logging.jar themselves in order to use the default
functionality.
Craig, you're funny :-D The reason is that any setup other than the current one doesn't work ;-)
Facts:
- The c-l API must be in the system CL
- the implementation of a logger must reside in the same CL as the logger (ie, if there's log4j somewhere, commons-logging.jar must be next to it)
I think the reason why what Craig is suggesting - placing commons-logging.jar instead of commons-logging-api.jar into $CATALINA_HOME/bin - would not work is due to an assumption in commons-logging.jar that its classloader also have access to log4j.jar.
For instance, the org.apache.commons.logging.impl.Log4JLogger constructor (in commons-logging.jar) references org.apache.log4j.Logger (from log4j.jar) as follows:
import org.apache.log4j.*;
public Log4JLogger(String name) { this.logger=Logger.getLogger(name); }
If commons-logging.jar is loaded by the system classloader, it won't be able to resolve org.apache.log4j.Logger unless log4j.jar is also loaded by the system classloader, or the above constructor made an attempt to load org.apache.log4j.Logger using the context classloader, which is how org.apache.commons.logging.impl.LogFactoryImpl.isLog4JAvailable() (in commons-logging-api.jar) loads it:
protected boolean isLog4JAvailable() {
try { loadClass("org.apache.log4j.Logger"); [...] }
where loadClass() uses the context classloader: getContextClassLoader().loadClass(name).
Therefore, commons-logging.jar and log4j.jar must be placed at the same classloading
level, but it is OK for commons-logging-api.jar to be loaded by the system classloader (and still be able to detect if log4j is available).
This is what Remy has been saying.
You're forgetting things in the equation. This would actually work fine (we don't really care if there are multiple Log classes in existence). The problem is a component like Jasper, which lives in common/lib, uses commons-logging, and is loaded while the webapp classloader (which would have a copy of commons-logging.jar) is the context classloader.
BTW, I indeed forgot to upload things in the classloader docs. Feel free to fix things.
Remy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
