On 2/15/07, <b class="gmail_sendername">Eric Crahen</b> <<a href="mailto:eric.crahen.lists@gmail.com">eric.crahen.lists@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<span class="q"></span><span class="q"><br></span>The Service API allows you to enumerate all options. SLF4J has a choice,<br><br>#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.
</blockquote><div><br>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.
<br><br>[ERROR] org.slf4j.LoggerFactory - Several Loggers were detected:<br></div></div>[ERROR] org.slf4j.LoggerFactory - Implementation 1 <br>[ERROR] org.slf4j.LoggerFactory - Implementation 2 <br>[ERROR] org.slf4j.LoggerFactory
- Implementation 3<br>[ERROR] org.slf4j.LoggerFactory - You should select and deploy only one of these Logger implementations..<br><br>This is MUCH clearer than a long stack trace followed by a really long single line error message.
<br><br>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.<br><br>-- <br><br>- Eric