No, this guy is 100% wrong. The distinction is absolutely clear. If someone else is expected to build on top of a framework he provides then he is building a library, and it would be inappropriate to tie future consumers to a back-end. This is relatively simple to fix - you mark his library as a dependency and add an additional <exclude> for slf4j-nop to that dependency, but it's not the right way to do this. Those messages aren't meant for him, they're meant for future consumers, and now after including his library they have to dig through and figure out why SLF4J suddenly broke.
I can't find exactly what this Tawny-OWL thing is (his link is broken), but it sounds like it might have some kind of interpreter application provided. If he is offering a finished application within the same build unit as his UI library, this is the "big ball of mud" architecture. The fix is to break his application out into a separate build unit that depends on his library. The application can then include slf4j-nop without messing up SLF4J for all his library's consumers. Maven Reactor can automatically build his dependencies when his main application builds, if desired.
The thing about having to deal with 2 different logging frameworks is exactly what SLF4J is meant to fix. SLF4J lets you route the messages from multiple sources to a single sink/backend defined by the final consumer application. Yeah, it sucks to deal with multiple logging frameworks, but that's simply how it is and you don't help anything by having a whinge about it. You include the routing/bridge modules (JUL-to-SLF4J, Commons-to-SLF4J, etc) in the final-consumer application and call it a day. If you don't want to do that, find some other dependency that doesn't use those logger frameworks.
My framework is built in Clojure. The interpreter is always there. Think of it like a statistics library with R.
The idea of a "main application" is itself not a clear one. There are a set of functions you can use. Whether you choose to launch directly over the library or import it is a matter of convenience.
Whoa. The author recommends including slf4j-nop as an explicit dependency of libraries?! This means that when a developer writes an application and forgets to include an slf4j backend, instead of getting a warning that no backend is configured, that developer will get absolutely no output. This is really bad advice.
This is a well understood problem and I think the design pattern SLF4J uses has become quite popular.
The ability to allow consumers to bind at runtime the implementation they want by providing an api jar is kind of a neat idea.
The thing I dislike the most is when libraries force me to use their logging runtime. If they need it just for tests they should add the 'test' scope and just use the 'api' jar as a 'compile' dependency.
It has become popular, but it is still wrong. If you're a nested dependency, then DON'T require end developers to be aware that you're there. Doing so makes you a leaky abstraction.
Though the author does have a point that fault here could be put on the library that added the dependency without a default logging behavior. However I'd still blame SLF4J for making the default case suboptimal.
It doesn't force anything though, unless you statically refer to the runtime. It does force you to exclude their logging backend, but that is straight-forward enough.
My feeling is that SLF4J and in general the boot strap initialization is fundamentally flawed in Java because of the plethora of libraries that do static initialization. I have been meaning to blog about this for sometime.
The reason is simple. Bootstrap configuration should load before logging but that is not the case.
In a large application it can be very difficult to control what boots up and the overall order of things being initialized particularly with SL4J, configuration frameworks like commons-configuration (archaius) and DI frameworks like Spring and Guice.
I understand that SLF4Js binding method is a static dependency to enable the very small case of Java JIT elision of method calls when using the NOOP logger.
But that is such a small case. If you have a library that is extremely hi performance do not use SLF4J for god sakes.
The reality is most large application projects should really create their own SLF4J binding so that they can control the initialization process particularly if you use a networking logging infrastructure such as AMQP. And this is fairly annoying because you will have to copy and paste the bridge library (ie because of the static nature it is impossibly to intercept the logging framework).
SLF4J should really do its binding dynamically (one option would be to use java.util.ServiceLoader). This is so that you could wrap and load existing bridges with out essentially having to copy and paste existing bridges.
Overall I would say if you have either a hi performance library, networking library, configuration library, or any other low level library please do not link to SLF4J. It is trivial to make your own one class logger that either uses system properties or what not to do its dispatching.
Some example libraries that do this correctly are the Kryo serializer, RESTEasy, and Tomcat (although flawed Tomcat does try).
Spring and most Apache projects some of the worse because they rely on Commons logging and the use static loggers on initialization (commons-config and most of Spring).
That's an all-or-nothing solution. As third-party libraries often use alternative loggers, and java.util.logging cannot be substituted on the classpath (because of the java.* namespace), then using JUL locks consumers out of using their own logging facade as it cannot be bridged to SLF4J.
I always found SLF4J's reasoning quite simple and logical and not at all an example of "those situations which show that software is difficult, and that often there are only compromises".
I think the core problem in this case is that the author is not clear if they are writing a library or a (command line) application.
The following workflow has always worked well for me:
1) Do you expect users of your project to use it by putting it in their classpath and calling its methods from their code? Then it's a library. You have no idea what else will be on the classpath and which context your library will be loaded in. (In fact, the user might not even be aware they are using your library thanks to transitive dependencies)
Libraries should never (if they can avoid it in any way) modify application-wide settings. So: Don't include any logger implementation at all, especially not the nop logger. (Please. Seriously. I've had to deal with misbehaving libraries in that regard and finding out why your logger settings are suddenly overwritten is a serious PITA.)
2) Do you expect your project to be used as a command line/standalone utility via java -jar ... or java -cp ...? Then you're writing an application. Do include a logger implementation and all necessary configuration. You can do it safely here as no one else should be using your project as a dependency.
3) Your project is a mix of 1) and 2) : Find out which parts of your project are library and which are application and split into sub-projects accordingly.
There are a few special cases I see, but not many:
4) You're writing unit tests for a library project: Do include a logger implementation, but make sure it's only visible to the test system. E.g., in Maven, you would add the logger implementation as a test-scoped dependency and put all configuration in src/test/resources.
5) You're writing a plugin/servlet/etc: Read up on your host system and find out if they provide logging or if it's your responsibillity. Proceed accordingly.
6) You're not using SLF4J but one of your dependencies does and so you get that message: Think about using SLF4J in your own project. Really. It's becoming almost a standard and usually you can keep using your old logging framework below it - but it will make things much easier later on. But if you don't want to, for some reason...
6a) If you're writing a library: Don't do anything at all. Do not include any logger implementation. See 1). The user of your library will be in a much better position to deal with the problem than you are.
6b) If you're writing an application: Include the slf4j-xxx implementation that corresponds to your logging framework: The log events from your dependency will be routed to the logging framework you're using and you can continue like you did before. If you're very certain you don't want any logging from any library using SLF4J, use the nop logger - however that is a very unusual case and a very inflexible solution.
It's a set of clojure code that I expect people to use in an interactive shell by, yes, calling methods. Whether people do that within an IDE, directly at a REPL or by running a script is up to them.
I'm still not understanding why I should perform major surgery on my tool for the sake of a logging library which is a transitive dependency.
Nor am I understanding why I should pass the error message that confused me on to downstream users. I'm happy to make the decision rather than sit on the fence.
Yes, this is exactly right. What a fucking nightmare. Every time I need to set up java logging for a new project, update a project, revisit an old project, I am dragged back to logging configuration hell.
Which logging package do I use? What is the logging config file called and where do I put it? How do I specify it? What do I do if different packages use different packages? A logging layer on TOP of other logging packages only makes things worse.
I'm sure many Java people remember the XML library hell. Each time you integrated another package that relied on XML configuration, you had to be sure to have the right version of the xerces library. Except that XML was simpler because XML itself didn't change that much. Logging is much worse.
To go on an even longer rant: Everything has become so fractured and distributed in the name of good modularity. Except that the interfaces are underspecified, or if adequately specified, they keep wiggling around. And good luck finding documentation to help you configure. It's got to match your version of every component, or you will likely fail. I am working on a project involving jetty, a Postgres database, a JDBC connection pool, and a logging system. Absolutely conventional stuff. I spent a couple of DAYS trying to do things the right way, doing XML config of everything. I absolutely could not make it work. I finally wrote my own trivial connection pool and configured everything in code. Took half an hour, done. I don't care that I can't swap out my logging system at runtime. That's a stupid thing to do anyway. When I need to change my connection pool, I will modify my code configuring it and re-deploy. The slightly improved flexibility is just not worth the fragility and maintenance headaches of doing things the "right" way.
Yeah, it's the exact situation described in that XKCD: "There are 14 competing standards! Let's create one that is perfect for everyone's use-case!" "There are 15 competing standards..."
And, as you noticed, pretty much every Java project will reach a point where it has to deal with all four-ish of the major logging frameworks. Some module, somewhere, will include an Apache dependency and then you get JCL, and some other purist will insist on java.util.logging and away you go.
With that said, it really isn't that bad to fix. You can use the SLF4J bridge modules and dump all 4 of the logging systems to a single output system. This doesn't actually have to be via SLF4J either - there are modules to dump SLF4J out to JCL or JUL or whatever.
This is one of those things about Java that's annoying as hell to get set up, but you plug through it for an hour and then you never need to touch it again. And the next time you can crib from your working build and 99% of it will be the same.
I do not think Java is the only outlier here. In general library authors should never force a logger to write to anything. It should be a do-nothing logger. It should provide a configuration so logs are going through the application utilizing the library. If I am wrong interpreting your comment, let me know.
paulmd|9 years ago
I can't find exactly what this Tawny-OWL thing is (his link is broken), but it sounds like it might have some kind of interpreter application provided. If he is offering a finished application within the same build unit as his UI library, this is the "big ball of mud" architecture. The fix is to break his application out into a separate build unit that depends on his library. The application can then include slf4j-nop without messing up SLF4J for all his library's consumers. Maven Reactor can automatically build his dependencies when his main application builds, if desired.
The thing about having to deal with 2 different logging frameworks is exactly what SLF4J is meant to fix. SLF4J lets you route the messages from multiple sources to a single sink/backend defined by the final consumer application. Yeah, it sucks to deal with multiple logging frameworks, but that's simply how it is and you don't help anything by having a whinge about it. You include the routing/bridge modules (JUL-to-SLF4J, Commons-to-SLF4J, etc) in the final-consumer application and call it a day. If you don't want to do that, find some other dependency that doesn't use those logger frameworks.
phillord|9 years ago
The idea of a "main application" is itself not a clear one. There are a set of functions you can use. Whether you choose to launch directly over the library or import it is a matter of convenience.
theanomaly|9 years ago
phillord|9 years ago
setheron|9 years ago
The ability to allow consumers to bind at runtime the implementation they want by providing an api jar is kind of a neat idea.
The thing I dislike the most is when libraries force me to use their logging runtime. If they need it just for tests they should add the 'test' scope and just use the 'api' jar as a 'compile' dependency.
btilly|9 years ago
http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...
Though the author does have a point that fault here could be put on the library that added the dependency without a default logging behavior. However I'd still blame SLF4J for making the default case suboptimal.
phillord|9 years ago
agentgt|9 years ago
In a large application it can be very difficult to control what boots up and the overall order of things being initialized particularly with SL4J, configuration frameworks like commons-configuration (archaius) and DI frameworks like Spring and Guice.
I understand that SLF4Js binding method is a static dependency to enable the very small case of Java JIT elision of method calls when using the NOOP logger.
But that is such a small case. If you have a library that is extremely hi performance do not use SLF4J for god sakes.
The reality is most large application projects should really create their own SLF4J binding so that they can control the initialization process particularly if you use a networking logging infrastructure such as AMQP. And this is fairly annoying because you will have to copy and paste the bridge library (ie because of the static nature it is impossibly to intercept the logging framework).
SLF4J should really do its binding dynamically (one option would be to use java.util.ServiceLoader). This is so that you could wrap and load existing bridges with out essentially having to copy and paste existing bridges.
Overall I would say if you have either a hi performance library, networking library, configuration library, or any other low level library please do not link to SLF4J. It is trivial to make your own one class logger that either uses system properties or what not to do its dispatching.
Some example libraries that do this correctly are the Kryo serializer, RESTEasy, and Tomcat (although flawed Tomcat does try).
Spring and most Apache projects some of the worse because they rely on Commons logging and the use static loggers on initialization (commons-config and most of Spring).
drostie|9 years ago
https://web.archive.org/web/20160505153552/http://www.russet...
http://webcache.googleusercontent.com/search?q=cache:9BEl9sv...
ninjakeyboard|9 years ago
chvid|9 years ago
tadfisher|9 years ago
twic|9 years ago
xg15|9 years ago
I think the core problem in this case is that the author is not clear if they are writing a library or a (command line) application.
The following workflow has always worked well for me:
1) Do you expect users of your project to use it by putting it in their classpath and calling its methods from their code? Then it's a library. You have no idea what else will be on the classpath and which context your library will be loaded in. (In fact, the user might not even be aware they are using your library thanks to transitive dependencies)
Libraries should never (if they can avoid it in any way) modify application-wide settings. So: Don't include any logger implementation at all, especially not the nop logger. (Please. Seriously. I've had to deal with misbehaving libraries in that regard and finding out why your logger settings are suddenly overwritten is a serious PITA.)
2) Do you expect your project to be used as a command line/standalone utility via java -jar ... or java -cp ...? Then you're writing an application. Do include a logger implementation and all necessary configuration. You can do it safely here as no one else should be using your project as a dependency.
3) Your project is a mix of 1) and 2) : Find out which parts of your project are library and which are application and split into sub-projects accordingly.
There are a few special cases I see, but not many:
4) You're writing unit tests for a library project: Do include a logger implementation, but make sure it's only visible to the test system. E.g., in Maven, you would add the logger implementation as a test-scoped dependency and put all configuration in src/test/resources.
5) You're writing a plugin/servlet/etc: Read up on your host system and find out if they provide logging or if it's your responsibillity. Proceed accordingly.
6) You're not using SLF4J but one of your dependencies does and so you get that message: Think about using SLF4J in your own project. Really. It's becoming almost a standard and usually you can keep using your old logging framework below it - but it will make things much easier later on. But if you don't want to, for some reason... 6a) If you're writing a library: Don't do anything at all. Do not include any logger implementation. See 1). The user of your library will be in a much better position to deal with the problem than you are. 6b) If you're writing an application: Include the slf4j-xxx implementation that corresponds to your logging framework: The log events from your dependency will be routed to the logging framework you're using and you can continue like you did before. If you're very certain you don't want any logging from any library using SLF4J, use the nop logger - however that is a very unusual case and a very inflexible solution.
phillord2|9 years ago
I'm still not understanding why I should perform major surgery on my tool for the sake of a logging library which is a transitive dependency.
Nor am I understanding why I should pass the error message that confused me on to downstream users. I'm happy to make the decision rather than sit on the fence.
puppetmaster3|9 years ago
So every library uses something else. I have a small project and have 4 logging systems (that I had to integrate).
ps: if you are a business person and have an option on this, I don't care for it regardless of your pov.
geophile|9 years ago
Which logging package do I use? What is the logging config file called and where do I put it? How do I specify it? What do I do if different packages use different packages? A logging layer on TOP of other logging packages only makes things worse.
I'm sure many Java people remember the XML library hell. Each time you integrated another package that relied on XML configuration, you had to be sure to have the right version of the xerces library. Except that XML was simpler because XML itself didn't change that much. Logging is much worse.
To go on an even longer rant: Everything has become so fractured and distributed in the name of good modularity. Except that the interfaces are underspecified, or if adequately specified, they keep wiggling around. And good luck finding documentation to help you configure. It's got to match your version of every component, or you will likely fail. I am working on a project involving jetty, a Postgres database, a JDBC connection pool, and a logging system. Absolutely conventional stuff. I spent a couple of DAYS trying to do things the right way, doing XML config of everything. I absolutely could not make it work. I finally wrote my own trivial connection pool and configured everything in code. Took half an hour, done. I don't care that I can't swap out my logging system at runtime. That's a stupid thing to do anyway. When I need to change my connection pool, I will modify my code configuring it and re-deploy. The slightly improved flexibility is just not worth the fragility and maintenance headaches of doing things the "right" way.
paulmd|9 years ago
https://xkcd.com/927/
And, as you noticed, pretty much every Java project will reach a point where it has to deal with all four-ish of the major logging frameworks. Some module, somewhere, will include an Apache dependency and then you get JCL, and some other purist will insist on java.util.logging and away you go.
With that said, it really isn't that bad to fix. You can use the SLF4J bridge modules and dump all 4 of the logging systems to a single output system. This doesn't actually have to be via SLF4J either - there are modules to dump SLF4J out to JCL or JUL or whatever.
http://www.slf4j.org/legacy.html
This is one of those things about Java that's annoying as hell to get set up, but you plug through it for an hour and then you never need to touch it again. And the next time you can crib from your working build and 99% of it will be the same.
uriahc|9 years ago
(Gradle dependencies format)
compile group: 'ch.qos.logback:logback-classic:1.1.3'
compile group: 'org.slf4j:jcl-over-slf4j:1.7.12'
compile group: 'org.slf4j:jul-to-slf4j:1.7.12'
compile group: 'org.slf4j:log4j-over-slf4j:1.7.12'
At least you only need to configure one logging subsystem then.
yeukhon|9 years ago
[1]: http://docs.python-guide.org/en/latest/writing/logging/#logg...
bhaak|9 years ago
azeirah|9 years ago
unknown|9 years ago
[deleted]
unknown|9 years ago
[deleted]