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 commons-logging.properties 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.
David
******************************************* 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 commons-logging >>backend, but since log4j is not configured by default, all the commons-logging >>logging will be automatically brocken. Come to think of it, this is exactly >>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 (http://issues.apache.org/bugzilla/show_bug.cgi?id=13201):
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 box of attempts to configure the underlying logger, which should be resisted based on the above principal.
> [ and this part is related to the crossposted message so please add > these remarks to the common thread ]
Done!
Regards,
Leonid Dubinskly.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
