logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject Re: log4j-sandbox options
Date Tue, 04 Feb 2003 14:40:18 GMT

Hi Ceki,

That sounds fine.  I must have forgotten about this resolution.

Sorry for the bother.


At 03:34 PM 2/4/2003 +0100, you wrote:

>Hi Jake,
>I thought we had this covered... It would fine to have 
>log4j.jar+selector.jar available to the shared class loader. This way 
>log4j+selectors would be accessible to  Servlet Container class laoder and 
>the web-application class loaders. This results in one copy of 
>log4j.jar+selector.jar but multiple logger repositories. There is no 
>absolute need to have selector.jar merged into log4j.jar.
>At 08:28 04.02.2003 -0600, you wrote:
>>One comment I have is that the servlet stuff needs to be run under 
>>WEB-INF/lib of a webapp whereas the selectors need to be wherever an 
>>existing log4j.jar is because there is two-way communication between the 
>>selector and log4j proper.  This is especially true for the 
>>ContextClassLoaderSelector.  The class calling this selector must be in 
>>the WebappClassLoader so that the selector gets a handle on the class 
>>loader to use as a key for the app's logger repository.
>>The problem is that if we package the selectors and the servlets/servlet 
>>context listeners in the same jar file, things will break unless you put 
>>the sandbox jar and the log4j jar in WEB-INF/lib which totally defeats 
>>the purpose of using the custom selector.  With everything in 
>>WEB-INF/lib, log4j already has a unique logging environment and has no 
>>need to use a custom selector.
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message