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.
Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
