[slf4j-user] Recommendation for library writers: use thiscopy and paste wrapper around SLF4j to avoid default static initialization

[Ceki Gülcü]

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
>