logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Sitze" <rsi...@us.ibm.com>
Subject Common Logging Interface
Date Wed, 07 Nov 2001 16:23:31 GMT
I was going to break a rule, and cross post to two different groups... but
I cannot find an Avalon group.  So I've added a few of the major LogKit
contributors, in addition to Berin (thanks for your comments to date
Berin!).

OK, so LogKit has the abstraction (interface), but it's not yet inline with
Log4J.  My overriding goal remains choice: I WANT CHOICE of a pluggable
API, and I WANT YOUR SUPPORT, NOT YOUR PACKAGE AS MY ONLY OPTION!!! (that
was podium pounding, not yelling :-)  In addition, I need a factory
interface to properly abstract initialization.  See history (below) of this
note..

Choice is important (this is open-source, remember!) to minimize multiple
configuration points and multiple log files in an enterprise application
(multiple middleware solutions, multiple applications, all trying to work
together.. in a distributed environment..).  See history (below) for more
details..

Finally, I believe that the changes are minimal.

To repeat earlier points and address the new LogKit interface, the
differences that I see between LogKit and Log4J are:

a.  LogKit::fatalError versus Log4J::fatal.

b.  Log4J lacks isXXXEnabled() methods.  I would prefer not to introduce an
isEnabled(Level) method to the interface, and I understand that JSR47 will
not be able to implement the interface directly, but will require a
wrapper.

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

d.  LogKit org.apache.avalon.framework.logger.Logger interface introduces
getChildLogger(String name)



I'm willing to do the work to establish a common logging interface, but it
must be coordinated.  Clearly I need to know that it's going to be accepted
before I start.  To make this happen, I need a coordinated VOTE from:

A.  Apache/Jakarta development leaders (common code?)
B.  Log4J development team (I can do work, I need support).
C.  LogKit development team (again, I'd be happy to do work, but I need
support).



For Apache/Jakarta common code (craig, can you help with logistics here?),
I propose the following (I'm not attached to names):

     Apache.1: Copy the org.apache.avalon.framework.logger.Logger
               interface to org.apache.common.logger.Logger (?).

     Apache.2: Remove getChildLogger(String name) from
org.apache.common.logger.Logger.

     Apache.3: Change logging method parameters from java.lang.String
               to java.lang.Object.

     Apache.4: More to come on factory, but that's incidental if I can get
               all of this done first.



I propose that the LogKit group VOTE on the following (as a unit) changes
to the org.apache.avalon.framework.logger.Logger interface:

     LogKit.1: Cause interface to extend org.apache.common.logger.Logger.

     LogKit.2: Remove logging methods in common with
                org.apache.common.logger.Logger (they inherit..).

                This effectively changes parameter types from
                java.lang.String to java.lang.Object, which should
                be backward compatible.

     LogKit.3: Leave getChildLogger(String name) as a method unique
                to the framework...



I propose that the Log4J group VOTE on the following (as a unit) changes to
the Category/Logger class:


     Log4J.1:  Cause class to implement org.apache.common.logger.Logger.

     Log4J.2:  add fatalError(), mapping directly to error()
                It's redundant but I want to preserve backwards
                compatibility.

      Log4J.3:  Add missing isXXXEnabled() methods: isErrorEnabled(),
                isFatalErrorEnabled(), isWarnEnabled().



*******************************************
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                                                           
          
                    09:59 AM                                                             
          
                    Please respond                                                       
          
                    to axis-dev                                                          
          
                                                                                         
          
                                                                                         
          



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




--
To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>


Mime
View raw message