commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: Problems with commons-logging
Date Wed, 06 Feb 2002 22:07:38 GMT

On Wed, 6 Feb 2002, Paulo Gaspar wrote:

> Date: Wed, 6 Feb 2002 21:05:21 +0100
> From: Paulo Gaspar <>
> To: Jakarta Commons Developers List <>,
> Subject: RE: Problems with commons-logging
> Hi Craig,
> Although Costin defended all the reasons to add a bit of configuration
> much better than I would be able to do, there are a couple of options
> to consider.
> The rest goes inline:
> > -----Original Message-----
> > From: Craig R. McClanahan []
> > Sent: Wednesday, February 06, 2002 5:16 PM
> >
> > On Wed, 6 Feb 2002, Paulo Gaspar wrote:
> >
> > >
> > > Hey, I am talking about the really minimal "log to a file"
> > > configuration that any logger supports and drawing the line
> > > after that.
> > >
> >
> > The "any logger supports" statement is why this proposal is on the
> > slippery slope.  IMHO, the commons-logging API itself should not touch
> > configuration at all.
> >
> > Configuration is a feature of a particular *implementation* of logging.
> > The implementations we wrap all have their own configuration mechanism.
> > So does the simple logger implementation that writes to System.out (which
> > uses system properties).
> Using Velocity is made much easier for the beginner because there is a
> default logger configuration quite similar to what I am defending.
> It is the practical case.

Why isn't picking a particular logger (by name) sufficient?  The default
for this can be preconfigured (we do this in Digester already, for
example), and a component can make it easily overrideable.

The use case I worry about is a large application involving tens or
hundreds of components that use logging.  The admin of such an environment
is *not* going to want to understand the quirks of configuring how each
component uses logging -- he or she is going to want to know what logger
names you use (this should be documented for each component), so that the
log output for that component can be merged with or split from log
messages for other components (i.e. using common appenders or not in
Log4J) as appropriate.

Doing a half-assed job of logging configuration is much worse, IMHO, than
doing nothing and saying "logging configuration is a feature of the
application, not of the component using the commons-logging APIs".

> > If that's not enough for you, the appropriate step is to write a slightly
> > more sophisticated implementation of the simple logger that configures
> > itself through whatever mechanism it wants to use.
> Yes, it should always be easy to separate the configuration bit but:
>  - I think its usefulness is big enough that it deserves to be a commons
>    thing instead of just my thing;
>  - It looks silly to have another project for that.

You don't need another project.  LogKit, Log4J, and Merlin logging already
self-configure -- and this self-configuration does just fine without the
addition of the method you are proposing.

> > (Paulo, your argument on this philosophical issue made it clear that data
> > conversion, for example, is a feature of a DynaBean implementation, not
> > the DynaBean interface itself :-).
> Yeah, I like to:
>  - keep thinks (especially interfaces) minimal;
>  - separate features and concerns...
> because that opens the way to multiple options (and multiple combinations
> of options) while allowing that those not using a feature do not have to
> "pay" for it.
> And I stick to those principles on this issue too. There must be separation
> enough (on packages for sure and maybe even on jars) that the configuration
> stuff does not have to be there for those that do not use it.
> I just think that it is overkill to make another project for this.

It's not another project -- it appears to me that you're proposing a
duplication of something that already exists in the loggers that matters.

> BTW... DynaBeans... they are still not minimal enough for much of the
> stuff I am doing. I have been thinking if I could use them instead of my
> "Records" but the extra bean (indexed properties and so) stuff really
> gets on the way for many things (e.g.: "moving data with names") because
> its interface promises too much.
> Me thinks there could be DynaBeans on top of Records. I will try to build
> a sandbox project around my Records and (the load of) related stuff and
> we probably can find synergies later.

That's a perfectly reasonable implementation of the DynaBean API.  If it
requires additions to, then it probably could be factored
better (sheesh, I'm starting to sound like the IoC advocates :-).  If it
needs reductions to the existing API, let's talk.

> Well, even Records are not my basic layer. My basic layer is a set of
> interfaces and wrapper and utility classes that are letting me operate on
> "named values" in many ways I was not foreseeing a couple of months ago.
> I will get back on this later.
> > Craig
> Have fun,
> Paulo Gaspar


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

View raw message