Mailing-List: contact log4j-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@jakarta.apache.org>
Message-Id: <5.2.0.9.0.20030205000338.01d25f90@mail.qos.ch>
Date: Wed, 05 Feb 2003 00:04:18 +0100
To: "Log4J Developers List" <log4j-dev@jakarta.apache.org>
From: Ceki =?iso-8859-1?Q?G=FClc=FC?= <ceki@qos.ch>
Subject: RE: log4j-sandbox options
In-Reply-To: <F73733CC5E11D41189E700D0B74A0C9E0529F4F7@exchange.bevocal.
 com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed


No, it just means that there is no absolute necessity to package the 
selector classes within log4j.jar.

At 10:31 04.02.2003 -0800, you wrote:
>But, does this mean that the selectors should be packaged in their own jar,
>separate from the log4j-sandbox jar?
>
>-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
> >
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

--
Ceki 


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