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-09 10:09 ------- Glen, > (a) why place within isDebugEnabled() and isWarnEnabled() > conditionals, why does this matter? To be as reticent as possible. If a user uses -d but his configuration also sets the log level to debug, he already has what he wants; skip the command line option silently. Similarly with -q. > (b) one conditional is !isDebugEnabled() with a negative but the other > is the positive isWarnEnabled()--was this a bug? -d and !isDebugEnabled() means that the user does not yet have debug log level but requests it, so we have to do something. -q and isWarnEnabled() means that the user still has warning level or a more verbose level on but requests quiet mode (error level), so we have to do something. > (c) Finally, did you actually mean isErrorEnabled() for the latter? No, isErrorEnabled() means error level enabled and perhaps more verbose. We need to ensure that we are not more verbose than error level, that is, !isWarnEnabled(). For the dumpConfiguration method of CommandLineOptions, if the user requests -x but does not set debug log level, he sees no configuration dump. That does not serve the user well. My patch checked that and used a debug enabled SimpleLog in that case. Alternatively, it might be a good idea to show the configuration at info log level; after all, this is information that the user explicitly requested. Regards, Simon
