Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Then apache decides to put new people on log4j, do a backward incompatible v2 design that nevertheless is worse than slf4j. Why?

slf4j itself isn't a logging framework. It's a facade to logging frameworks.

Simple Logging Facade for Java ( https://www.slf4j.org )

It needs a logging framework behind it - log4j, log4j2, logback, commons, JUL.

The question is "why do log4j2?"

Logback went from the log4j1.x path ( https://logback.qos.ch )

Log4j2 has a lot of features that weren't present when the project started ( https://en.wikipedia.org/wiki/Log4j#Apache_Log4j_2 ).

There is a licensing difference between Logback (LGPL) and Log4jx (Apache Commons).



> Log4j2 has a lot of features

Apache projects in general have this feature creep seeping into every single one of their products that I have used.

It's just hard to trust apache projects now.


> It needs a logging framework behind it - log4j

Minor nit: log4j doesn't implement the slf4j interface, though. If you do want log4j to do your logging, but use slf4j in your application, you need to include a "bridge" library that adapts slf4j to log4j. And, conversely, if you have dependencies that use log4j, but want things to end up going through your slf4j-supporting backend (say, logback), you need to exclude the "real" log4j jar and include a different library that implements log4j's interface and forwards calls to slf4j.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: