axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
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:

<snip/> 

> 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:

org.apache.avalon.framework.logger.Logger;

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);
}

<snip/>

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

Mime
View raw message