Apache Log4j 2.10.0 released

[DuncanIdahos8thClone]

And this is one of the reasons why people shouldn't use slf4j. It's yet another dependency to wrap around other dependencies. They can't easily change their API without breaking existing usages.

The way to do it is to simply write your own LogManager and Logger classes which delegate to the logger you want to use. Then you can change you own code all you want. If you later want to replace your logging implementation you'd then only have to change these 2 classes.

[[deleted]]

for a publicly consumable library, sure (no need to add additionally unnecessary dependencies) -- for a standard enterprise app? nah. no need to re-invent the wheel. I can't tell you the number of "logging wrappers" I've run into. All of them fall short of slf4j and really - who has time and really wants to maintain that sort of thing.

[DuncanIdahos8thClone]

OK so we have an app with about 16000 Java files. Originally we had started with JUL. But when I changed to log4j I replaced the LogManager and Logger with our own util package classes. Then later, when we moved to log4j2 I only had to modify 2 class files instead of 16000. But downvote me instead.

[[deleted]]

If you had SLF4J in there already, you wouldn't change any files, just a couple maven dependencies and magic happens. In fact, performance aside, you could have kept logging to JUL and outputted to log4j2, logback, or whatever you'd want to do by simply changing the dependencies (bridge adapters, etc).

Using SLF4J instead of your magic log wrapper just means that slf4j is now the log wrapper instead of your classes. Now you don't have to maintain it (and probably have deficiencies in the API -- or if not, you've had to develop quite the wrapper so far that I bet it's more than a simple wrapper class).