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 2004/04/20 19:41:06 UTC

DO NOT REPLY [Bug 14155] - Access to underlying native logging provider missing

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=14155

Access to underlying native logging provider missing





------- Additional Comments From pbwest@powerup.com.au  2004-04-20 17:41 -------
I think the discussion here about access to the native logger misses the point.
 Chris Hagman wanted to be able to setLevel().  Because setLevel() is not in the
logging interface or implementations (except SimpleLog), he had to resort to
accessing the native logger.  Everything Craig says about the evils of using the
native logging implementation are correct.  However, the point is not made that
the requirement (for Chris and others) would not exist if setLevel were
available in comms-loggin, as it is in Log4J, 1.4 logging, Lumberjack (I
presume), and even in the humble SimpleLog.  (Why in SimpleLog?  For
consistency, shouldn't SimpleLog have been restricted to external configuration,
including its logging level?)

When others are browsing for solutions to the same problem, they should be made
aware that the "correct" solution, if they do require setLevel() is to subclass
the interface and the logging implementations mentioned above.

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