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 18:05 ------- ------- 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. > Perhaps, but not many others appear to be thinking this way. A considerable statement, given all the apps--Tomcat, Axis, Struts, POI, Tapestry, Turbine, etc., etc.--currently using commons-logging as-is. The logging level *is* the prerogative of the user--they decide whether or not they want to see "info" or "debug" statements. We don't adjust the log level of the logger, instead we declare the desired level of the message to be displayed. People choose debug level, or info level, and the app stays with that level. When there *are* misbehaving instances, those error messages should be given "warn", "error", or "fatal" levels--which guarantees that they will show up in any logger with a "debug" or an "info" setting. (i.e., Loggers *will* print out the messages of more severe errors than that of what they are assigned for. It is just that they will not display less severe errors.) >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. > Actually, maybe we don't really need to consider it. After all, you think the folks at Tomcat, Turbine, et. al. have never considered that situation--have never needed to? All of them came to same conclusion--even under presumably much more demanding circumstances that FOP would have: the logging level is to be set by the user. Craig McClanahan of Sun is probably the lead developer on Tomcat, Struts, and Commons-Logging, and has been on all three for several years now. If programs not being able to set the logging level was an actual problem, it probably would have been long identified and fixed by now. I believe the C-L team came to the conclusion that would cause more headaches than it solves. I see two logical problems with the argument that the logging requirements of FOP go beyond what might be needed by a servlet container, J2EE server, or Web framework environment--i.e., the motivation for subclassing: (1) FOP primarily runs *on* servlet containers, J2EE servers, and in Web framework. But these servers don't need the ability to set the log level--they're not asking for it--so why do we? (2) Our programmatic cousins--Xalan and Batik--don't even use logging to begin with. (Sometimes I'm unsure if we even need it ourselves!) If it is indeed true that it would be unworkable if FOP cannot set the logging level, would it not follow that Xalan and Batik are immediately DOA because they don't even have loggers? What *is* important for us, however, is that the error messages printed out for the "misbehaving instance" be detailed enough so the situation can be reproduced. >SimpleLog provides this facility, and it is (was?) used in the -d switch >processing. > No, that's not a runtime option--that's a command-line option that is fixed for the life of the report generation. This option was removed in my last patch, because it was quietly overriding what they have set up in C-L locally, and it was only there for reasons of backward compatibility, which can't be deemed much of an issue anyway given that we've switched the logger. >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 moved the settings into the fop.bat and fop.sh files in my last (attached) patch. I'm currently unsure how sufficient that is. You do raise a valid point here, however, CL will not allow us to use command line settings to change the logging level. The user needs to read up on the logger that they have chosen, and configure it according to that logger's directions. Logging is truly a "configuration" item in the Java world. > >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. > Actually, I think it *is* worth arguing about over there--the committers there have studied logging for some time, they get all the debates and issues day in and day out. What they (and Sun, with its 1.4 logger) are telling you--logging is a configuration and not a runtime issue--should carry some weight with you. >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). > Yes, and for the JDK1.4 logger in particular, you just need to edit the logging file to specify that logger the designated for class "X" is to have "Y" level of logging capability. The user can already override it to his heart's content. SimpleLog can't do that (NoOpLog is also pretty constrained ;)--so if the user wishes this type of overriding they should switch to a different logger. (JDK1.4 logging is what 1.4 users will get by default anyway.) > >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. > Which in my last patch, I removed, so there will be no confusing conflicts to contend with. Commons-Logging means commons-logging. If users have problems with its functionality, C-L is the place for them to take their concerns, to make sure they are met in the next release. It would be detrimental for everyone IMO to have each app using C-L override it (e.g., with command line settings) with something different. >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." > Actually, this would be only a difficulty if we wanted to retain this behavior of overwriting what they set up for C-L. I disagreed with setting up extra loggers on top of what the users have already configured--in this case, losing backwards compatibility is the lesser of two evils IMO--and so removed these options from my latest patch. >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. > I don't think so--currently, the best solution appears to be for you to put an enhancement request to commons-logging for them to provide that functionality. Let's see what others say--users, CL developers. But if the other apps aren't requesting this functionality, and they are mostly of one voice that programs should not be adjusting the user's choice of logging levels, then that would appear to be the way to go for us. To a large extent, what you're telling us is that the users of Commons-Logging, along with the C-L developers themselves, are in error. Obviously, you have a tough case to make, and I think we need more convincing examples. What is so special about FOP that it needs to make runtime switches of the logging level, something that none of the (many) other C-L using apps need? Thanks, Glen
