I don't understand your concern about reliance on the thread context class loader. The ServiceLoader mechanism is a well established method for doing this reliably. This happens all over the JDK, from character sets, to encryption schemes. It works very well and gives you a much cleaner separation.
<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 09:40 PM 2/12/2007, Eric Crahen wrote:<br>>On 2/12/07, Ceki Gülcü <<mailto:<a href="mailto:listid@qos.ch">listid@qos.ch</a>><a href="mailto:listid@qos.ch">listid@qos.ch</a>> wrote:<br>>><br>>>Given that there seem to be real demand for a standalone
slf4j-api.jar (at<br>>>compile time), I think I'll attempt to solve it by having slf4j-api depend<br>>>on a "bootstrap" module, containing a trivial implementation of<br>>>StaticLoggerBinder, just enough to get slf4j-api to compile. Bindings will
<br>>>need to provide actual real implementation as they do today.<br>>><br>>>I think this little change will make life easier for our users. I'll give<br>>>it a shot. As usual, we can revert if need be.
<br>><br>>Wouldn't moving that LoggerFactory I provided earlier solve this?<br><br>Yes and no. SLF4J does the binding at compile time avoiding reliance on the<br>value of the thread context class loader.<br><br>
<br>>Or is that what you were talking about?<br><br>No, I am talking about some thing else, an implementation that relies on<br>compile time binding.<br><br>>--<br>><br>>- Eric<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