You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bu...@apache.org on 2002/10/02 15:06:09 UTC
DO NOT REPLY [Bug 13201] New: - Remove default log4j configuration

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13201

Remove default log4j configuration

           Summary: Remove default log4j configuration
           Product: Commons
           Version: 1.0.1 Final
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Logging
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: stevencaswell@apache.org


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.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>