Mailing-List: contact log4j-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@jakarta.apache.org>
Date: Tue, 4 Feb 2003 13:04:41 -0600
From: Jacob Kjome <hoju@visi.com>
Reply-To: Jacob Kjome <hoju@visi.com>
Organization: Springfield Nuclear Plant
Message-Id: <10510348971.20030204130441@visi.com>
To: "Log4J Developers List" <log4j-dev@jakarta.apache.org>
Subject: Re[2]: log4j-sandbox options
In-Reply-To: <F73733CC5E11D41189E700D0B74A0C9E0529F4F7@exchange.bevocal.com>
References: <F73733CC5E11D41189E700D0B74A0C9E0529F4F7@exchange.bevocal.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Mark,

Yep,

Hi Mark,

This is exactly why I spoke up about this.  Even if Ceki remembered
the resolution, I don't think the consensus was ever made that clear.

So, at a minimum, we need:

log4j-selector.jar
log4j.jar
log4j-sandbox.jar

I would go further and separate any stuff that uses the servlet API
into its own jar.  Servlet stuff should exist in the WebappClassLoader
and I imagine that there is some sandbox stuff besides the selectors
that we might want to put alongside the log4j.jar in a shared
class loader.  Since servlet stuff shouldn't be shared (and absolutely can't be
shared in the case of servlets/listeners using the
ContextClassLoaderSelector), they should be available in their own jar
to be added to WEB-INF/lib of each webapp independently of anything
else in the sandbox.

So, I propose the following jar:

log4j-servlet.jar
or
log4j-webapp.jar


How does that sound?

Jake

Tuesday, February 04, 2003, 12:31:46 PM, you wrote:

MW> But, does this mean that the selectors should be packaged in their own jar,
MW> separate from the log4j-sandbox jar?

MW> -Mark

>> -----Original Message-----
>> From: Jacob Kjome [mailto:hoju@visi.com]
>> Sent: Tuesday, February 04, 2003 6:40 AM
>> To: Log4J Developers List
>> Subject: Re: log4j-sandbox options
>> 
>> 
>> 
>> Hi Ceki,
>> 
>> That sounds fine.  I must have forgotten about this resolution.
>> 
>> Sorry for the bother.
>> 
>> Jake
>> 
>> 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.
>> >
>> >--
>> >Ceki
>> >
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>> >For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>> 

MW> ---------------------------------------------------------------------
MW> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
MW> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org


-- 
Best regards,
 Jacob                            mailto:hoju@visi.com


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org