commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: commons-logging & classloading
Date Fri, 10 Oct 2003 17:02:46 GMT

Howdy,
I'm tried should be I'm tired in my previous message ;)


Yoav Shapira
Millennium ChemInformatics


>-----Original Message-----
>From: Shapira, Yoav
>Sent: Friday, October 10, 2003 1:02 PM
>To: Jakarta Commons Developers List
>Subject: RE: commons-logging & classloading
>
>
>Howdy,
>I'm sure other developers like myself have been following your thread.
>Personally, I'm tried of commons-logging classloading issues and don't
>use it unless required.  I use log4j directly and am happy with my
>experience.
>
>Search the archives of this, the log4j-user, and the tomcat-user
mailing
>lists, as many people have run into problem using commons-logging in
>webapps, and several creative solutions have been offered, including by
>the authors of commons-logging.
>
>Yoav Shapira
>Millennium ChemInformatics
>
>
>>-----Original Message-----
>>From: Will Jaynes [mailto:jaynes@umich.edu]
>>Sent: Friday, October 10, 2003 1:00 PM
>>To: Jakarta Commons Developers List
>>Subject: Re: commons-logging & classloading
>>
>>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?
>>
>>Thanks, Will
>>
>>Will Jaynes wrote:
>>
>>>  >> Why does LogFactoryImpl in commons-logging
>>>  >> try to load the Log implementation class first
>>>  >> from thread classloader and then loader that loaded this class?
>>>  >>
>>>  >> Is there some kind of design pattern behind this?
>>>  >>
>>>  >
>>>  >One very common :-) use case for commons-logging is inside web
>>>  >applications, where the servlet container provides a class loader
>per
>>>  >webapp (pointing at the classes in /WEB-INF/classes and
>/WEB-INF/lib),
>>>  >plus normally a parent class loader for shared classes and
>resources.
>>>  >The container is required to set the Thead context class loader
for
>the
>>>  >current webapp prior to handing the request off to the servlet.
>>>  >
>>>  >The lookup design pattern in LogFactoryImpl allows webapps to use
>their
>>>  >own version of the log implementation classes.
>>>
>>> With regard to this web app use case, the problem I'm seeing is that
>I
>>> can't share components at the server level if they use
>commons-logging.
>>> What must the configuration of jars and property files look like if
I
>>> have components that use commons-loggin both at the server and web
>app
>>> levels?
>>>
>>> So far, nothing works properly unless all components are at the web
>app
>>> level (in WEB-INF/lib).
>>>
>>>
>>> Here's an example of what can go wrong:
>>> I have slide and HttpClient in at the server level in resin/lib.
>>> HttpClient uses commons-logging, so I have to add commons-logging to
>>> resin/lib. My web app uses Struts, so I've got commons-logging in
>>> WEB-INF/lib, and I use log4j, so log4j.jar is also in WEB-INF/lib.
>(by
>>> the way, I'm using Java 1.4)
>>>
>>> As soon as my web app trys to use HttpClient I get a exception :
>"Class
>>> org.apache.commons.logging.impl.Log4JLogger does not implement Log".
>I
>>> believe that what is happening is this: HttpClient loads with the
>server
>>> classloader. HttpClient wants to log, so it causes Log and
LogFactory
>to
>>> be loaded with the server classloader. LogFactory specifically uses
>the
>>> thread context classloader to look a log factory. The thread context
>>> classloader is the web app's classloader, so it finds LogFactoryImpl
>and
>>> log4j and then loads Log4JLogger, but it is still using the thread
>>> context classloader, so it finds the Log4JLogger in the WEB-INF/lib.
>It
>>> then does a check with Log.class.isAssignableFrom() on Log4JLogger,
>but
>>> since Log and Log4JLogger were loaded with different classloaders
the
>>> test fails and the exception is thrown.
>>>
>>> After a lot of experimentation, the only configuration of jars that
>>> works properly is to put everything in the WEB-INF/lib of each web
>app.
>>>    Commons-loggin has made it impossible to deploy slide and
>HttpClient
>>> at the server level.
>>>
>>> Am I missing something in how to configure this use case?
>>>
>>> Will
>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
>This e-mail, including any attachments, is a confidential business
>communication, and may contain information that is confidential,
>proprietary and/or privileged.  This e-mail is intended only for the
>individual(s) to whom it is addressed, and may not be saved, copied,
>printed, disclosed or used by anyone else.  If you are not the(an)
intended
>recipient, please immediately delete this e-mail from your computer
system
>and notify the sender.  Thank you.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org




This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message