commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <cost...@covalent.net>
Subject Re: Resisting the temptation
Date Fri, 10 May 2002 23:50:16 GMT
On Fri, 10 May 2002, Craig R. McClanahan wrote:

> * If the app has no explicit configuration of commons-logging,
>   there are two subalternatives:
> 
>   - If no other logging implementation has a services entry,
>     the factory configured by Log4J will be used.
> 
>   - If there is also another logging implementation that has a
>     services entry, whichever one is seen first in the classpath wins.

If the user has 2 logging implementations - then he is supposed to
explicitely select the one he wants, we can't guess what he wants.
It doesn't matter what API he uses, we can help and discover one 
logger and have things working with minimal configuration, but we can't 
decide for the user what logger should he use when 2 are available. 

I think we should add a simple way to explicitely select a 
logger without using properties ( since in a sandbox you can't 
set properties ), that would allow full control.


> * If the app explicitly configures commons-logging (via a system
>   property), that configuration wins, and the services entry in
>   log4j.jar is ignored.
> 
> (Costin, looking at the current LogFactory code, it seems the check
> for commons-logging.properties is now *after* the services entry check --
> shouldn't it be before so that a commons-logging.properties file will also
> win over any JAR file with a services entry?)

You're right. I'm not very sure if commons-logging.properties is very
usefull, probably an API-based getLog( "factory.class.name" ) would
help more to deal with multiple loggers.

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