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
