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:28:47 GMT

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.

So, could the sandbox stuff get split up into separate jars with stuff 
using the servlet api being in one jar and any other stuff being in a 
separate jar?


At 11:13 PM 2/3/2003 -0800, you wrote:
>I think we should discuss some options for the log4j-sandbox:
>1) Are there any other items we want to move from the core log4j cvs into
>the log4j-sandbox cvs?  Classes from the varia package?  Move the
>contributor directories?
>2) Should the log4j-sandbox packages be released independently of the core
>log4j package or "in sync"?
>3) Should the log4j-sandbox be released as a single jar or as a package of
>1) I think we should move the contributors directories over.  In this
>regard, I would like to optionally allow contributors to create build.xml
>files to build their code, and have those build scripts called from a target
>in the main build script.  Whether we move over the varia package...I don't
>2) I think it should be released independently.  There is nothing in the
>sandbox right now that requires any features from v1.3, so why not release
>it when we are happy with it?
>3) It depends.  There is a 'core' set of 'official' sandbox classes.  If we
>move over the contributors, and build scripts are submitted, we might want
>to have those build into a separate jar.
>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