logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: log4j-sandbox options
Date Tue, 04 Feb 2003 14:34:13 GMT

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

View raw message