avalon-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 20:44:26 GMT
>> I want a common interface that is *implemented* (as in Java 'class
>> 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.

When I go through that adapter layer I loose context on the current log
statement.  The logger is aware of calling classes/methods (it can look on
stack) and categories that can be used for filtering.  Once you go through
that adapter layer...

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

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

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

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

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
      (if logging implemention supports), etc.

Richard A. Sitze            rsitze@us.ibm.com
CORBA Interoperability
WebSphere Development
IBM Software Group

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message