Ceki Gulcu <[email protected]> writes: >> I do acknowledge the bootstrap difficulty this causes for SLF4J, but >> there are solutions. The issue of library vs. application only comes >> into question when we discuss the problem with your solution (i.e bind >> to nop). > > OK, admittedly, I am assuming that there is a distinction between > library vs. application, a distinction although natural to me might not > always be natural to others. > > FYI, I added the following paragraph to > http://www.slf4j.org/codes.html#StaticLoggerBinder > > If you are packaging an application and you do not care about logging, > then placing slf4j-nop.jar on the class path of your application will > get rid of this warning message. Note that embedded components such as > libraries or frameworks should not declare a dependency on any SLF4J > binding but only depend on slf4j-api. When a library declares a > compile-time dependency on a SLF4J binding, it imposes that binding on > the end-user, thus negating SLF4J's purpose.
This is good, although I would probably change the wording a bit, as it conflicts with the maven terminology. Refering statically to a SLF4J binding really would impose the choice (as you say). Adding a slf4j binding as either a compile *or* runtime scoped dependency would imply a choice, but not impose it, as in either case it can be over-ridden. > In any case, thank you for initiating and valiantly pursuing this > discussion. Such design questions are quite fundamental. And thanks to you, and everyone else for replying so thoughtfully. I shall leave the issue (and the list!) at this point. Phil _______________________________________________ slf4j-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/slf4j-user
