5 ms·
Not to be a pessimist but, I can do without more versions of log4j. The pain and annoyance of fighting version conflicts from multiple dependencies and the des
by mbell 14y ago
Not to be a pessimist but, I can do without more versions of log4j.
The pain and annoyance of fighting version conflicts from multiple dependencies and the desire of some to include slf4j directly in their jar files gives me FAR more pain than anything syntactic related to how the logger actually works. If you want to truly improve logging, find a way to avoid this mess.
- eternalban 14y agoThe standard logger in JDK is entirely serviceable.
- mbell 14y agoThat doesn't fix anything. Examples: One dep want log4j-api 1.6.4 one wants 1.4, this doesn't matter to the client but I have to make sure to override one in maven to make sure the API version matches the back end version. When your project has 20 dependencies all using log4j, its a pain in the ass and makes your POM quite ugly. Two deps stupid enough to include slf4j in their JAR files, now my build process consists of pulling the deps from maven, then running a script to manually strip out the slf4j files from the jar. Yes this is the authors fault but a logger that would allow 2 versions on the classpath would be amazing, granted it would require some trickery with the class loader to make work.
- mbell 14y agoAnd of course I got slf4j and log4j backward in my examples.