> -----Original Message-----
> From: Peter Donald [mailto:[EMAIL PROTECTED]]
> >
> > 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
