[slf4j-dev] Consolidating the LoggerFactory / A better plugin mechanism

[Eric Crahen]

On 2/15/07, Boris Unckel <boris.unckel.mlg at gmx.net> wrote:
>
> just one thing:
> Could you explain what happens if two or more classes/jars provide the
> service?
> If more than one class/jar provides the service, which one is taken?
> Which one has to be taken by the factory?
>

The Service API allows you to enumerate all options. SLF4J has a choice,

#1: Accept the first JAR, report warning that you have others - this is
pretty much the same behavior as we have today - the difference is that with
the static binding method you will be unaware that you have deployed several
implementations and you'll just get what came first in the classpath. Here
we can at least issue a warning where we can not today.

#2: Allow some sort of precedence to be assigned. You might always prefer
the stderr logger in the case where multiple implementations are present.
The idea being is someone deployed an imlpementation wrote to a network and
one that wrote to a file they really might not be sure what they are doing
and stderr might be the best bet to inform them of the configuration error -
and again, the message can be very explicit - "hey, you deployed these
specific loggers, here is what to do"

#3: You could allow a property to select one if multiple are present. Sort
of like #2 but the precedence can be influenced by a system property. I'm
not a huge fan of this one either.


-- 

- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-dev/attachments/20070215/b7dd9b72/attachment.htm>