You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Richard Sitze <rs...@us.ibm.com> on 2001/11/07 17:23:31 UTC
Common Logging Interface
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
> <gt...@us.ibm.com>, Russell Butek
> > <bu...@us.ibm.com>, Sam Ruby
> <ru...@us.ibm.com>, Chris
> > 11/06/2001 Barlock <ba...@us.ibm.com>,
> > 03:15 PM graham.hamilton@eng.sun.com,
> Cesare Giuliani
> > Please respond <cg...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Common Logging Interface
Posted by Jeff Turner <je...@socialchange.net.au>.
On Wed, Nov 07, 2001 at 12:14:34PM -0500, Berin Loritsch wrote:
>
> Richard Sitze wrote:
[..]
> > 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.
>
> Using the Avalon Framework Logger interface, they both become Logger::fatalError().
> In fact it also works for JSR47::serious().
>
> > 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.
>
> The Avalon Framework Logger interface has the isXXXEnabled() methods accross the
> board. For the ones not available in Log4J, the wrapper uses the isEnabled(Level).
>
> > c. LogKit parameters are java.lang.String, whereas Log4J uses
> > java.lang.Object.
>
> Do you _really_ every log anything else other than strings? For objects, you would
> simply perform a Object.toString() on it.
I'm sure some people do. Log4j has an ObjectRenderer interface:
http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/or/ObjectRenderer.html
I've never used it, but I'd imagine it lets you choose your object
rendering at configuration time, rather than at compile time.
> > Apache.2: Remove getChildLogger(String name) from
> > org.apache.common.logger.Logger.
>
> -10. It is common in Avalon programming to get a child logger and hand it
> to a group of Components that the Container is managing. It makes the
> interface simple, and keeps the child from circumventing the Inversion
> of Control principles that Avalon is designed around.
I believe the suggestion was to keep:
org.apache.avalon.framework.logger.Logger#getChildLogger()
But not to have it in the common interface, org.apache.common.logger.Logger
I think that's reasonable, since getChildLogger() is mostly an Avalon concept
(and a darn good one too, for those who value IoC).
[..]
> > 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.
>
> This is possible.
>
> > 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...
>
> Honestly, if you get different loggers another way I don't like it.
> The reason being is that you open yourself up to Spoofing attacks
> if you have code that automatically loads and uses components. If
> you get a rogue component that wants to retrieve Logging calls from
> the rest of the system, it has access to the whole logging heirarchy.
> This is not good. Bear in mind that Logging has alot of precious
> information that a Hacker can use to determine weaknesses in a system.
>
> I prefer a system that minimizes the impact of such rogue Components
> as possible. This is critical in a server framework which Avalon caims
> to be.
Fully agree with those sentiments! It seems the getInstance() vs.
getChildLogger() characterises the philosophical differences between Log4j and
LogKit. As such, I think the way of obtaining loggers should be
framework-specific. That is what I think Richard is proposing:
> Apache.1: Copy the org.apache.avalon.framework.logger.Logger
> interface to org.apache.common.logger.Logger (?).
Ie, there won't be a getInstance() *or* a getChildLogger() in the common
interface.
Sounds good to me :)
Richard, at some stage could you summarize the discussion (perhaps with
the proposed interface), and post to just log4j-dev and avalon-dev?
thanks,
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Common Logging Interface
Posted by Berin Loritsch <bl...@apache.org>.
Richard Sitze wrote:
>
> 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!).
avalon-dev@jakarta.apache.org
> 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..
Avalon Framework has the interface.
As to being "inline" with Log4J, the interface merely has the client part of
the Logger interface. Anything else is too much. You can't guarantee the
same API for setting up and configuring Logging implementations. Nor should
you. Can you give more info on being "inline" with Log4J?
Avalon Framework does give you the choice of which Logging implementation you
want.
> 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.
Using the Avalon Framework Logger interface, they both become Logger::fatalError().
In fact it also works for JSR47::serious().
> 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.
The Avalon Framework Logger interface has the isXXXEnabled() methods accross the
board. For the ones not available in Log4J, the wrapper uses the isEnabled(Level).
> c. LogKit parameters are java.lang.String, whereas Log4J uses
> java.lang.Object.
Do you _really_ every log anything else other than strings? For objects, you would
simply perform a Object.toString() on it.
> d. LogKit org.apache.avalon.framework.logger.Logger interface introduces
> getChildLogger(String name)
The default implementation for the Log Tools that don't support the notion
of Child Loggers (instead of ParentLoggers), we use dot notation for the child.
e.g.
return Category.getInstance(logger.getName() + "." + childName);
So you still have the same effective interface.
> 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 (?).
If this happens, make the package name shorter. Honestly, I like the Avalon
Logger package, and I do not want something that exposes the whole Logger
Heirarchy.
> Apache.2: Remove getChildLogger(String name) from
> org.apache.common.logger.Logger.
-10. It is common in Avalon programming to get a child logger and hand it
to a group of Components that the Container is managing. It makes the
interface simple, and keeps the child from circumventing the Inversion
of Control principles that Avalon is designed around.
> Apache.3: Change logging method parameters from java.lang.String
> to java.lang.Object.
-0 Honestly, in the end, you are logging Strings. Period. If you really want
to "log" Objects, knock yourself out.
> Apache.4: More to come on factory, but that's incidental if I can get
> all of this done first.
Avalon Excalibur has a LogKit Factory that is both powerful and easy to extend.
It can be modified to allow multiple Log tools relatively easily.
> 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.
This is possible.
> 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...
Honestly, if you get different loggers another way I don't like it.
The reason being is that you open yourself up to Spoofing attacks
if you have code that automatically loads and uses components. If
you get a rogue component that wants to retrieve Logging calls from
the rest of the system, it has access to the whole logging heirarchy.
This is not good. Bear in mind that Logging has alot of precious
information that a Hacker can use to determine weaknesses in a system.
I prefer a system that minimizes the impact of such rogue Components
as possible. This is critical in a server framework which Avalon caims
to be.
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>