Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <F369B5B779D1794FB19653920D62D3BD39E935@kossuth.synygy.net>
From: "Inger, Matthew" <Inger@Synygy.com>
To: 'Jakarta Commons Developers List' <commons-dev@jakarta.apache.org>
Subject: RE: [logging] ServletContextLogger
Date: Thu, 27 May 2004 10:29:32 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

Some points:

1.  The classloader for any thread in a servlet container is guarnteed to
    be unique per Web Application (context).  Each Web Application has it's
    own classloader, which is part of the servlet spec.  I'm not sure i
understand
    what your saying here.

2.  I wouldn't be using commons-discovery.  To me, logging is the most basic
    functionality, and shouldn't have dependencies outside of the log
packages.
    The discovery code is very simple (3 methods of relatively small size in
my
    estimation), and would be included directly in the LogFactory
implemenation
    class, or more likely, in a utility class.  The discovery file might
look like:

	org.apache.commons.logging.impl.Log4JLogger
	...

    The order in the file, determines the search path.  When dealing with
multiple
    resources, the order in which the resources are found is undetermined,
and this
    is an issue we'd have to work out.  In most cases, we'll take the first
available
    logger which can be used.  If the user wants a specific one, they can
set a system
    property.

3.  I'd also like to refactor the existing logging classes to seperate each
logger
    type out into it's own package.  ie.
org.apache.commons.logging.impl.log4j.Log4JLogger
    Something like this would make it easier to create multiple build
artifacts, such as:

	commons-logging-1.0.x-api.jar
	commons-logging-1.0.x-log4j.jar
	commons-logging-1.0.x-jdk14.jar
      etc....


    But this is something that can happen at a later date.

Plugging in the discovery mechanism would be the first thing i would do,
then implementation of the ServletContextLogger would come next.  It
would not affect the existing code. It would simply be an alternate
LogFactory implementation.

I am still waiting for my CLA to be processed (been several weeks now), so
I wouldn't be able to commit this myself.


-----Original Message-----
From: robert burrell donkin
[mailto:robertburrelldonkin@blueyonder.co.uk]
Sent: Wednesday, May 26, 2004 5:11 PM
To: Jakarta Commons Developers List
Subject: Re: [logging] ServletContextLogger


On 26 May 2004, at 21:22, Inger, Matthew wrote:

hi matthew

<snip>

> As far as initialization, it could provide a static method (since 
> there's
> only ever
> one ServletContext per web app anyway, a static variable will suffice),
> which could
> be called from the Servlet's init method.  (I'm open to other 
> suggestions
> here, but
> it's the only way i see to make this happen)
>
> public class ServletContextLogger {
>    private static ServletContext context;
>
>    public static synchronized init(ServletContext context) {
>       ServletContextLogger.context = context;
>    }
>
>    ...
> }

the code you propose is unlikely to be safe in a servlet container 
environment. you'd have to use a per-context-classloader singleton. 
ideally, this would have to be held in a weak hashmap (to ensure that 
the context is garbage collection) but probably this should be 
discovered at runtime to allow better compatibility.

i'd probably not see this as part of the default logging compile time 
search (due to the fact that this registration stage is needed) but 
could be a good addition as an optional logger.

it may be a good idea to wait until after the upcoming 1.0.4 release 
before adding any new loggers.

> PS:  I'm also willing to create a new implementation of LogFactory 
> which
> will discover the available log implementations at runtime, rather 
> than the
> compile time strategy which exists now.

sounds interesting. the idea of using commons-discovery to find all 
implementation at runtime has come up before but AFAIK without much 
action.

- robert


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

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