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

[Adam Gent]

On Sat, Mar 18, 2017 at 3:45 PM, Ceki Gülcü <ceki at qos.ch> wrote:

> Logging needs to be set up somehow. SLF4J has adopted the most stupid
> approach imaginable for selecting the logging backend. The main advantage of
> this stupid approach is that it is easy to understand to anyone interested.

I agree. Again this would be for those that for some reason that don't
want to ship with any possible output caused by their library.
Probably a fringe case. Just to be clear I wasn't a strong proponent
but I wanted to play devils advocate for those that still would prefer
zero side effects.

>
> I somehow doubt that. NOPLogger does nothing, so invoking it costs a method
> call. Getting a NOPLogger involves reading the value of INITIALIZATION_STATE
> which is a volatile int. Unless reading volatile variables is expensive in
> Android, there is really no way to optimize logging with SLF4J+NOPLogger.
>

That is my point. The NOPLogger does nothing. It is what the library
would be picking as the default instead of relying on the backend
logger code (which requires initialization and overhead for filter).
Now if they have the NOP backend (which is different than the NOP
logger) that is different story but most are using logback or log4j2
these days.

If the library used Logging.getLogger() and used the backend logger
you would not get a NOPLogger. Most backend logging frameworks aren't
going to somehow know selectively to defer to the NOPLogger (or
equivalent NOP action) with out performing some logic. That is they
still have to perform logic whether to emit the trace messages or not.

I mean I generally agree my arguments are fairly weak because I'm
defending a small minority of libraries. That is part because
libraries that have these problems (chicken/egg, performance issues)
just avoid logging all together or write their own (e.g.
https://github.com/EsotericSoftware/kryo has its own).

>
> Why do you think you need your own interception? In multi-threaded boot-up
> process, SLF4J event replay just works. It's an internal process transparent
> to user code. In a single threaded boot-up, event replay works just as well.
> The interception is done by SLF4J while the logging back end is configuring
> itself and the intercepted events are replayed after the logging backed has
> finished configuring itself.
>

Because you now have to put all your initialization configuration
(like calling discovery services like zookeeper or consul) in the
backend logging framework and this is because the logging framework
almost always runs first unless you are extremely judicious about what
libraries you use to setup your application.

The real issue is you may need to configure the backend logging framework.

And this hard because we are in a cloud world where yeah you have to
connect a whole bunch of things to get configuration and those clients
need to do logging. This is a real problem that both dropwizard and
spring know about.

Yeah can customize your logging backend to run some code first but
this was and still sort of difficult (if you remember I was the one
who did the implementation for the ServiceLoader for logback).

And yeah you could just reinitialize the logging framework but not all
frameworks support that (well).

Yeah you could just write a custom SLF4J adapter for the library but
this is actually impossible for some libraries that natively speak
SLF4J.

Maybe others just don't run into these issues because they do file
based logging. We push the logs over the network to a queue. We prefer
this over the pull method but I guess  that is one major advantage of
the pull method (not having to configure the logger).




> --
> Ceki
> _______________________________________________
> slf4j-user mailing list
> slf4j-user at 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