logging-log4j-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 Interface
Date Wed, 07 Nov 2001 17:14:34 GMT

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:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>


Mime
View raw message