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-07 20:37 ------- Glen, SimpleLog log = new SimpleLog("FOP"); log.setLevel(SimpleLog.LOG_LEVEL_INFO); driver.setLogger(log); driver.getLogger().info(version); options = new CommandLineOptions(args); This code in Fop.java has three problems: 1. SimpleLog is configured by Java system properties. The second line above overrules that, against reasonable expectations of users. If a user does nothing, SimpleLog selects a reasonable default: info. 2. The command line options -d and -e are used to configure the Log object of the options object. This log is not passed on to driver, and thus gets lost. 3. Commons logging is also configured by Java system properties. A user may configure it to use a certain logging implementation, e.g. Log4J. Hard coding a SimpleLog instance goes against reasonable expectations of users when we advertise that we use commons logging. If a user does nothing he gets the JDK 1.4 logging if he runs that version, and SimpleLog otherwise. I believe that my patch makes Fop's logging behaviour consistent with the claim that we use commons logging, and with the documented configuration options of commons logging. And it makes it consistent internally. Note that Jeremias changed the code of many classes to use commons logging. SimpleLog logs to stderr; only redirection sends it to a file (and that is impossible under MSWindows command and cmd shells). For command-line users that seems appropriate; other users should select and configure a log implementation that suits them. With commons logging configuring logging via command line options is not really appropriate. This is all I discovered. I went into this because I was hit by the inconsistencies in the current logging. For example, currently getlogger().debug(xxx) in FOText.java will not give you anything for the reasons I described under 1 and 2 above. Regards, Simon