commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Resisting the temptation
Date Fri, 10 May 2002 22:48:58 GMT


On Sat, 11 May 2002, Ceki Gülcü wrote:

> Date: Sat, 11 May 2002 00:06:40 +0200
> From: Ceki Gülcü <ceki@qos.ch>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> Subject: Re: Resisting the temptation
>
> At 14:47 10.05.2002 -0500, Richard Sitze wrote:
> >If the interface is based on the commons logging factory then the logger
> >(Log4J presumably) is already set by the time Log4J is encountered (else it
> >would go elsewhere).
> >
> >If not, the current default is going to go to Log4J anyway...  How SHOULD a
> >logger implementation bootstrap itself into commons logging, assuming it
> >wants to use a logger internally?
> >

I think the Log4J folks would like to rely on something more concrete than
the fact that the current discovery algorithm just happens to select that
first :-).

> >If these things are set in a manifest, what will happen if Log4J is in the
> >path AND we aren't using it,or worse we ARE using it in another component
> >of the system.  Will it force everything to the one logger?
>
> Good question.
>

By "set in a manifest", I assume we mean as a META-INF/services entry in
log4j.jar, and log4j.jar is in your classpath?  Then, the following
alternatives are possible:

* 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 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?)

Note also that these policies are basically identical to the policies that
JAXP uses to select DOM, SAX, and XSLT implementation classes for you.

>
> --
> Ceki
>

Craig


--
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