Will, what I suggest is placing c-l.jar in your server-level classpath, or in the JVM classpath... and **nowhere else**. If you have any custom Logs or LogFactory or anything put that in the same place. Then you can be sure that each web-app will use the same classes.
This is what I am currently doing. I have code USING c-l at both the server level and at the app level, and it all works fine. Putting the same jar at the server level *and* at the web-app level seems to be asking for trouble. .T. > -----Original Message----- > From: Will Jaynes [mailto:[EMAIL PROTECTED] > Sent: Monday, October 13, 2003 03:14 PM > To: 'Jakarta Commons Developers List' > Subject: Re: commons-logging & classloading > > > > Remy Maucherat wrote: > > > Will Jaynes wrote: > > > >> I was hoping some developers would weigh in on this issue. I expect > >> that this has been discussed before, but I can't find any references. > >> > >> I believe the classloading in commons-logging is broken. The web app > >> use case I describe below is a demonstration of why c-l is broken. The > >> way classloading is implemented makes it impossible to to share > >> components at the J2EE server level. It's clear from looking at the > >> LogFactory.getContextClassLoader() method that the developers > >> explicitly want to use the thread context classloader. But it just > >> causes problems. > >> > >> I went in and changed LogFactory.getContextClassLoader() to simply > >> return LogFactory.class.getClassLoader(), and all my logging problems > >> went away. I can put slide, HttpClient, commons-logging at the server > >> level; and struts, commons-logging, log4j in the web apps. And things > >> work fine and just as I expect them to. > >> > >> So, can someone please explain why commons-logging is implemented as > >> it is? Will anyone consider changing it? > > > > > > I believe the current commons-logging implementation is just fine. > > However, containers which use it (such as Tomcat) must include it in a > > very specific way to have it work fine in all situations. I believe you > > won't experience any problems with Tomcat 5. > > > > The way to use it is what you say: place your logger, its configuration, > > as well as the commons-logging logger plugin (or the full JAR, as you > > wish) in your /WEB-INF/lib. > > > > Remy > > Remy, This how I've handled things up to now. But now I would like to > use HttpClient, which uses commons-loggin. Are you saying that the > proper way to handle components that use commons-logging is to put them > in WEB-INF/lib; that all such components can not be shared at the server > level? > > Will > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
