avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Galluzzo" <egallu...@einnovation.com>
Subject RE: FOP, Avalon, Logging
Date Tue, 18 Sep 2001 14:03:35 GMT
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> >
> > I'm confused. If the Avalon interface Loggable is generic, then
> I only need
> > to learn that one and I probably only already know at most one (LogKit,
> > Log4J, JDK 1.4, etc.) which is the one I want to plug in for
> consistantcy.
> > The guy that wrote the generic API needs to know all six but few others
> > would bother.
>
> I guess I wasn't clear ;)
>
> I don't mind a writeable generic interface (like that in Loggable
> proposal
> directory) and think that is a great idea. I could even be convinced I
> suspect that a generic LoggerFactory interface that is grabbed like JAXP
> picks up compilers may be a good idea.
>
> However interfaces that do "management" functions ie virtually
> any of set*()
> or specify logging constants (like levels/priorities/whatever) except
> implicitly, assume too much about the underlying architecture
> IMHO. Virtually
> all get*() functions could also be eliminated (except the
> is<Level>Enabled()
> which is an optimization thing).
>
> So a basic Logger interface is good - its when you start adding all the
> mutators and accessors and other management functions that it becomes bad
> because then you have just created a new Logging API ;/

I'm not sure. :)  There is a line to draw there, between offering a
fully-fledged no-holds-barred interface to every function of every logging
API, and offering a purely minimalist getLogger() method with no parameters.
We have tried, in Trunk, to walk that fine line.  We do offer a couple of
"meaty" methods -- e.g. Logger.setLoggingThreshold(), which we consider to
be essential for any logging API to be useful; and
LoggingDriver.configure(), which takes a driver-specific configuration file
and uses it to configure the underlying logging system.  However, throughout
Trunk, including the above two methods, virtually all of the "meaty"
functionality is implemented by the logging system to which the particular
Trunk driver is interfacing, not by the driver or by Trunk itself.  So
Trunk, although necessarily offering its own interface, is not an API in
itself, and is not feature-laden.  It is more like a useful common
denominator that is "good enough" for almost all logging users.

To counter the point you made in an earlier post about switching over to JDK
1.4 eventually when it becomes standard, thus obviating the need for Trunk:

    1. We do not necessarily know that JDK 1.4 logging will become the
       "industry standard" logging API; I know that some people have raised
       some very serious objections to it (and rightly so).
    2. Even if JDK 1.4 becomes the standard, it will certainly take people a
       couple of years to all move over to 1.4.  The company for which I was
       working until March of this year was still using JDK 1.1 for a
variety
       of reasons.
    3. If JDK 1.4 logging does become the standard, that is even more reason
       to use a generic interface.  Currently, Avalon uses LogKit, which is
       a fine API; but if we suspect we're going to have to switch to JDK
1.4
       style logging in the future, it only makes sense to code to a generic
       interface (which is no more complicated than LogKit) so that if such
       an eventuality occurs, we can simply "plug in" the JDK 1.4 driver --
       or better yet, offer the user the chance to use whichever logging
       toolkit he wishes -- instead of having to modify all the code that
       uses logging (which is likely a great deal of it).
    4. Certainly, in the short term, JDK 1.4 logging will _not_ be the
       standard, and the Java community will remain fragmented between
       several different logging APIs.  Jakarta itself maintains three of
       them (Log4J, LogKit, and Velocity)!  Therefore, whoever is trying to
       integrate other products with Avalon will be faced with the same
       dilemma we at our company are faced with, namely: we must ship with
at
       least two logging JARs because two different products have decided to
       use two different logging APIs.  This entails coordination between
       configuration files, code bloat, and other hassles.  Using a generic
       pluggable interface such as Trunk solves this problem simply.

Thanks for reading this far and listening to my ramblings! :)

    - Eric


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


Mime
View raw message