commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <cost...@covalent.net>
Subject RE: Problems with commons-logging
Date Wed, 06 Feb 2002 23:02:26 GMT
On Wed, 6 Feb 2002, Craig R. McClanahan wrote:

> Why isn't picking a particular logger (by name) sufficient?  The default

Same could be said about a SAX parser. 'Features' serve a very clear role
- they reduce the need to use implementation-specific classes.


> The use case I worry about is a large application involving tens or
> hundreds of components that use logging.  The admin of such an environment
> is *not* going to want to understand the quirks of configuring how each
> component uses logging -- he or she is going to want to know what logger
> names you use (this should be documented for each component), so that the
> log output for that component can be merged with or split from log
> messages for other components (i.e. using common appenders or not in
> Log4J) as appropriate.

That's one use case. In an environment like J2EE it is indeed a good idea
to have JDBC, JNDI, parsing, logging, etc managed by the container.

However this is not the only use case. And many applications that
will use logging will run standalone or in environments that do not
behave this way.

Making 'centralized configuration' as the only way to use the logger is
wrong. JDBC, JNDI, parsing and almost all other APIs we use do provide
some form of configuration ( like a simple Hashtable for jndi, a
setFeature/setAttribute for JAXP, etc ), that allow independent
applications to use the API outside of a J2EE-like environment.

An API that can't be used 'standalone' ( in the sense that we'll allways
be forced to write implementation-specific code to make any use
of the API in an application or rely on a container ) is useless for me.


> Doing a half-assed job of logging configuration is much worse, IMHO, than
> doing nothing and saying "logging configuration is a feature of the
> application, not of the component using the commons-logging APIs".

First, adding a get/setAttribute() is not a half-assed job - it's
something other APIs are doing succesfully.

Second, the logging configuration is not a feature of the component
using the commons-logging. It's a feature of the logging API that it
allows to pass configuration info to the backend - like
all other APIs.

JDBC configuration is not a feature of the component,
neither JAXP configuration. It should be done by the application
or container. Some piece could be done by the component - like
tunning ( validation in jaxp for example - which is a config
info passed to the backend ). Or if a component needs - it can
do the full thing.


> It's not another project -- it appears to me that you're proposing a
> duplication of something that already exists in the loggers that matters.

It's not a duplication - it's including in the commons-logger API
methods that would allow to take advantage of things that existing
loggers ( which we want to abstract ) provide.


If the commons-logger can't be used in the same way as a SAX parser
is, but require the application to use the 'real' parser and
have code for crimson, xerces, etc  - than the commons-logger
API is not good enough, and we should better use log4j
or logkit and create an adapter for the others ( so a component
using log4j APIs can talk to a logkit backend or reverse ).



Costin


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message