avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Logging at Avalon
Date Sun, 22 Feb 2004 08:38:56 GMT
Niclas Hedhman wrote:
> Gang,
> Could someone who has been around since the stone ages explain the plethora of 
> logging packages;

Grunt! (stone age man taps on keyboard)

> avalon-logkit

The logkit package is logging implementation written prior to the stone 
age.  Is basically in the same space as Log4J.  It is small, lighter, 
faster, less feature rich, and at end-of-life.  It exists for legacy 
reasons as it is referenced in framework and excalibur.

> avalon-excalibur/logger

The excalibur logging package was designed as a container-side logging 
management api and implementation.  It defines a logging manager and a 
number of adapters including adapters for LogKit, Log4J, Java Logging 
and a couple of others.

> avalon/logging

The avalon-logging package is a open logging platform suitable for use 
by container implementators (i.e. exactly the same space as excalibur 
logging). It is based largely on the original excalibur logging system 
but with some important changes. Firstly it leverages the 
avalon-repository technology to support dynamic loading of 
implementation strategies, secondly, it simplifies the overall approach 
to target configuration, and thirdly, it applies a formal logging 
category meta-data model that is consistent with avalon model-driven 
container solutions.

In case your wondering why a separate package was created:

   1. the practice of bundling optional implementation class
      references in working classes plays havoc with any multi-tie
      classloading system (a practice common in excalibur content)

   2. APIs in Excalibur Logging reference APIs in LogKit eliminating
      the possibility of effective sunsetting of LogKit and
      substantially hindering development of a modern logging system

   3. management model assumes that the all logging requirements
      are statically defined via a configuration - which is
      inconsistent with modern container needs

   4. approach to configuration is overly complicated and overdue
      for a rethink

The basic logging system that was put in place under merlin 3.2 
addressed requirements that were specific to Merlin - namely meta-driven 
dynamic channel management.  However, several user requests were made to 
enhance the package to support features such as rotating file targets, 
customizable filter patterns, etc.  A couple of attempt were made to 
evolve excalibur-logging to meet these requirements (once by Berin and 
once by me).  Both attempts failed.  The third and ultimately more 
successful approach was to put in place a completely independent API and 
to build a solution (leveraging excalibur-logging code) based on the 
avalon-repository package.


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


| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/merlin/distributions/latest    |

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

View raw message