commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: commons-logging & classloading (continued)
Date Sun, 02 Nov 2003 22:02:26 GMT
IMHO the right way to solve the issue of loading Log implementations is to 
use the existing system property to load a different LogFactory 
implementation. this implementation can then override LogFactoryImpl and 
load using whatever classloader is most appropriate.

the issue then becomes how to load the initial LogFactory implementation. 
it seems to me that at the moment given a suitable stuffed up classloading 
configuration, the LogFactory implementation will be loaded by the context 
classloader and not be assignable. the current LogFactory implementation 
looks like it will throw a configuration exception even if a compatible 
implementation of the class is available in the class classloader for 
LogFactory.

i can see two improvements we might make for users faced with this 
situation:

1. we could introduce a system property flag which (when set) would force 
the LogFactory class classloader to be used.

2, a more sophisticated implementation for the loading of the LogFactory 
implementation that would try to load the class from the LogFactory class 
classloader if the assignment fails. since (at the moment) we throw an 
exception in this circumstance (from would be very difficult to recover 
from), i don't think that add this extra step would do any harm.

comments anyone?


BTW one feature that i've been wanting for some time is the ability to 
turn off all configuration exceptions and go with a reliable default 
(probably a LogFactory nested class). there are times when library code 
failing to initialize logging is not a good enough reason to stop the 
executing of the application. maybe a system property could be added for 
this.

again, comments please.

- robert

On Thursday, October 30, 2003, at 10:36 AM, Ojares Rami EINT wrote:

> Well put Norbert.
> I think that since classloading and threads are such complex
> issues there should be a way to not use the pattern
> of loading the implementation from thread's context classloader.
> (Hint to Craig :)
>
> - rami
>
>> -----Original Message-----
>> From: Norbert Klose [mailto:nklose@mail.com]
>> Sent: Thursday, October 30, 2003 12:21 PM
>> To: commons-dev@jakarta.apache.org
>> Subject: commons-logging & classloading (continued)
>>
>>
>> Hello,
>>
>> i currently use Tomcat 4.1.27 bundled with commons-logging
>> 1.0.3. My own webapp i'm working on also uses commons-logging,
>> so i include a copy of the jar file into the WEB-INF/lib
>> directory to be protable to other servlet containers that does
>> not include the commons-logging package. I found some
>> discussions in the mail archive that is about commons-logging
>> and its class loading strategy. But as i could not found an
>> anwser to my problem, i post my problem here again, hoping to
>> get a hint for a solution (or maybe to settle on a new consens).
>>
>> The problem is, that when tomcat wants to anser a HTTPS
>> request it instantiates a Http11ConnectionHandler which
>> processes the connection.
>> The Http11ConnectionHandler instance itself instantiates a
>> JSSE14Support class which itself instantiates a
>> org.apache.commons.logging.Log implementation class. Because
>> the thread that runs the Http11ConnectionHandler has the
>> WebappClassloader of my web application as its
>> context class loader (which ist used by commons-logging to
>> load the Log implementation (logClass)), BUT the
>> org.apache.commons.logging.Log interface itself was loaded
>> from the Common StandardClassLoader, the predicate in
>> LogFactoryImpl.getLogConstructor()
>>
>> 	(!Log.class.isAssignableFrom(logClass))
>>
>> is false, so that LogFactoryImpl.getLogConstructor() throws a
>> LogConfigurationException. Because both classes are loaded
>> from different classloaders.
>>
>> IMHO what commons-logging MUST ensure to work correctly is,
>> that the logClass is loaded from the same classloader than the
>> Log.class is and this is not guaranteed by the current
>> implementation! For example
>>
>>    protected static ClassLoader getContextClassLoader()
>>        throws LogConfigurationException
>>    {
>>        return Log.class.getClassLoader();
>>    }
>>
>> would do. BUT to keep the current implementation what about
>> changing LogFactoryImpl.getLogConstructor(), so that the
>> correct predicate is evaluated?
>>
>>    protected Constructor getLogConstructor()
>>        throws LogConfigurationException {
>>
>>         ...
>>
>>            logClass = loadClass(logClassName);
>>            ___logClass___ =
>> loadClass("org.apache.commons.logging.Log")		//
>> something like this...
>>            if (logClass == null) {
>>                throw new LogConfigurationException
>>                    ("No suitable Log implementation for " +
>> logClassName);
>>            }
>>            if (!___logClass___.class.isAssignableFrom(logClass)) {
>>                ...
>>            }
>>
>>        ...
>>
>>    }
>>
>> The problem with the current implementation is, that
>> commons-logging can not rely on the fact that the threads
>> current context class loader is the classloader that the class
>> (like the JSSE14Support above) wants to get its logging
>> implementation from!!!
>>
>> Is there a chance to get a consens on that, or at least to
>> think about changing the current implemetation making it more
>> reliable ?
>>
>> Kindly regards,
>> Norbert.
>> --
>> __________________________________________________________
>> Sign-up for your own personalized E-mail at Mail.com
>> http://www.mail.com/?sr=signup
>>
>> CareerBuilder.com has over 400,000 jobs. Be smarter about your
>> job search
>> http://corp.mail.com/careers
>>
>>
>> ---------------------------------------------------------------------
>> 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
>


---------------------------------------------------------------------
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