On Sat, Mar 18, 2017 at 3:45 PM, Ceki Gülcü <c...@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@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
