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 2003/01/18 04:47:37 UTC

DO NOT REPLY [Bug 15450] - Ability to set levels for loggers

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=15450>.
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=15450

Ability to set levels for loggers

craig.mcclanahan@sun.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From craig.mcclanahan@sun.com  2003-01-18 03:47 -------
The philosophy of commons-logging was, and always has been, to wrap only the
actual logging calls -- not the lifecycle or configuration of the underlying
logging implementation.  That was left to the application itself.  In your
particular scenario, you could have left the Log4J configuration screens in
place, but only allowed them to be accessed when Log4J is available.  Likewise,
it would be straightforward to build similar screens for JDK 1.4 logging (if
available), or any other logging implementation you want to support.

Going down the path of adding more and more functionality to commons-logging
would lead, ultimately, to writing a complete logging implementation.  That
would be a waste of time, when perfectly good implementations exist already. 
Instead, commons-logging should stay narrowly focused on abstracting just the
logging calls themselves.

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