[slf4j-user] Fail Silently on NOP implementation
Phillip Lord
phillip.lord at russet.org.uk
Fri Apr 29 08:11:35 UTC 2016
Joachim Durchholz <jo at durchholz.org> writes:
> Now you have a case where your library can also stand as an application.
> The best advice is to pull the application part out into a separate artifact.
> Let the application have a hard dependency on whatever backend you prefer.
> You mentioned that you have a REPL; it should actually go into the library,
> too. The main program just configures logging and starts the REPL.
Alas, I don't control the main program. Like most lisps, a REPL is an
intrinsic part of Clojure, as it is most lisps. And, there are several
ways of starting the REPL -- depending on whether you want it to
interact with the command line, through a socket or so forth. So the
REPL isn't mine.
> That way, people who write something more elaborate (say, a GUI around
> your REPL) can easily call the REPL without having to worry about the
> logging decisions that were right for your application.
In fact, I have actually done this -- I have plugged my library into a
GUI which then gives a REPL to change the data structures of the GUI
application, either accessable in a widget or via a socket.
>> I think including an explict dependency on the slf4j-nop backend is the
>> correct thing to do. Otherwise, slf4j-api prints an error message.
>
> Actually it's already the case.
> You're getting the message as a hint that tells you that you should really
> have made an explicit decision about the logging backend. That's because for
> the vast majority of cases, NOP logging is not what you want but SLF4J can't
> reasonably tell which backend is the right one to use.
It does say which is the right, default backend to use -- the NOP
logging.
>
> Heh. Indeed.
> I'd like to add this:
>
> 0) Include slf4j-nop in the class path of the main application.
>
> No insanity at all here.
Yes, this is what I have done. I will wait for Ceki to answer if he is
willing to provide a gentler mechanism for pacifying these error
messages, otherwise, this is the way to go.
Many thanks for your time!
Phil
More information about the slf4j-user
mailing list