[slf4j-user] Recommendation for library writers: use thiscopy and paste wrapper around SLF4j to avoid default static initialization
Adam Gent
adam.gent at snaphop.com
Sat Mar 18 22:06:05 CET 2017
On Sat, Mar 18, 2017 at 4:50 PM, Ceki Gülcü <ceki at qos.ch> wrote:
>
>
> On 3/18/2017 21:26, Adam Gent wrote:
>
>> 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.
>
>
>
> I don't follow you. Can you give simplified example of the chicken and egg
> problem? Do you mean for example logback configuration which has as
> DBAppender writing to a database with a JDBC connector which itself uses
> slf4j for logging? This should work with the aforementioned event replay
> mechanism. Any other examples?
How do get the connection string for the DBAppender?
In traditional environments people used system properties or
environment variables but today people connect to other remote systems
to get configuration. Some examples are Zookeeper, Consul, etcd,
Google Cloud Metadata.
So I either need to write code that executes before the logging
backend to setup the environment. If the clients to the metadata
services kick off logging then logging will be configured incorrectly
(lets assume no reinitialization or substitute loggers).
To prevent this I could of course make an omniscient DBAppender that
gets the configuration (and then the log replay system would work) but
this requires me knowing about the underlying logging framework (and
writing a special appender for backend).
I actually did the appender route for awhile but I had various issues
particularly with old log4j and an older logback that didn't have
replay (or maybe it was reentry.. I can't recall). I also just prefer
having our code run first instead of the logging framework.
So what we do now is just use custom configuration and client
libraries that do absolutely zero logging making sure to run this code
before any other code that kicks off logging. However in some
environments despite what Joachim thinks this is nontrivial in say a
servlet environment or using Spring Boot because those guys have some
sort of static reference somewhere with getLogger.
--
CTO
SnapHop (snaphop.com)
(twitter) @agentgt (linkedin) http://www.linkedin.com/in/agentgt
(cell) 781-883-5182
More information about the slf4j-user
mailing list