avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Simons" <m...@leosimons.com>
Subject RE: Logger package
Date Wed, 28 Mar 2001 08:42:53 GMT
Here's an overview of the current logging setup...

Logging is a system level service. As such, Avalon should provide
this to apps building on top of it. To do so, LogKit (in
org.apache.log) was written. This is a lightweight logging
tool, offering all features Avalon itself needs/wants.
Because the main active maintainer of Avalon is also the main
active maintainer for LogKit (i.e. Peter Donald), if Avalon
needs a new logging feature, it is easily added.

Recently another logging tool, Log4j, has been added to the
Jakarta project. Log4j is bigger and has a host of features
LogKit does not provide. From its FAQ:
- log4j is optimized for speed.
- log4j is based on a named category hierarchy.
- log4j is fail-stop but not reliable.
- log4j is not restricted to a predefined set of facilities.
- Logging behavior can be set at runtime using a configuration
      file. Configuration files can be property files or in XML format.
- log4j is designed to handle Java Exceptions from the start.
- log4j can direct its output to a file, the console, an
      java.io.OutputStream, java.io.Writer,
      a remote server using TCP, a remote Unix Syslog daemon, to a
      remote listener using JMS, to the NT EventLog or even send e-mail.
- log4j uses 5 priority levels, namely DEBUG, INFO, WARN, ERROR
  and FATAL.
- The format of the log output can be easily changed by
      extending the Layout class.
- The target of the log output as well as the writing strategy
      can be altered by implementations of the Appender interface.
- log4j supports multiple output appenders per category.
- log4j supports internationalization.
We might add:
- it has a larger developer/use base.
- LogKit is even faster, once the
	if( getLogger().isWarnEnabled() )
	   getLogger().warn( "Some " + " expensive " + "string" + "operation" );
	setup has been added and implemented (which I'm sure will happen
	soon, as it's a good idea).
- because of it's complexity, Log4j is more likely to run into

The question is whether the Jakarta project should keep the two logging

Arguments for:
- LogKit provides the lightweight logging, while Log4j provides the
heavyweight features. They're to be used for different purposes. Thus,
the separation is good.

	The APIs are quite similar. The fact that velocity
	can swap one for the other seems to indicate they
	indeed serve much the same purpose. Thoughts?

- we think it would be nice for LogKit to merge with Log4j, but the
Log4j people think otherwise. LogKit provides features we cannot afford
to loose (speed, stability, design).

	Is this really the case? Avalon is evolving as
	rapidly as log4j, which means we might not need
	LogKit's stability. Which design is better is
	IMHO a matter of taste, so it isn't something to
	judge from. As for speed, see below for thoughts.

- both are in daily use. If we decide to cancel one (which would
be LogKit), we'll have to maintain legacy support etc etc.

	Not a good argument at all. Listening to this means
	creating bloatware in the long run.

Arguments against:
- there is a big duplicity here.
	-- that means duplication of efforts
	-- separation of developers
	-- confusion for new users
	-- and many other not very cool things.


- Log4j has many more developers and many more features.
It could eat LogKit for lunch and still have room for the
new logkit API in jdk 1.4.

	True. But does size matter?

Startup costs for logging are not terribly important. The
costs of log statements are. Around 4% of code is for logging
purposes, this means the speed of logging has a significant
impact on the speed of the application (for server envs,
LogKit is faster than Log4j, if you disregard Log4j's
"check first if we should before even attempting to log"
feature, implemented as:

	if( logger.enabled() )
	   logger.log( expensive string operation );

This is so important because an expensive string operation
takes around 10 times as much time as an entire logging
statement. The check whether or not to log usually takes
a neglible amount (<8ms) of time.


For both LogKit and Log4j, it is usually true that the
actual time spent in the logging code is more than tenfold
less than the (actual time spent writing the statement+
time spent doing string operations).

Thought experiment:
- assume LogKit's code is twice as fast as Log4j's
- assume working through the code is 1/10 of the actual
time spent on logging. The rest is spent writing to outputs
and doing string operations.
- assume the 4% logging code means 5% of the delays in
a running program.

this means that using LogKit instead of log4j results in a
a 5% x 10% x 2 = 1% faster program.

When you need to choose between LogKit and log4j, it basically
comes down to speed (LogKit) versus features (log4j).
I believe that, for Avalon, the speed advantage offered by
LogKit, combined with its already existing ties to Avalon,
is merit enough to keep it.
However, I think that for applications based on Avalon, Log4j
might make a lot more sense - it is in more widespread use,
better documented, offers some valuable features and still is
a speedy package.

Based on that fact alone, I think we should move from LogKit
to Log4j in Avalon 4. Add to it all the advantages that come
from removing code duplicity, and I'm completely convinced.

Guess it is time for a vote.



	About LSD  = new PersonalInfo();
	LSD.name("Leo Simons");
		http://www.leosimons.com, // personal website
		http://www.atfantasy.com, // fantasy RPG portal
		http://www.the-sign.nl    // web-design company
	] );

To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

View raw message