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