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