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

Sat Mar 18 16:40:16 CET 2017

The issue I've come across that's similar to this is integrating logging
with Spring Boot or other initialization style frameworks. The issue there
was that Spring Boot wants to defer logging initialization until it's
loaded up enough of its own configuration related code, but that code also
wants to use logging. Eager initialization of the logging system in Logback
and Log4j both cause issues in these sorts of environments. In Log4j, we
ended up using a similar pattern to the ServiceLoader files, but we added
some additional metadata there like API version compatibility.

On 18 March 2017 at 10:18, Adam Gent <adam.gent at snaphop.com> wrote:

> On Fri, Mar 17, 2017 at 6:47 PM, Ceki Gülcü <ceki at qos.ch> wrote:
> >
> > Hi Adam,
> >
> > --------------
> > Quoting from https://www.slf4j.org/faq.html#optional_dependency
> >
> > It is reasonable to assume that in most projects Wombat will be one
> > dependency among many. If each library had its own logging wrapper, then
> > each wrapper would presumably need to be configured separately. Thus,
> > instead of having to deal with one logging framework, namely SLF4J, the
> user
> > of Wombat would have to detail with Wombat's logging wrapper as well. The
> > problem will be compounded by each framework that comes up with its own
> > wrapper in order to make SLF4J optional. (Configuring or dealing with the
> > intricacies of five different logging wrappers is not exactly exciting
> nor
> > endearing.)
> > --------------
>
> Just to make my previous my points clear. My code (which is basically
> just use your own static method instead of LoggerFactory.getLogger())
> I'm proposing is to encourage users not to create their own wrappers
> but write their on LoggerFactory.getLogger() instead of reimplementing
> all of slf4j-api.
>
> This is not to make SLF4J optional. The code is to disable or
> intercept the static initialization of an API interface. I would
> actually argue that an API should never do static initialization but
> that ship has sailed. The framework or application should probably
> explicitly initialize SLF4J but I admit the way SLF4J is currently
> used and understood at this point it is probably easier. Consequently
> Just know that the logging framework is almost always the first thing
> to initialize (hence why one would really want to be configure it).
>
> To show how egregious this is just putting an annotation on a class or
> implementing an interface can cause of initialization of SLF4J which
> then kicks off the initialization of the logging framework which may
> or may not be configurable for interception.
>
> >
> >
> > --------------
> > Quoting from: http://stackoverflow.com/a/11360517/100970
> > and http://stackoverflow.com/a/11359358/100970
> >
> > Except the end user could have already done this customization for his
> own
> > code, or another library that uses log4j or LogBack. jul is extensible,
> but
> > having to extend LogBack, jul, log4j and God only knows which other
> logging
> > framework because he uses 4 libraries that use 4 different logging
> > frameworks is cumbersome. By using slf4j, you allow him to configure the
> > logging frameworks he wants. not the one you have chosen. Remember that
> > typical projects use myriads of libraries, and not just yours.
> > --------------
> >
>
> This is exactly my point. To control the initialization of our suite
> of applications we have to write custom code that intercepts log4j,
> log4j2, logback, etc all because there is no way to do it in SLF4J.
> SLF4J is not configurable!
>
> Why do we have all these different logging frameworks? Well because of
> legacy code or that is what that application prefers (e.g. zookeeper
> or solr or something). I'm talking in a microservice environment it is
> actually common to have  a zoo of logging frameworks (obviously not in
> the same app). I think you misunderstood me before and thought I meant
> having all sorts of logging frameworks in the same application.
>
> I guess ideally SLF4J should offer some sort of configuration (it
> already has system.properties it reads to do things) to do what I'm
> talking about but for the time being library writers can do what I'm
> proposing particularly if logging isn't really a critical aspect of
> the library.
>
> Finally most libraries you do have to go look up information on how to
> turn on logging for that particularly library. It is just a nasty fact
> of life. Libraries don't use Markers or logger name hierarchy in a
> standard way. Even then they still often (particularly for high
> performance libraries) have some system property or something to
> actually enable or disable logging.
>
> I'm just trying to offer a best practice or standard to prevent the
> above of every library being different or worse having a their own
> complicated wrapper. Ideally SLF4J would offer more than just a best
> practice.
>
> >
> > --
> > Ceki
> >
> > On 3/17/2017 22:28, Adam Gent wrote:
> >>
> >> Yes as noted in my not really javadoc comment:
> >>
> >> /*
> >> * Simply prefix Internal in front of LoggerFactory:
> >> * So instead of:
> >> * Logger logger = LoggerFactory.getLogger(MyClass.class);
> >> * It should be:
> >> * Logger logger = InternalLoggerFactory.getLogger(MyClass.class);
> >> */
> >>
> >> Obviously this creates tight coupling with LoggerService but that is
> >> OK because LoggerService is expected to be a copy and paste snippet
> >> (that is each library should have its own namespace LoggerService). It
> >> could also be multiple files. I just made it one file to encourage
> >> easy copy and paste.
> >>
> >> I use LoggerService in my own message bus library (it is a library
> >> that is sort of like hystrix + guava eventbus + amqp + reactivestreams
> >> that I plan on open sourcing someday). This library does it for
> >> performance reasons.
> >>
> >> I also have a configuration facade framework as well that has an
> >> opensource start here https://github.com/agentgt/configfacade .  Our
> >> internal version is far more sophisticated as well as actually
> >> production quality and is the one that uses its own LoggerService as
> >> well. This library does it for bootstrap reasons and to beat the
> >> logging frameworks initialization.
> >>
> >>
> >> I have seen other libraries that refuse to use SLF4J directly though
> >> because of its static binding. Many JBoss libraries IIRC such as
> >> RestEasy:
> >> https://bill.burkecentral.com/2012/05/22/write-your-own-
> logging-abstraction/
> >>
> >> Of course these libraries could have just wrapped the LogFactory
> >> creation but instead implement their own logging wrapper which is a
> >> lot more code as well as not implementing logging parameter
> >> replacement at all or correctly ("{}").
> >>
> >> -Adam
> >>
> >> On Fri, Mar 17, 2017 at 4:36 PM, Ceki Gülcü <ceki at qos.ch> wrote:
> >>>
> >>>
> >>> Hi Adam,
> >>>
> >>> Using ServiceLoader.load(LoggerService.class) is quite a good idea. I
> >>> think
> >>> we will have to go that way in future versions of SLF4J to be
> compatible
> >>> with Java 9.
> >>>
> >>> I suppose your library code no longer invokes
> >>> org.slf4j.LoggerFactory.getLogger().  How do you use LoggerService in
> >>> your
> >>> libraries?
> >>>
> >>> On 3/17/2017 16:51, Adam Gent wrote:
> >>>>
> >>>>
> >>>> Many library writers want to use SLF4j but may want to avoid the
> >>>> default initialization and binding process. In fact if it is a library
> >>>> and not a framework I recommend something like what I'm proposing.
> >>>>
> >>>> I have written a single very small copy and paste class that you can
> >>>> put in your own library to avoid default SLF4J initialization while
> >>>> allowing consumers of your library to pick whatever SLF4J
> >>>> initialization they like through the ServiceLoader mechanism. The
> >>>> class is meant to be copied and pasted such that you pick your own
> >>>> package (namespace) for the ServiceLoader part.
> >>>>
> >>>> The code is available at this github gist:
> >>>>
> >>>> https://gist.github.com/agentgt/28dc6e9724cb8b96ca08fc147476a7de
> >>>>
> >>>>
> >>>> There are several reasons why if you are a library writer to consider
> >>>> this pattern:
> >>>>
> >>>>  * Often library users don't want to see the annoying default missing
> >>>> slf4 binding messages
> >>>>  * Performance reasons. By defaulting to NOP you prevent accidental
> >>>> performance problems by a user of the library.
> >>>>  * You allow for even greater logging configuration and separation
> >>>> than possible with SL4J. For example one library could be configured
> >>>> to use a Logback SLF4J and another Log4j legacy SLF4J.
> >>>>  * If the library used to configured a down stream logging framework
> >>>> (ie logback) you might need interception (ie SubstituteLogger).
> >>>>
> >>>> Thoughts?
> >>>>
> >>>> I'm hoping perhaps the SL4J documentation recommend something like
> >>>> this for library writers.
> >>>>
> >>>> -Adam
> >>>>
> >>> _______________________________________________
> >>> slf4j-user mailing list
> >>> slf4j-user at qos.ch
> >>> http://mailman.qos.ch/mailman/listinfo/slf4j-user
> >>
> >>
> >>
> >>
> > _______________________________________________
> > 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
> _______________________________________________
> slf4j-user mailing list
> slf4j-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-user
>

-- 
Matt Sicker <boards at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-user/attachments/20170318/e32e6147/attachment-0001.html>