References
[1] https://logback.qos.ch/
[2] https://stackoverflow.com/questions/178215/log4j-vs-logback
[3] https://howtodoinjava.com/log4j/slf4j-vs-log4j-which-one-is-better/
[4] https://vectorbeta.wordpress.com/2014/08/26/the-java-logging-quagmire/
SLF4J vs commons-logging
Apache Commons Logging and SLF4J are facades over actual logging implementations. Each of them does include an internal, simplistic logging implementation (“SimpleLog” for Commons Logging, “Simple” for SLF4J) but you’re meant to use a real implementation in production.
SLF4J was designed to do what commons-logging does but better
Basically you should replace your selfmade wrapper with slf4j IF and only IF you are not happy with it for some reason. While Apache Commons Logging is not really providing a modern API, slf4j and the new Log4j 2 facade is providing that. Given that quite a bunch of apps use slf4j as a wrapper it might make sense to use that.
log4j/logback vs slf4j
Simple Logging Facade for Java (SLF4J) is an API designed to give generic access to many logging frameworks; log4j being one of them. Which one you use, is then decided at deployment time, not when you write your code. Best practice is to use slf4j to for your own log statements, and then choose the appropriate backend for it (including log4j and logback by configuring to use them as a logging backend).
SLF4J does not replace log4j, they work together. It removes the dependency on log4j from your application and make it easy to replace it in future with more capable library.
Logback natively implements the SLF4J API. This means that if you are using logback, you are actually using the SLF4J API. You could theoretically use the internals of the logback API directly for logging, but that is highly discouraged. All logback documentation and examples on loggers are written in terms of the SLF4J API.
log4j vs logback
Logback is intended as a successor to the popular log4j project, picking up where log4j leaves off.
In summary, Logback seems to be the best option.