axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: Common Logging Package
Date Tue, 06 Nov 2001 20:15:59 GMT
Richard Sitze wrote:
> I'm sure this is going to spark some kind of annual (or semi-annual)
> debate, so my apologies before I go any futher.  I've decided to copy a
> number of folks that, as I understand, have an interest in this topic.
> I would like to take a more aggressive approach than I think has been
> proposed in the past, so I hope that excuses this exercise.
> The bottom line is that I want a pluggable logging layer, that can be
> replace at runtime with another.  NONE of the current logging packages that
> I've looked at and NONE of the proposed logging packages use an interface
> that allows pluggability.

As of now, Avalon Framework has a Logging tool abstraction layer.  This way
all logging is performed to a common interface--allowing the logging
implementation to be switched.

> At the same time, I want to be sensative to runtime overhead (a past life
> was with embedded system on a tight budget, so I'm a performance biggot who
> has been struggled for air in the enterprise application arena :-).
> Before I go any further, I'd like to step back and introduce my situation
> more clearly.
> I am working with AXIS developers and looking at integrating the AXIS
> logging (and other open source tools in the future) with enterprise
> application development tools and services.  AXIS is using Log4J today, our
> products are using legacy logging tools.  We are not in a position to
> change, any more than any other project... open or closed.
> As we integrate different open source projects into enterprise applications
> we are going to end up with a plethora of logging tools under the covers.
> In a worst-case (but realistic) scenario we are going to end up with
> Enterprise applications using:
> * Log4J
> * LogKit (Avalon)
> * JSR47
> * Proprietary Logging Interface (internal?)
> * who knows what else...

The Avalon Framework logging abstraction provides wrappers for Log4J
LogKit and JSR47.  It does not abstract the configuration of the different
logging packages--but it does abstract the use of it which is IMO much
more important.

> Leaving this as-is means that developers and end-users (customer) must
> manage multiple configurations (enable/disable, filters, etc), multiple log
> files, monitor multiple log files (with time-stamped records, hopefully),
> and try to merge info together to gain a clear picture of sequential system
> activity during debugging... bottom line: it's a headache.  It's simply
> undesirable and unnecessary complexity for developers and end users.
> I see two solutions available:


> There will be some impacts to both Log4J and LogKit.  Worst case, we end up
> with bloated code (small wart, really) that works for both worlds
> unchanged.  The discrepencies appear to be:
> a.  LogKit::fatalError versus Log4J::fatal.

Using the common interface, this becomes Logger::fatalError for LogKit,Log4J,
and JSR47 (equ. to SEVERE)

> b.  Log4J needs a few more isXXXEnabled() methods.

Log4J does have isEnabled(Level), which is used to test for the higher
priority methods.  You will find the same issue for JSR47

> c.  LogKit parameters are java.lang.String, whereas Log4J uses
> java.lang.Object.

You log Strings.  There are some places where someone would do more
than a .toString() on an object, but in general that works.

> My design principles:
> 1.  Keep it simple (For example, I considered introducing a Priority
> interface, but that starts to move us further from JSR47).
> 2.  Keep names meaningful first, balanced by short.
> 3.  In the end, if I'm looking for a bug I turn on all tracing... which is
> why I have only on level of debug tracing (simple).
> 4.  One "logger" per JVM.
> 5.  Given flexible versus rigid, and all else equal, go with flexible
> (flexible can be easier to use).
> My proposed interfaces and factory would be (I have no real attachment to
> any names below, just the principle):
> package org.apache.common.Logger;
> interface Logger
> {
>     public void isFatalEnabled();
>     public void fatal(java.lang.Object message);
>     public void fatal(java.lang.Object message, java.lang.Throwable
> throwable);
>     public void isErrorEnabled();
>     public void error(java.lang.Object message);
>     public void error(java.lang.Object message, java.lang.Throwable
> throwable);
>     public void isWarnEnabled();
>     public void warn(java.lang.Object message);
>     public void warn(java.lang.Object message, java.lang.Throwable
> throwable);
>     public void isInfoEnabled();
>     public void info(java.lang.Object message);
>     public void info(java.lang.Object message, java.lang.Throwable
> throwable);
>     public void isDebugEnabled();
>     public void debug(java.lang.Object message);
>     public void debug(java.lang.Object message, java.lang.Throwable
> throwable);
> }

Avalon Framework has this at:


but the "fatal" level is "fatalError".
Also, we have a method getChildLogger();

> interface LogManager
> {
>     public Logger getRootLogger();  // do we need this?
>     public Logger getLogger(java.lang.String name);
> }

This won't work for AvalonFramework, because it uses the Inversion of
Control principle.  IOW, The Logger is handed to the object being logged.
We use the following interface:

package org.apache.avalon.framework.logger;

interface LogEnabled {
    void enableLogging(Logger logger);


Avalon does have a fairly flexible LogKitManager that could easily be
extended to set up logging environments for the other Loggers.  It is
not part of the LogKit package though.


"Those who would trade liberty for
 temporary security deserve neither"
                - Benjamin Franklin

View raw message