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=28237>. 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=28237 [PATCH] Use the commons logging LogFactory also in Fop.java ------- Additional Comments From [EMAIL PROTECTED] 2004-04-19 11:30 ------- Glen, One more... 3) setLevel() has been part of the Log4J API since before Logger was born; i.e. when Logger was Category. What Sun is up to is summed up neatly in the java.util.logging description: http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/package-summary.html#package_description The Log4J documentation also mentions the critical importance of logging for debugging, quoting Kernighan and Pike on the superiority of judicious logging over interactive debuggers. (Yes!) I discovered the limitations because I started the process of converting the recently introduced 1.4 logging in alt-design to use commons-logging. At some stage I will probably subclass commons-logging and apply that, so that at least the logging invocations will look the same. Thanks, Glen, for taking the trouble to look up the details of the usage of commons-logging. Unfortunately, Craig doesn't address the issue. Currently, commons-logging *forces* us to use the kind of "work-around" he describes. But that work-around is only necessary because of the absence of setLevel(). Not including it is an ideological decision which cripples the logging. In the absence of commons-logging, users of 1.4, Log4J and Lumberjack can all setLevel dynamically. Craig might have decided that that is a Very Bad Thing, and that we must be protected from ourselves. But the four points have no bearing on whether to provide setLevel(); they are all about getting the native logger, which users are forced to do by the refusal to include setLevel in the interface. If it were included, there would be no need to get the native logger. The real workaround is to modify the interface and the implementations. All any of us have to do is understand the arguments. If they persuade us, it doesn't matter how many or how few have adopted it. Likewise if they fail to persuade.