axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Sitze" <rsi...@us.ibm.com>
Subject Re: Common Logging Package
Date Wed, 07 Nov 2001 14:46:05 GMT
Berin - what I see is the framework, and the LogKit... the logger class
(not interface) is in the LogKit.

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.

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

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




Mime
View raw message