[PATCH] Use the commons logging LogFactory also in

------- 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
  properties file
       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

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."

"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.

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
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

 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

Reply via email to