commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <>
Subject Re: Logging packaging questions
Date Mon, 16 Jun 2003 22:33:53 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.

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

   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:

View raw message