11–20 of 58 posts
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.
The logging in java is supper idiotic. This is because everyone agrees that Java's logging is shit. 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.
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.
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'…
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'…
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. 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 fo…
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.
It's ugly advice. Wish there was a better alternative. Ideas on a post-card please.
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 for slf4j-nop to that dependency, but it's not the right way to do this. Those messages ar…
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.
It's a perfectly sensible default for a framework to warn you at runtime that it's not configured properly, and stderr is the appropriate channel for that to go out over. I would even go so far as to say that it should default to stderr output on warn/error messages unless explicitly muted, instead of merely switching to NOP output after the initial misconfiguration warning. An interpreter might prefer another default but I think that's probably the best default for most Java projects.
The way I see it here, Clojure built on top of a stack without understanding the caveats that go with the stack. It's simply a fact that Java logging is a mess, there are four major competing standards and you need to tell Java which one you prefer, because any project will eventually need to interact with all of them if it continues growing. It's a fact of building on that stack.
Earlier quoted context omitted.
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. 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 fo…
But it seems useful because you can decide what behavior your want for your project.
But there is no reason why a configurable library can't have reasonable default behavior if no configuration is supplied. While still being configurable. If you're winding up as a buried dependency that end developers may not be aware of or care about, you want to do this.
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'…
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.
Earlier quoted context omitted.
But it seems useful because you can decide what behavior your want for your project.
Right, it is configurable. But there is no reason why a configurable library can't have reasonable default behavior if no configuration is supplied. While still being configurable. If you're winding up as a buried dependency that end developers may not be aware of or care about, you want to do this.