Hi Jake, That is an interesting thought. Adding the nop bindings to the slf4j-api.jar. Which is just what we did with the nop bindings - added the classes from the slf4j-api.
> 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. Turning this around a bit. - For the 1.3.0-SNAPSHOT (at this time) - a user can depend on the slf4j-nop.jar and be done. Only if logging is desired would one need to replace that jar with a binding that actually preforms logging. I apologize for not taking part in the discussion about the Service API. With this release I have focused on the OSGi runtime requirements for slf4j plugin functionality. IMHO they are very similar. So allow me to investigate some more before I comment further. kind regards, John Jacob Kjome 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 > _______________________________________________ dev mailing list [email protected] http://www.slf4j.org/mailman/listinfo/dev
