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?
Jake
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 jars? <my-opinions> 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 know. 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. </my-opinions> -Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
