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

[Eric Crahen]

On 2/15/07, Eric Crahen <eric.crahen.lists at gmail.com> wrote:
>
>
> 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.


This is a good case for a fallback stderr logger, an invalid configuration
(multiple implementations) detected is another excellent example of when you
really don't have a good logger to select, and we have a bunch of
information to give a user. It would be a very good user experience to see a
message like this if they have misconfigured thier environment.

[ERROR] org.slf4j.LoggerFactory - Several Loggers were detected:
[ERROR] org.slf4j.LoggerFactory -   Implementation 1
[ERROR] org.slf4j.LoggerFactory -   Implementation 2
[ERROR] org.slf4j.LoggerFactory -   Implementation 3
[ERROR] org.slf4j.LoggerFactory - You should select and deploy only one of
these Logger implementations..

This is MUCH clearer than a long stack trace followed by a really long
single line error message.

This fallback logger would also be useful in reporting other debug
information about what SLF4J is doing, which is another feature of LOG4J
that people would miss. The -Dslf4j.debug=true equivalent of -
Dlog4j.debug=true options.

-- 

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