Yes as noted in my not really javadoc comment: /* * Simply prefix Internal in front of LoggerFactory: * So instead of: * Logger logger = LoggerFactory.getLogger(MyClass.class); * It should be: * Logger logger = InternalLoggerFactory.getLogger(MyClass.class); */
Obviously this creates tight coupling with LoggerService but that is OK because LoggerService is expected to be a copy and paste snippet (that is each library should have its own namespace LoggerService). It could also be multiple files. I just made it one file to encourage easy copy and paste. I use LoggerService in my own message bus library (it is a library that is sort of like hystrix + guava eventbus + amqp + reactivestreams that I plan on open sourcing someday). This library does it for performance reasons. I also have a configuration facade framework as well that has an opensource start here https://github.com/agentgt/configfacade . Our internal version is far more sophisticated as well as actually production quality and is the one that uses its own LoggerService as well. This library does it for bootstrap reasons and to beat the logging frameworks initialization. I have seen other libraries that refuse to use SLF4J directly though because of its static binding. Many JBoss libraries IIRC such as RestEasy: https://bill.burkecentral.com/2012/05/22/write-your-own-logging-abstraction/ Of course these libraries could have just wrapped the LogFactory creation but instead implement their own logging wrapper which is a lot more code as well as not implementing logging parameter replacement at all or correctly ("{}"). -Adam On Fri, Mar 17, 2017 at 4:36 PM, Ceki Gülcü <c...@qos.ch> wrote: > > Hi Adam, > > Using ServiceLoader.load(LoggerService.class) is quite a good idea. I think > we will have to go that way in future versions of SLF4J to be compatible > with Java 9. > > I suppose your library code no longer invokes > org.slf4j.LoggerFactory.getLogger(). How do you use LoggerService in your > libraries? > > On 3/17/2017 16:51, Adam Gent wrote: >> >> Many library writers want to use SLF4j but may want to avoid the >> default initialization and binding process. In fact if it is a library >> and not a framework I recommend something like what I'm proposing. >> >> I have written a single very small copy and paste class that you can >> put in your own library to avoid default SLF4J initialization while >> allowing consumers of your library to pick whatever SLF4J >> initialization they like through the ServiceLoader mechanism. The >> class is meant to be copied and pasted such that you pick your own >> package (namespace) for the ServiceLoader part. >> >> The code is available at this github gist: >> >> https://gist.github.com/agentgt/28dc6e9724cb8b96ca08fc147476a7de >> >> >> There are several reasons why if you are a library writer to consider >> this pattern: >> >> * Often library users don't want to see the annoying default missing >> slf4 binding messages >> * Performance reasons. By defaulting to NOP you prevent accidental >> performance problems by a user of the library. >> * You allow for even greater logging configuration and separation >> than possible with SL4J. For example one library could be configured >> to use a Logback SLF4J and another Log4j legacy SLF4J. >> * If the library used to configured a down stream logging framework >> (ie logback) you might need interception (ie SubstituteLogger). >> >> Thoughts? >> >> I'm hoping perhaps the SL4J documentation recommend something like >> this for library writers. >> >> -Adam >> > _______________________________________________ > slf4j-user mailing list > slf4j-user@qos.ch > http://mailman.qos.ch/mailman/listinfo/slf4j-user -- CTO SnapHop (snaphop.com) (twitter) @agentgt (linkedin) http://www.linkedin.com/in/agentgt (cell) 781-883-5182 _______________________________________________ slf4j-user mailing list slf4j-user@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-user
