Delivered-To: cgu@qos.ch
From: "Payam Mirrashidi" <payam_mir NOSPAM yahoo.com>
To: <java-logging-input@eng.sun.com>
Cc: <cgu@qos.ch>
Subject: Comment on JSR 47
Date: Wed, 13 Jun 2001 19:11:21 -0700
Organization: Ruby Networks, Inc.

JSR-00047 Expert Group:

I am writing in response to a mail by Ceki Gulcu asking for support for the
log4j API. While I don't expect the expert group to radically change the
path that they have chosen so far, I think there are a couple log4j features
that ought to included to the current spec. I will comment on one.

I have been using the log4j API for about 6 months on an almost daily basis.
Previous to that, I had used the ATG Dynamo logging APIs extensively for a
year. Before that I had survived with selective printlns. I have to admit
that I was sold on log4j almost immediately.

Most notably, as I read the current configuration spec, it seems that
runtime file logging is configured on a global instance. That is, it is
possible, via a .properties file, to configure the
java.util.logging.FileHandler class to log to a single file. I do not see a
way to configure multiple file handlers each with a different output file at
runtime without having to write new classes. This is too severe a design
limitation. I understand that this feature could be added programmatically
by using the logging APIs with a propietary configuration format. But I
think a standard mechanism for runtime configuration should be part of the
spec.

One thing this design inhibits is a seperation in logging responsibilities
between programmers and system administrators. Quite often, with server
deployments, the logging configuration is set up to log to multiple files
each for a different target audience. For example, error logs are typically
tailed by processes that send pages/email when new errors are logged.(yes, I
could write a new log handler but sysadmins with perl skills can't do that).
Another case for multiple file logging is the case when problems arise with
a deployment. The runtime logging configuration can be changed easily with
new logfiles being generated with the appropriate logging information for
the person who is interested in it. This allows all the previous deployment
infrastructure to remain unchanged.

In one large Dynamo deployment I worked on, there was a large, fast disk
that was wiped on a hourly basis that was solely for the use of developer
debug logs. The errors and warning logs, however, were logged to slower,
smaller RAID disks that were backed up on a daily basis. The flexibility to
do all of this through runtime configuration file changes was a key aspect
of the setup.

log4j defines two different but powerful configuration file formats. The
ease of use and the expressiveness of these formats should not be
discounted. My biggest complaint about Dynamo logging is that it is
exceedingly difficult to configure at runtime. It is important for the
expert group to define configuration formats as expressive as the log4j
format otherwise there will necessarily arise several competing formats that
allow better, more expressive, runtime configuration.

----
Payam Mirrashidi