Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 68203 invoked by uid 500); 7 Nov 2001 13:45:01 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 68061 invoked from network); 7 Nov 2001 13:45:00 -0000 Message-ID: <3BE93B2B.826F5C25@apache.org> Date: Wed, 07 Nov 2001 08:46:19 -0500 From: Berin Loritsch X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: axis-dev@xml.apache.org Subject: Re: Common Logging Package References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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. > > > > ******************************************* > Richard A. Sitze rsitze@us.ibm.com > CORBA Interoperability > WebSphere Development > IBM Software Group > > > Berin Loritsch > che.org> cc: Greg Truty , Russell Butek > , Sam Ruby , Chris > 11/06/2001 Barlock , > 03:15 PM graham.hamilton@eng.sun.com, Cesare Giuliani > Please respond , 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: > > > > > 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); > } > > > > 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