Am 29.04.2016 um 10:11 schrieb Phillip Lord:
Joachim Durchholz <j...@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.
I see your problem, but you should tell the Clojure guys that you need
the logging backend to be configurable.
Though I'd be surprised if there isn't a way to configure that. You
probably can write a main program that starts the REPL.
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.
Then your GUI can pull in whatever logger you prefer.
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.
For 99% of the cases, it's not the right backend.
It's not really the default. It's an error message.
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.
I fail to see how that approach is non-gentle.
Having to exclude a dependency is less.
Silently nopping out all log messages without giving any message is
worse, at least for those who do want logging messages, i.e. about every
single server application on the planet.
Many thanks for your time!
You're welcome.
Regards,
Jo
_______________________________________________
slf4j-user mailing list
slf4j-user@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-user
