+1
For what it's worth, here's my analysis of the logging situation.
1. Personally, I like log4j. A lot. It's simple but powerful, and seems
able to grow with my needs. I haven't done an extensive analysis of other
logging APIs, so maybe I'm missing something great, but there's nothing I've
needed to do, or can imagine a need to do, that log4j doesn't support.
(Maybe I'm just small minded :) ) Log4j is also well supported by "add-ons",
as listed at http://jakarta.apache.org/log4j/docs/download.html and probably
elsewhere.
2. The fact that I like log4j, or that it is sufficient for my needs doesn't
mean squat. Clearly others have differing opinions, and those opinions seem
valid enough. Trying to change those people's opinions on this matter seems
like a losing proposition anyway.
3. Like I said before, *some* people will want logging from *some* commons
components. I happen to be one of them, but I'm certainly not alone.
(You'll be hard pressed to convince me that there is *never* a need for
logging in all components within the scope of jakarta-commons. Even within
the current commons crop, I'd suggest dbcp, pool, probably httpclient and
possibly even digester benefit from logging. There simply are events that
occur that are neither exceptions nor should necessarily change the
application flow, but I'd like to know about when they happen.)
4. As a *common* *component*, a commons component should be able to
integrate fairly easily with the application/system that uses it. For the
people mentioned in #3, this includes being able to integrate into whatever
logging system they want, if they want logging.
5. Having a distinct logging abstraction in each commons component is silly
a best. Why do I need a distinct set of classes for each component that
supports logging? Why should I need to recreate my
abstraction-to-implementation glue for each distinct component?
6. While log4j supports pluggable Appenders, and hence could be used to do
what is described in #4 and #5, there are some factors that seem to limit
it's viability as an option as the *conventional* (not necessarily
"standard") commons logging API:
6.1) The latest minimal log4j build I've seen is ~20KB (I can't get to
qos.ch right now so I can't check it exactly). Some people believe this to
be too large. There are plenty of circumstances (client-side installations,
embedded installations, applets, burned onto CDs, etc.) where I tend to
agree with them, although I think for the typical application that's
probably small enough. Getting log4jME down to ~5K for log-less operation
would probably be small enought for all but the most extreme circumstances
(in which case a custom build with all logging calls removed is probably
warranted.
6.2) Using log4j as the "logging abstraction" really is tying those
components to log4j at some level--and a level more signficant than simply
creating a CLASSPATH dependency. It constraints the interface used by the
components (but not of the containing application) to that supported by
log4j. Maybe that interface is sufficient, but when it isn't (say there is
some nifty feature of Merlin or LogKit that can be safely or reasonably
ignored when not supported by other logging APIs) the only way to add API
support for it is to get log4j to add a no-op method for it. This seems
difficult at best.
The converse also applies. If the log4jME supports some nifty feature that
isn't reasonably supported by the other logging APIs, we have no programatic
way to constrain a commons component from using it, meaning log4j has to
limit their minimal interface to some least common denominator or our
support for other logging toolkits is significantly weakened (in which case
pretending we have a "logging abstraction" and not just log4j is silly).
6.3) No matter what "logging abstraction" is used, someone will need to add
a little bit of glue code to connect the abstraction to the implementation.
Reasonable or not, in practice I suspect that most other logging
implementations will be loathe to create direct log4j wrappers for their
logging systems--to do so would seem to be admitting defeat at some level
and clearly makes log4j the defacto standard. Having this stuff live in the
log4j code base might also be awkward.
It seems to me that a small, more-or-less logging-implementation-agnostic
component is quite useful, since it resolves many of the forces above.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
