commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Thu, 09 Dec 2004 23:26:09 GMT
The discovery process is a concern.  It's not trivial.  It only gets worse 
over time.  Enough said.

To be quite frank, here is what I believe to be the right strategy

1.  Implement a "workable" discovery mechanism where it belongs... in 
Commons Discovery.

2.  Have the existing LogFactory attempt to use Commons Discovery, and 
failing that fall back to...

3.  Clean up [for 2.0] the LogFactory mechanisms... simplify, simplify, 
simplify...  minimize, minimize..  I'm advocating regressive behavior with 
this statement.  This is necessary to "fix" the problems we had with 

If you *want* solid discovery, the price should be bringing that it your 
environment.  I think a simple J2SE [single classloader] discovery is 
reasonable for the LogFactory, should hit the 80% user mark.  For those 
that want the 20%, let's please solve the problem in Discovery, and resist 
duplicating the solution in many Jakarta components.


simon <> wrote on 12/09/2004 05:18:37 PM:

> On Fri, 2004-12-10 at 11:52, Martin Cooper wrote:
> > This sure doesn't sound like Commons Logging would be "an ultra-thin
> > bridge between different logging libraries" any more.
> > 
> >
> > 
> > This sounds more like a different package altogether. IMO, we have
> > enough trouble as it is with some people resisting adding a dependency
> > on Commons Logging that the last thing I want to see is a bunch more
> > functionality - and size - added to this component.
> It looks to me like the changes will be just a couple of fairly simple
> new classes for globalisation, and a couple of trivial methods to
> support the JSR-47 "finer" log level. I don't think that's a big deal.
> The "repackaging" of the logging library to separate the "interfaces"
> from the log-library-specific adapters is something that has already
> been proposed on this list, and clearly will *reduce* jar file size
> (though add complexity by forcing users to deploy two jars instead of
> one).
> It is less clear how the proposed changes to the 'discovery' process
> would affect code size/complexity, and I agree a close eye needs to be
> kept on this to make sure commons-logging stays the "thin bridge" it was
> always meant to be.
> Regards,
> Simon

Richard A. Sitze
IBM WebSphere WebServices Development

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

View raw message