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 Wed, 07 Nov 2001 14:59:19 GMT
Richard Sitze wrote:
> 
> Berin - what I see is the framework, and the LogKit... the logger class
> (not interface) is in the LogKit.

AS I SAID, the interface was in CVS:

http://cvs.apache.org/viewcvs/jakarta-avalon/src/java/org/apache/avalon/framework/logger/Logger.java

> I need an independent but common interface.  I recognize the features and
> benefits of LogKit, as well as Log4J, but I don't want my application code
> to be tied to either.

The next version of Avalon Framework will be released in a week or two. (maybe
even less)

> I would be willing to make the requisit changes to Log4J and LogKit, and
> submit - but I'd prefer to have an understanding that the changes will be
> acceptable (and therefore accepted).

I don't think that such changes are that necessary.

> *******************************************
> Richard A. Sitze            rsitze@us.ibm.com
> CORBA Interoperability
> WebSphere Development
> IBM Software Group
> 
> 
>                     Berin Loritsch
>                     <bloritsch@apa       To:     axis-dev@xml.apache.org
>                     che.org>             cc:
>                                          Subject:     Re: Common Logging Package
>                     11/07/2001
>                     08:46 AM
>                     Please respond
>                     to axis-dev
> 
> 
> 
> Richard Sitze wrote:
> >
> > I started with the API docs on
> jakarta.apache.org/avalon/api/index.html....
> > the org.apache.avalon.framework.logger package doesn't have the logger
> > interface.  Is it out of date?
> 
> It is currrent as of the last release.  We are gearing up for a new release
> with the added functionality of supporting Namespaces in Configuration, as
> well as the Logger Abstraction.  There are also a couple minor bug fixes to
> the Version class.
> 
> >
> > <ras>
> >
> > *******************************************
> > Richard A. Sitze            rsitze@us.ibm.com
> > CORBA Interoperability
> > WebSphere Development
> > IBM Software Group
> >
> >
> >                     Berin Loritsch
> >                     <bloritsch@apa       To:     axis-dev@xml.apache.org
> >                     che.org>             cc:     Greg Truty
> <gtruty@us.ibm.com>, Russell Butek
> >                                           <butek@us.ibm.com>, Sam Ruby
> <rubys@us.ibm.com>, Chris
> >                     11/06/2001            Barlock <barlock@us.ibm.com>,
> >                     03:15 PM              graham.hamilton@eng.sun.com,
> Cesare Giuliani
> >                     Please respond        <cgiulian@tivoli.com>,
> ceki_gulcu@yahoo.com,
> >                     to axis-dev           craigmcc@apache.org
> >                                          Subject:     Re: Common Logging
> Package
> >
> >
> >
> >
> > 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
> 
> --
> 
> "Those who would trade liberty for
>  temporary security deserve neither"
>                 - Benjamin Franklin


-- 

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

Mime
View raw message