On 2/19/07, <b class="gmail_sendername">Ceki Gülcü</b> &lt;<a href="mailto:listid@qos.ch">listid@qos.ch</a>&gt; 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;">
<br>I do not wish to hide behind backward-compatibility excuses. We<br>finally have a nice and clear separation between slf4j-api and<br>slf4j-binding. Let&#39;s keep it clean and simple even if it costs an<br>extra jar on the class path.
<br><br>[1]<br><a href="http://www.qos.ch/pipermail/logback-user/2007-February/000129.html">http://www.qos.ch/pipermail/logback-user/2007-February/000129.html</a><br></blockquote></div><br>So we still do have a weak coupling thats based on contract rather than an interface in order to plug various logging implementations in. In that respect I&#39;m not sure the separation is nice and clean. Also, the opportunity isn&#39;t there with the static binding solution to actually report potential errors in configuration w/o the Service API. It simplifies a build, and it reduces the opportunity for error for new logger implementation writers. 
<br><br>Is there any actual technical reason the Service API is not being used? On a technical basis, it has advantages the other solution does not and it seems like there is just some general fear about because its description involved the word &quot;ClassLoader&quot;.
<br><br><br>-- <br><br>- Eric