logging-log4j-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 Interface
Date Wed, 07 Nov 2001 21:45:09 GMT

>> Even if I accept that adapter plugins, I must now deal with
>> for each middleware component.  It begins to grow (Log4J, LogKit,
>> When I want to enable tracing I've now got to go through I-don't-know
>> many configuration points to do so, and communicate to my end-users
>> multiple different mechanisms to enable/disable tracing at different
>> in the code.  Guess what: my own selfish desires aside, my users don't
>> 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
>allow one file to describe the entire log heirarchy and Logger names for
>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
>one system.
>If you wanted a Logger that talked directly to a Third-Party Logging
>you would create a wrapper/adapter for the implementation, and a Factory
so you
>can choose it for the LoggerManager.

Terrific.  Now if only I could replace Log4J with LogKit in my
middleware... some programmer started his project off with Log4J and the
API's just aren't compatible.  And I don't want a Log4J adapter that wraps
the LogKit API, because then I cannot use the LogKitManager - it doesn't
have the visibility and context that Log4J has...


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

Excellent point... something to think about  - thanks.

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

No, I'm only talking about the logger, and only if we can align with Log4J.

>> 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
>jar.  That would mean that both LogKit and Log4J would be required to
>the contents of the shared interface jar.  Can you imagine the classloader

Why?  The framework guarentees that only one of them gets loaded into the
the other isn't needed.


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