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/
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.
