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.)
--------------
--------------
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.
--------------
You need to consider the Kantian argument. What will happen if every
library developer follows your pattern? In my opinion, the situation
will be not just bad but completely untenable for the end-user.
--
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ü <[email protected]> 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
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-user
_______________________________________________
slf4j-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-user
