On Wed, 15 Aug 2001, Jason van Zyl wrote:
>
> I really don�t see any downside to binding to log4j in the components. Log4j
> can easily integrate with anything that comes down the pipe in the future.
>
From the perspective of a potential user of Commons components, there
would be a very important downside to locking the components in to using
Log4J -- that forces the user to use Log4J whether or not they want
to. (I'm not interested in arguments on why we might want to try to
convince them otherwise -- not everyone is going to be converted :-).
It doesn't matter to such users that they can write adapters and Category
implementations and such -- they already have their own logging
environment, and want to use *that* instead without having to learn
Log4J's configuration formats, or enough internals to integrate it. To
such users, tying commons components to Log4J will be a showstopper for
using the commons components in the first place.
No argument that such a decision might not be rational - but this is
reality.
Note that the decision is different for something like Turbine, where you
need more sophisticated logging capabilities. There, it makes perfect
sense to choose a logging API and use it throughout, plus make it easy for
applications developed on top of Turbine to take advantage of its
capabilities.
The decision for commons components should be based on different criteria.
> I think this would also be a step toward making a component API for all the
> commons projects can use. We can start with logging and go from there :-)
>
Note that, the way the current abstraction layer works, it defaults to
Log4J anyway if the classes are visible, so integrating commons components
into an environment already using Log4J reqauires nothing you aren't
already doing in terms of configuration.
And, if you don't have Log4J installed, any log output created by Commons
comopnents is silently thrown away -- you don't have to care at all about
logging unless you want to.
> --
>
> jvz.
>
Craig
