commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <dgraham1...@hotmail.com>
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 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: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message