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 21:13:23 GMT
Richard Sitze wrote:
> >> I want a common interface that is *implemented* (as in Java 'class
> MyLogger
> >> implements commonLogger') by both the LogKit Logger and the Log4J
> >> Category/Logger classes.
> >>
> >
> >Richard, is this an absolute requirement?  Or isn't the real goal that you
> >want your *application* to be able to use the abstraction layer, and then
> >have an adapter that plugs in to the lower level logger implementation?
> My requirement is that I want my Enterprise Applications to be able to use
> a pluggable logging interface WITHOUT writting special adapter plugins for
> each piece of middleware that reroute logged messages through my system
> logging tool.

Somewhere, someone has to write them....  That said, you can control how
they are invoked.

> Even if I accept that adapter plugins, I must now deal with configuration
> for each middleware component.  It begins to grow (Log4J, LogKit, JLog)...
> When I want to enable tracing I've now got to go through I-don't-know how
> many configuration points to do so, and communicate to my end-users
> multiple different mechanisms to enable/disable tracing at different points
> in the code.  Guess what: my own selfish desires aside, my users don't LIKE
> more than one way to configure tracing...  I'm thinking that I have a
> better chance of getting a common pluggable interface from you folks that a
> common configuration scheme!!!

The LogKitManager (that can easily be adaptable) is your savior.  This will
allow one file to describe the entire log heirarchy and Logger names for them
all.  The LogKitManager (which would in this case change it's name to
LoggerManager) would even be able to set up loggers from multiple sources in
one system.

If you wanted a Logger that talked directly to a Third-Party Logging implementation,
you would create a wrapper/adapter for the implementation, and a Factory so you
can choose it for the LoggerManager.

> >For example, we're never going to be able to get the JSR-047 logger in JDK
> >1.4 to implement org.apache.commons.logger.Logger - but it would still be
> >feasible to write an adapter underneath that used it (perhaps
> >transparently).  We could include adapters for Log4J, LogKit, and JSR-047
> >in the commons package -- but you could also write an adapter for a
> >proprietary logging API that already existed.
> With regards to JSR47 and other schemes that don't fit as well as Log4J and
> LogKit do:  you are right.  In this case I'd like to follow the lead of the
> avalon framework, introduce a wrapper for those loggers, and encourage
> future middleware developers to use the framework with their logger
> implementation of choice.  When they deliver their middleware to me, I can
> swap in whatever I favor this week, across the all middleware components
> (OK, I'm dreaming, but that would be the end goal).  I suppose my real goal
> is to minimize management complexity.
> I'm beginning to see that the Avalon framework is very close to what I
> want, if I understand Berin - I'd just like to remove that wrapper around
> Log4J because some folks have expressed the concerns of runtime overhead
> with wrappers etc. etc...

Keep in mind that with modern compilers (like JDK 1.3+) make some optimizations.
The wrapper classes are declared final, as well as all the methods and internal
variables.  In essence, in the run-time, the wrapper is optimized out, and the
contents of the code are in-lined.

This achieves very little to no overhead.

> I'm not proposing that we solve all the problems, just try to take
> advantage of the simularities where they are to help encourage people to
> use the framework...  Perhaps what I'm advocating is equivalent to
> 1.  Moving the avalon framework to an apache common tool...

The whole framework?  Or just the logging part?  We need to resolve this
soon, because it affects my release plans for Framework.

> 2.  Make the minor mods to LogKit and Log4J
>     (the two predominant open-source logging API's)
>     to eliminate overhead of wrappers entirely when
>     used with the framework...

Here is the deal with that approach:

Requiring a supposedly self-contained jar to implement interfaces from an
external project now REQUIRES all users of the jar to now incorporate that
other jar.  Either that, or include the other jar inside the self-contained
jar.  That would mean that both LogKit and Log4J would be required to include
the contents of the shared interface jar.  Can you imagine the classloader

I have a feeling it won't behave as nicely as you want.

> >To me, this is the easier problem to solve -- the harder problem is to
> >talk all the open source component developers into writing to the Commons
> >Logger APIs instead of directly to Log4J or LogKit or whatever :-).
> >
> >Craig
> If I can get this common interface, my first project will be to move AXIS
> to that interface (it's currently based on Log4J, and I expect minimal
> changes).  That will allow:
> a.  the AXIS community to continue developing using Log4J with
>     - minimal code changes
>     - minimal/no changes in coding log/trace statements
>     - zero performance impact
> b.  the (enterprise) application community putting AXIS to work to
>     - achieve a *tight* binding to an alternate logging system with
>     - minimal runtime overhead (removes requirement of multiple
>       layers of loggers/adapters),
>     - gain advantage of common configuration, single enable/disable
> hierachy
>       (if logging implemention supports), etc.
> *******************************************
> Richard A. Sitze            rsitze@us.ibm.com
> CORBA Interoperability
> WebSphere Development
> IBM Software Group


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

View raw message