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

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

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

<snip>

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

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
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
>issues?

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


<ras>


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