axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "R J Scheuerle Jr" <>
Subject Re: Common Logging Package
Date Tue, 06 Nov 2001 20:58:40 GMT
Looks good to me.

Rich Scheuerle

                    Sitze"               To:     "Greg Truty" <>, "Russell
                    <        <>, "Sam Ruby" <>,
"Chris Barlock"     
                    .com>                 <>,,
"Cesare Giuliani"   
                    11/06/2001           cc:                 
                    01:42 PM             Subject:     Common Logging Package             
                    Please respond                                                       
                    to axis-dev                                                          

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.

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

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:

1.  Write adapters/handlers for each of these that maps to the Enterprise
logging SPI.  Solves the multiple log files problem, but not the multiple

2.  Push, as far as we can, a common/pluggable API that is covers 90% of
what logging interfaces do today.  I would argue that any remaining 10% is
glitter and glitz that could be done away with in exchange for reduced
complexity when integrating AXIS, Xerces, Xalan, Avalon, Eclipse, Tivoli,
etc into an enterprise application or development environment.

In the short term it is likely that we are going to end up with (1) anyway.
In the longer term, I would hope that open source middleware would move
towards (2).

Note also, that once (2) is completed, specific handlers that wrap (2) can
be packaged with Log4J/LogKit/JSR47.  From that point a quick bootstrap of
an application, using middleware bringing Log4J/LogKit/JSR47 together, can
be accomplished by writting a quick wrapper for the "proprietary logging
interface" using the same interface.  Granted that this is a "least common
denominator" solution, but it's a quick and easy one to get things started,
that could be replaced with something better later.

I'm proposing a common interface that can be used IF DESIRED.  I'm
proposing that Log4J and LogKit  implement that interface in their
Category/Logger classes, to eliminate concerns about wrappers and overhead.
I'm focusing on Log4J and LogKit as a model for this interface because a)
they are open source, b) they are in use and established, and c) they have
much in common.  Other logging interfaces will need to use thin wrappers -
which isn't much of an overhead when considering how Log4J and LogKit
implement the functions exposed in this interface...  Once that is
accomplished then we can let the community decide (that's what open source
is about, right?):
--  If they want to use Log4J, LogKit, JSR47, or whatever - then go for it.
--  If they want a very simple, rudementary, but pluggable API, with which
they can swap in/out Log4J (directly), LogKit (directly), JSR47 (wrapper?),
JLog/JRas (wrapper?),  or other logger API, then they can use the

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.
b.  Log4J needs a few more isXXXEnabled() methods.
c.  LogKit parameters are java.lang.String, whereas Log4J uses

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

    public void isErrorEnabled();
    public void error(java.lang.Object message);
    public void error(java.lang.Object message, java.lang.Throwable

    public void isWarnEnabled();
    public void warn(java.lang.Object message);
    public void warn(java.lang.Object message, java.lang.Throwable

    public void isInfoEnabled();
    public void info(java.lang.Object message);
    public void info(java.lang.Object message, java.lang.Throwable

    public void isDebugEnabled();
    public void debug(java.lang.Object message);
    public void debug(java.lang.Object message, java.lang.Throwable

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

// A separate implementation of this interface should be defined
// for each current logging API: Log4J, LogKit, JSR47, etc.
// It may be that even more specific implementations of this factory are
// coded for applications with different requirements on logger
interface LogManagerFactory
    // Create and initialize a LogManager.
    public LogManager getLogManager();

    // ???
    // Would it be useful, and do the existing API support appropriate
    // to bind an instance of a "logging hierarchy" to this log manager....
such that
    // we activate a handler that routes call through the foreign logger to
this API..

class ApplicationLogger
    // Create a new LogManager for the given application.
    // An assumption here is that we want one LogManager per JVM,
    // which is in line with our goal of integrating logging together.
    // system property org.apache.common.logger specifies an
    // implementation of the LogManagerFactory interface.
    static public LogManager getLogManager();

    // override system property with an instance of a LogManager.
    static public void setLogManager(LogManager logManager);

Richard A. Sitze  
CORBA Interoperability
WebSphere Development
IBM Software Group

View raw message