I like it ;-)<br><br><div><span class="gmail_quote">On 2/17/07, <b class="gmail_sendername">Jacob Kjome</b> &lt;<a href="mailto:hoju@visi.com">hoju@visi.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Of course with the Service API that Eric Crahen<br>is pushing, the NOP implementation could be used<br>as the default fallback binding, packaged into<br>the slf4j-api.jar, and chosen if no other binding<br>is made available by the user.&nbsp;&nbsp;This would have following benefits...
<br><br>1.&nbsp;&nbsp;Remove the imposition of forcing a user to<br>provide a separate SLF4J binding jar, since the<br>default do-nothing binding would be used as a<br>fallback if no other binding is provided.<br><br>2.&nbsp;&nbsp;Remove the imposition of logging when it is
<br>not desired, and without having to actively provide slf4j-nop.jar<br><br>3.&nbsp;&nbsp;Remove the necessity of generating<br>slf4j-nop.jar, as it would already be part of slf4j-api.jar<br><br>4.&nbsp;&nbsp;Reduce user confusion.&nbsp;&nbsp;Instructions now read:
<br><br>&quot;To satisfy an SLF4J dependency, simply put<br>slf4j-api.jar in the classpath.&nbsp;&nbsp;Optionally, to<br>get logging output, add an SLF4J implementation<br>binding in the classpath alongside slf4j-api.jar.&quot;<br>
<br><br>With this setup, a user can depend on<br>slf4j-api.jar and be done.&nbsp;&nbsp;Only if logging is<br>desired would one need to add a binding that actually performs logging.<br><br><br>Thoughts?<br><br>Jake<br><br><br>At 10:37 AM 2/17/2007, you wrote:
<br> &gt;Ceki Gülcü wrote:<br> &gt;&gt; At 11:05 PM 2/16/2007, John E. Conlon wrote:<br> &gt;&gt;<br> &gt;&gt;&gt; Your right, neither do I want to increase the number of classes in the<br> &gt;&gt;&gt; org.slf4j packages.&nbsp;&nbsp;But we are basically doing the same kind of thing
<br> &gt;&gt;&gt; with the second approach as well - exposing our selves to greater<br> &gt;&gt;&gt; coupling by clients.&nbsp;&nbsp;By exporting the org.slf4j.spi package we are<br> &gt;&gt;&gt; exporting what was once a private package and all classes in it, on to
<br> &gt;&gt;&gt; the OSGi package matrix.<br> &gt;&gt;&gt;<br> &gt;&gt;<br> &gt;&gt; The o.s.spi package contains two interfaces, namely<br> &gt;&gt; LoggerFactoryBinder and MarkerFactoryBinder. I am not worried about<br>
 &gt;&gt; exposing these interfaces into the public.<br> &gt;&gt;<br> &gt;&gt;<br> &gt;That makes sense.&nbsp;&nbsp;I just committed&nbsp;&nbsp;the change.&nbsp;&nbsp;Project now builds<br> &gt;with -Posgi flag.<br> &gt;<br> &gt;End users will still only import 
o.s while adapters clients will import<br> &gt;both o.s and o.s.spi.<br> &gt;&gt;&gt; Right now we are in a very good position regarding client coupling to us<br> &gt;&gt;&gt; and dependencies we have on other third party jars.&nbsp;&nbsp;Although we are
<br> &gt;&gt;&gt; still using split packages to deliver our Logger service but now for<br> &gt;&gt;&gt; 1.5.0 we do the &#39;package join&#39; at maven build time versus before we had<br> &gt;&gt;&gt; our clients do it on the classpath.
<br> &gt;&gt;&gt;<br> &gt;&gt;<br> &gt;&gt; It&#39;s quite nice that we have the technical ability to package all<br> &gt;&gt; SLF4J classes within each binding. However, I am not 100% convinced<br> &gt;&gt; that doing so yields the best user experience, especially as seen by
<br> &gt;&gt; developers of libraries.<br> &gt;&gt;<br> &gt;&gt; Assume Alice is the developer of some library, say La. As far as<br> &gt;&gt; Alice is concerned, imposing slf4j-api as a dependency of La is<br> &gt;&gt; acceptable while imposing a binding is not. In SLF4J 
1.2, Alice has to<br> &gt;&gt; depend on a binding in La, typically slf4j-simple, and then let the<br> &gt;&gt; user change the binding. It would be more convenient if La depended on<br> &gt;&gt; slf4j-api only. This would allow the end-user to import La as is,
<br> &gt;&gt; including its dependency on slf4j-api without change.<br> &gt;&gt;<br> &gt;Perhaps I am not seeing it but, wouldn&#39;t it work like it always has?<br> &gt;Alice for her library still imposes the slf4j-api as a dependency and
<br> &gt;for testing uses one of the bindings.<br> &gt;&gt; For instance, if Bob was the author of some library, say Lb (how<br> &gt;&gt; original) which depended on La and by transitivity on slf4j-api, Bob<br> &gt;&gt; could use the SLF4J API without additional work.
<br> &gt;&gt;<br> &gt;Bob uses La for Lb which carries with it only the slf4j-api dependency,<br> &gt;Bob then uses whatever binding he wishes for testing his Lb.<br> &gt;<br> &gt;Sally now builds an application from Lb and uses whatever binding she
<br> &gt;wants but when packaging the application for end user distribution only<br> &gt;needs to add a slf4j binding to the installation zip.&nbsp;&nbsp;(Even if she<br> &gt;added the slf4j-api and the binding it should still work as expected.)
<br> &gt;<br> &gt;John<br> &gt;<br> &gt;_______________________________________________<br> &gt;dev mailing list<br> &gt;<a href="mailto:dev@slf4j.org">dev@slf4j.org</a><br> &gt;<a href="http://www.slf4j.org/mailman/listinfo/dev">
http://www.slf4j.org/mailman/listinfo/dev</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