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-18 03:27 ------- Glen, Simon, et al. I have a problem with commons-logging. It deliberately leaves the configuration to the user and the underlying logging system. One example of this is in the dynamic setting of log levels. FOP allows a command line (or user configuration) override of the logging level. This code has been the focus of some discussion here. To my way of thinking, such an override is not a configuration issue per se, but extends to be a run-time issue. Consider the situation in which we wish to allow the logging level to be changed during the lifetime of a single FOP instance; to allow, e.g., an administrator to get more information about a misbehaving instance. SimpleLog provides this facility, and it is (was?) used in the -d switch processing. I can't do that if I am using Jdk14Logger, Jdk13LumberjackLogger or Log4JLogger. I don't know whether Log4JLogger supports log level changes, and it doesn't partucularly matter. Jdk14Logger and presumably Jdk13LumberjackLogger do, and it's a very useful facility, even if only to support command line settings. I've taken the issue up on the (overcrowded) jakarta-commons dev list, and been told that it's a configuration issue, and that SimpleLog has the facility because there is no underlying logger. I don't see it, but it's not worth arguing about there, especially as it was suggested that I subclass the relevant interfaces and classes if I wanted the facility. That seems to be the way to go. The alternative is to drop back to the native logger whenever a change of level is required, which seems to me to rather defeat the purpose. Simon's original point I think ran counter to this proposal ("create a hard-coded SimpleLog instance with the appropriate log level set"). Note, though, that the behaviour of the default common-logging LogFactory is to create a single log instance *of any given name*. If we create a log named "FOP" (or "org.apache.fop" if we are following the 1.4 recommendations), it is not going to interfere with the logging of any other applications, but the user will expect to see changes to the level reflected in the Fop log (but see configuration details below). If users have set up debugging in the user configuration file, we ought to give them debug logging. If there is a conflict with some other setting, it is the user's responsibility. If there is a command line switch for debugging, the requirement is even more definite. The default logging selection behaviour is quite complex: Find a LogFactory a system property named org.apache.commons.logging.LogFactory JDK 1.3 JAR Services Discovery - a resource named META-INF/services/org.apache.commons.logging.LogFactory properties file commons-logging.properties: property org.apache.commons.logging.LogFactory else default LogFactory The default LogFactory looks for: configuration attribute org.apache.commons.logging.Log else system property org.apache.commons.logging.Log else if Log4J available, Log4JLogger else if 1.4, Jdk14Logger else SimpleLog I suspect that Jdk13LumberjackLogger might be in there between Jdk14Logger and SimpleLog. Whether the LogFactory that is in use is well behaved or not will depend on configuration details which are deliberately beyond our control, but the JDK and default LogFactory both guarantee a single instance of a Log of a given name. This seems to satisfy one of Simon's difficulties. "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." If users are specifying a logging implementation which does *not* behave in this way, and in obeying their instructions about, say, debugging, we go over the top of their entire server logging, they need to fix their instructions to Fop or use another logger. I agree with Simon that, in the absence of any specifics, we make no changes to the inherited logging environment. "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." Agree. "SimpleLog logs to stderr; only redirection sends it to a file (and that is impossible under MSWindows command and cmd shells)." I didn't realise there was no redirection facility for 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." It remains a possibility at the user's discretion, and I think we need to support it. "... isErrorEnabled() means error level enabled and perhaps more verbose." The six logging levels used by Log are (in order): 1. trace (the least serious) 2. debug 3. info 4. warn 5. error 6. fatal (the most serious) I.e., warn is a superset of error. To repeat, I think we should subclass commons-logging to provide setLevel and getLevel, which can be no-ops if the underlying implementation does not support them.
