On Sat, Mar 18, 2017 at 4:50 PM, Ceki Gülcü <c...@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 _______________________________________________ slf4j-user mailing list slf4j-user@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-user
