Please do, I really believe the ServiceLoader mechanism is a lot less hacky than the static binding thing happening now. <br><br>The ClassLoader problems you had with the JCL are completely different and do not exist with this solution (and those JCL issues don't mean using ClassLoaders is always a bad thing either ;).
<br><br><a href="http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html">http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html</a><br><br><br><div><span class="gmail_quote">On 2/13/07, <b class="gmail_sendername">
Ceki Gülcü</b> <<a href="mailto:listid@qos.ch">listid@qos.ch</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">At 10:12 PM 2/13/2007, Eric Crahen wrote:
<br>>I don't understand your concern about reliance on the thread context class<br>>loader. The ServiceLoader mechanism is a well established method for doing<br>>this reliably. This happens all over the JDK, from character sets, to
<br>>encryption schemes. It works very well and gives you a much cleaner<br>>separation.<br><br>The SLF4J approach is pretty dumb but it is also easy to follow when things<br>go awry. Not relying on class loader machinery is one the hard-earned
<br>lessons from JCL. Admittedly though, I am not that familiar with the<br>ServiceLoader mechanism so I'll have a closer look at it.<br><br>--<br>Ceki Gülcü<br>Logback: The reliable, generic, fast and flexible logging framework for Java.
<br><a href="http://logback.qos.ch">http://logback.qos.ch</a><br><br>_______________________________________________<br>dev mailing list<br><a href="mailto:dev@slf4j.org">dev@slf4j.org</a><br><a href="http://www.slf4j.org/mailman/listinfo/dev">
http://www.slf4j.org/mailman/listinfo/dev</a><br></blockquote></div><br><br clear="all"><br>-- <br><br>- Eric