Issues replacing Log4j with LogBack, log4j-over-slf4j.jar shortcomings

Question

So I've been porting some of our services to use Logback over log4j and I've been using the log4j-over-slf4j jar to spoof log4j for our legacy dependencies. The only issue is log4j-over-slf4j doesn't implement many of the classes of log4j so I'm seeing a decent few class not found exceptions from dependent jars. How have people got around this? Is it enough to just put the nlog4j in your classpath instead of the log4j-over-slf4j jar? I haven't tested this last idea yet but I'm planning on it tomorrow.

Reference:

• http://www.slf4j.org/legacy.html
• http://www.slf4j.org/nlog4j/

Answer 1

The only issue is log4j-over-slf4j doesn't implement many of the classes of log4j so I'm seeing a decent few class not found exceptions from dependent jars. How have people got around this?

Well, I guess you're facing "problems" explicitly mentioned in the Bridging legacy APIs link you posted:

When does it not work?

The log4j-over-slf4j module will not work when the application calls log4j components that are not present in the bridge. For example, when application code directly references log4j appenders, filters or the PropertyConfigurator, then log4j-over-slf4j would be an insufficient replacement for log4j. However, when log4j is configured through a configuration file, be it log4j.properties or log4j.xml, the log4j-over-slf4j module should just work fine.

If the dependent JARs are under your control, you should really try to migrate the code using the SLF4J Migrator tool.

Is it enough to just put the nlog4j in your classpath instead of the log4j-over-slf4j jar?

This might solve the ClassNotFoundException but I wonder how the whole logging is going to work. And given that NLog4J is no longer actively developed, I wonder if this is a good long term solution.

Answer 2

I suggest you contact the slf4j user list describing your situation.