-1
We should use the log4j API, if there are some implementation issues we should
handle them but creating a new API just because you don't like an implementation
is not a good thing.
> For what it's worth, here's my analysis of the logging situation.
With my opinion
> 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.
I also like log4j and it does what I need... but we could (if needed) make some
add-ons or else ask an enhancement of log4j itself.
> 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.
People can always choose, we are now voting for
- use commons-logging API for logging
- use log4j API for logging
> 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.)
And some packages should be optimized for speed (without any runtime logging).
IMHO, I think that (small) components shouldn't log anything. They can contain
debug statements that were used to develop the component and are left in because
there might be a bug but logging... no. The pool component shouldn't log
anything when you request something from an empty pool, it should just do what
the API specifies, return null or throw an exception. The application should
handle that situation and write some log message if the situation demands it.
> 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.
Log4j can integrate with almost everything and if something is not possible we
should enhance log4j.
> 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?
Why use glue if you can use the real thing...
> 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.
Size doesn't matter (if I read your own text correctly)
- under normal circumstances you can probably live with ~20K or more
- under extreme circumstances you want to remove all logging calls
If we want, we can make a log4j API implementation that does no logging, a
no-op version will be smaller then 20K.
> 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.
Why a no-op method, enhance log4j to support that nifty feature.
> 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).
All features in log4j are there because somebody needed them, and if you want
that somebody to use commons-logger you probably have to support them too.
> 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.
Are you really saying make commons-logging the standard because "admitting log4j
is the defacto standard" is a bad thing ?
> 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.
The only thing we might need is no-op implementation of the log4j API and some
add-ons.
There are also some disadvantages of using glue. For example you cannot use
(%F:%L) to display the current file and line number, it always returns "glue".
Maybe there is a solution for this, but there are other disadvantages as well,
extra overhead for each call, more code,...
Dirk
