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:[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
