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.

Reply via email to