commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Inger, Matthew" <>
Subject RE: [logging] ServletContextLogger
Date Thu, 27 May 2004 14:29:32 GMT
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
    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
    The discovery code is very simple (3 methods of relatively small size in
    estimation), and would be included directly in the LogFactory
    class, or more likely, in a utility class.  The discovery file might
look like:


    The order in the file, determines the search path.  When dealing with
    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
    logger which can be used.  If the user wants a specific one, they can
set a system

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


    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
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


> 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 

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message