commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Morgan Delagrange" <>
Subject Re: Problems with commons-logging
Date Wed, 06 Feb 2002 05:21:06 GMT
I agree with Tim's basic sentiment.  We could design a generic configuration
engine, tweak it to death, and it could still be unsatisfactory wrt. tapping
the essential features of all the logging variants.  And, in any case, a
generic logging interface does not need to be included in the first release;
we can always add it later if there actually is a need.  It would not even
need to constitute a revolution, since it should be possible to place a
configuration layer on top of the logging facade without changing existing

Speaking as a user of logging APIs, a generic configuration interface would
be a non-feature to me.  The first thing I would do is explore the API of
the underlying logger implementation, since it would always have more
features than the abstraction.  Log4J for instance provides lots of
flexibility with the configuration of its appenders (including custom
appenders); that would be difficult to capture in an interface that also can
configure LogKit without lots of unsupported options.

We need a logging abstraction, because we have to be able to program
components in a log-agnostic fashion.  Abstracting the _configuration_ of
logging is not strictly necessary however, since it does not change the way
components are developed at all.

- Morgan

----- Original Message -----
From: "Tim Vernum" <>
To: "'Jakarta Commons Developers List'" <>
Sent: Tuesday, February 05, 2002 10:38 PM
Subject: RE: Problems with commons-logging

> From: Paulo Gaspar []
> > > Configuration is not done by a components, therefore it is
> > > outside the scope of the common-logging package.
> >
> > I still do not get WHY you really need to impose such
> > limitations.
> 1) The more you add the more you have to support.
>  If someone adds code to commons-logging to do basic
> configuration, then commons has to support it.
>  You have to make sure it's not creating security problems.
>  You have to support it for any future logging kits that
> commons-logging supports.
> 2) The more you add the more users expect.
>  It's a "slippery slope".
>  If you add a bit of configuration, then people want
> "a bit more".
> 3) The more you add, the more people have to download.
> The idea is to keep the component small.
> 4) We don't need YetAnotherLoggingAPI.
> This is a minimal wrapper around a few logging toolkits.
> If you keep adding more functionality, you end up replicating
> log4j/logkit. We don't need that.
> 5) If you add it, you've got to do it properly.
> What methods will you add?
> setConfigurationFile( String filename )
> What about the SimpleLog, how do you configure that?
> What about logging kits that don't use file based
> configuration?
> Once you walk that path, there's a heck of a lot
> of work do to.
> This component has a purpose.
> It fulfills that purpose without needing a configuration
> mechanism.
> Don't go adding one.
> At some point you need to draw a line in the sand and say
> "This is the scope of the project"
> This e-mail and any attachments are confidential and may contain copyright
material of Macquarie Bank or third parties. If you are not the intended
recipient of this email you should not read, print, re-transmit, store or
act in reliance on this e-mail or any attachments, and should destroy all
copies of them. Macquarie Bank does not guarantee the integrity of any
emails or any attached files. The views or opinions expressed are the
author's own and may not reflect the views or opinions of Macquarie Bank.
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Do You Yahoo!?
Get your free address at

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

View raw message