commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: commons-logging & classloading
Date Tue, 14 Oct 2003 15:56:13 GMT
Ojares Rami EINT wrote:

>Craig,
>
>Would it be difficult to somehow parametrize the classloading in commons-logging.
>I just commented out small portion that resorts to thread classloader.
>To me it seems that it would be very trivial to give the user possibility
>to disable thread classloading (which still could be the default).
>  
>

That would lead to a Catch-22 situation, because the thread context 
class loader is used to load the commons-logging.properties file as 
well, and you would want the setting to take effect first :-).

More seriously, letting people disable this would be a disaster in a 
servlet container environment, which is a very common use case for code 
that uses commons-logging.  More than a few people on this thread have 
described exactly how to set up and use it successfully, allowing each 
individual webapp to define their own logging environment.  If you 
turned of context class loading, this would be impossible unless you 
forced every app to have their own copy of c-l, and didn't allow the 
container to have its own (which, among other things, would totally 
break Tomcat 5).

>- rami
>

Craig


>
>  
>
>>-----Original Message-----
>>From: Craig R. McClanahan [mailto:craigmcc@apache.org] 
>>Sent: Tuesday, October 14, 2003 1:18 AM
>>To: Jakarta Commons Developers List
>>Subject: Re: commons-logging & classloading
>>
>>
>>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 commons-logging.properties (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 
>>>      
>>>
>>Craig
>>
>>
>>
>>---------------------------------------------------------------------
>>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