Delivered-To: cgu@qos.ch
From: Steve Wingfield <wingfields NOSPAM hotmail.com>
To: "'java-logging-input@eng.sun.com'" <java-logging-input@eng.sun.com>
Cc: "'cgu@qos.ch'" <cgu@qos.ch>
Subject: JSR47 enhancement request
Date: Wed, 13 Jun 2001 11:32:54 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)

Dear Sun,

I'm very pleased to see that JDK1.4 is going to have a logging API associated with it.  And in particular I think the JSR47 specification has some good ideas behind it.  However, I'm concerned that, in its current form, it contains some shortcomings that will affect its usability and performance.  Namely,

1.  Performance -- It seems that setting the log level of the root logger in JSR47 recursively sets the log level of all descendant loggers.  The projects I've worked on tended to have trees with a large depth to them, which would result in a performance hit under this scheme.  Allowing descendant loggers to determine their log level as needed would seem to be more performant.


2.  Usability -- There are a number of areas I'm concerned about in terms of usability.  The following lists the major ones:

Error Handling -- I believe a logging facility should be as unobtrusive as possible.  In its current form, it looks like JSR47 requires programmers to explicitly catch potential runtime exceptions to avoid a program crash.  In my experience, it's been more useful to have a logging package mostly suppress errors (perhaps, at minimum, reporting an error to a standard location like stdout/stderr), rather than having to code around error handlers. 

Setting of Log Levels -- I'm a little concerned about the fact that setting a parent logger's log level will overwrite all of its children's log levels.  I'm not convinced that it will always be convenient to first set a parent logger's level prior to setting a child's log level.  But in the JSR47 scheme, if you don't set the log levels in the correct order, you will unintentionally overwrite a child's log level.  I'm afraid that this will at minimum cause confusion, and at worst be intractable in some cases.

Inheriting Parent Handlers -- It doesn't seem like this is explicitly possible in JSR47.  Global handlers provide some of this functionality, but they are not as flexible as the idea of true handler inheritance.  The same limitation exists for resource bundles.

Supporting Multiple Concurrent Handlers -- It doesn't seem that you can have a logger write to more than one handler at a time.  This capability can be  extremely useful at times; for example, in tech support cases, it's nice to be able to add a socket as a log recipient, in addition to the usual log file.


There are some other areas where I believe improvements could be made, such as log entry formatting, and a more extensive list of log handlers, but the preceding are the ones that really concern me. 


Currently there exists another java logging package called log4j, available from http://jakarta.apache.org, that addresses these items.  I've been using it on various projects, and have been extremely impressed with its robustness, flexibility, and ease of use.  I'm certainly not your stereotypical die hard fanatic that, once familiar with a software package, will never sway from it or try anything new.  In fact, I'm eager to learn and become proficient with any Java standard API's that come out.  However, the issues I mentioned above are, I'm afraid, too weighty to allow me to use the current form of the JSR47 specification in place of the package I've been using.  I hope that you'll take these comments into consideration and either adopt log4j as the logging API for JDK1.4, or at least revise the current specification to handle the above listed items.



Sincerely,
Steven Wingfield