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

[Adam Gent]

I guess to simplify what I'm saying is you could of course do the
configuration lookup (or bootstrap) in your backend logging framework
which will work thanks to the event replay. The problem is that it is
awkward to do most of your initialization in the logging framework let
alone something so specific like an Appender .

Imagine explaining to other developers... oh yeah our initialization
code that setups singleton metadata (like environment info such as
region and various other cloud metadata)... the DBAppender makes the
first call to it. Its confusing to follow just like it is confusing to
configure who initialized the logging framework first (well with a
debugger it isn't but whatever).

But yeah I'm not really making any strong points one way or the other.
I mean it isn't pretty but you can get buy and I'm not sure how SLF4J
at this time really could help (that is as much as I hate its simple
static initialization it is to your point the right way).


On Sat, Mar 18, 2017 at 5:06 PM, Adam Gent <adam.gent at snaphop.com> wrote:
> 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



-- 
CTO
SnapHop (snaphop.com)
(twitter) @agentgt (linkedin) http://www.linkedin.com/in/agentgt
(cell) 781-883-5182