commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <>
Subject Re: Logging packaging questions
Date Mon, 16 Jun 2003 22:36:35 GMT
>Hence the need to maintain commons-logging.jar AS-IS.
>We already HAVE commons-logging-api.jar, we simply need to add new jar
>files for each implementation 'flavor'.  Consideration could be given to
>including a file that configures the logger,
>though there are pro/cons with that.

I really don't think we want to go down that road.  AFAIK, commons-logging's 
mission is to provide a thin layer between an app and the underlying logging 
package to allow you to plugin different logging packages, not to be a 
logging package itself.


>Richard A. Sitze
>IBM WebSphere WebServices Development
>Nicolas Mailhot wrote:
> >>If the split goes through,
> >>the situation is likely to arise where log4j is used as a
> >>backend, but since log4j is not configured by default, all the
> >>logging will be automatically brocken. Come to think of it, this is
> >>what we have now, without the split, and looks like we are not happy :)
> >
> > Since this is exactly what we have now the split would not make it
> > worse.
>It will. Much worse.
>What we have now can be fixed by removing the 'Class-Path:' entries.
>After that, only those who put log4j on classpath *manually* and do
>not configure it will have their logging brocken.
>If the split happens, any naive user who believes that he can use
>log4j as a backend for commons-logging and does not install
>SimpleLog - or installs it, but does not override the alternatives so
>that log4j is *not* used - will have his logging brocken.
> > So there is no reason not to go for the split because we know the
> > other benefits we'll get.
>I think that working setup is preferrable to better modularization :)
>I'd like to have both, but it looks that we can't.
>Unless you persuade log4j developers to make it self-configured.
> > It is commons-logging responsibility IMHO to do initial log4j
> > configuration if its used - commons is supposed to hide the backend so
> > why should we know something about it ?
>This question is best answered by the bug 13201 description
>    I am requesting that the code added to Log4JCategory in
>    commons-logging-1.0.1 that sets up a default initialization in log4j be
>    removed.
>    Why? When I put 1.0.1 in place of 1.0, I started getting extraneous
>    messages logged to the console. Subsequent research led me to the new
>    initialization code in Log4JCategory. The problem is in the way the
>    initialization code tries to decide if log4j has been configured. It
>    assumes that the root category has been configured with an appender. I
>    happen to have a log4j properties configuration that doesn't configure
>    an appender, so the initialization code couldn't tell that log4j had
>    been configured, it created the default root appender, and I started
>    getting the extraneous messages.
>    I realize there are easy workarounds for my particular problem, but I
>    believe this presents a more philosophical issue. Quoting from the
>    commons-logging api org.apache.commons.logging package description:
>    "The basic principle is that the user is totally responsible for the
>    configuration of the underlying logging system. Commons-logging should
>    not change the existing configuration."
>    The code in question directly violates this expressly stated principal
>    and is inappropriate. Allowing this code to remain opens a Pandora's
>    of attempts to configure the underlying logger, which should be
>    based on the above principal.
> > [ and this part is related to the crossposted message so please add
> > these remarks to the common thread ]
>Leonid Dubinskly.
>To unsubscribe, e-mail:
>For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

Protect your PC - get VirusScan Online

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

View raw message