On 2/16/07, <b class="gmail_sendername">Jukka Zitting</b> <<a href="mailto:jukka.zitting@gmail.com">jukka.zitting@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;">
Exactly, and I think this should be the *only* configuration SLF4J<br>would ever need. Any solution that requires extra configuration<br>properties or explicit precedence settings is IMHO too much.<br><br>The fact that SLF4J always uses the implementation jar that is first
<br>available in the classloading hierarchy is simple and easy to<br>understand. I don't see any good use cases that would require anything<br>more complex.<br></blockquote></div><br>You don't need to get as complicated as doing precedence, but I still think that including the stderr logger as the fallback and default is the way to go. This is exactly 0 configuration to get a working logger, deploy slf4j-api jar. Additionally, it gives you a logger to report error messages on when someone deploys multiple implementation jars. To get any other logger, you deploy the implementation jar and it will be used instead.
<br><br>This is no extra configuration, its not really different from what we are doing now. <br>What you get out of it is:<br>* a 0 config option - non existant now<br>* a sane descriptive error reporting mechanism - non existant now.
<br><br clear="all"><br>Those couple of legitimate cases you mentioned are valid (logback-access for jetty logging, something else in a webapp for instance); but these are detectable because we can still look at the ClassLoader that loaded the logging implementation and only issue warning when there is more than one in the same ClassLoader and not just more than one.
<br><br>-- <br><br>- Eric