On Sat, 11 May 2002, Ceki Gülcü wrote:
> Date: Sat, 11 May 2002 00:06:40 +0200
> From: Ceki Gülcü <[EMAIL PROTECTED]>
> Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
