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