I'm currently developing a new project for my employer and recently made the decision to replace log4j with slf4j & logback. However as close as I came to completing this replacement I have finally come to terms with its impracticability and will need to unfortunately undo my changes & revert to log4j. The reason is because we have a number of first-party reusable "component" libraries that have been around for a decade or so. My new project, like many many of our other projects, require some parts of these legacy components. Because of the sheer number of scattered projects dependent on these components I am absolutely unable to alter any of their code. So I setup my new project with slf4j-api-1.6.1.jar, slf4j-ext-1.6.1.jar, logback-classic-0.9.29.jar & logback-core-0.9.29.jar, and I setup the legacy components to use log4j-over-slf4j-1.6.1.jar, slf4j-api-1.6.1.jar & slf4j-ext-1.6.1.jar.

PropertyConfigurator Issue: A class used by many other projects for universal logging configuration exists in one of these component libraries and it uses org.apache.log4j.PropertyConfigurator. Although my project does not use the aforementioned class, it does require other classes from the library in question. Per reading through slf4j documentation I understand PropertyConfigurator is intended not to be supported. I understand the decision not to support its functionality but it doesn't make much sense to me that it should prevent code from compiling. I just need to be able to compile this code using log4j-over-slf4j, whether or not PropertyConfigurator is fully functional is a non-issue as my project does not use it, though other projects do use it and log4j will likely indefinitely remain in their classpaths'. So I propose a "bare bones" class be created at org.apache.log4j.PropertyConfigurator within log4j-over-slf4j. While it doesn't affect me I think it makes sense for org.apache.log4j.xml.DOMConfigurator too. Although I do see that org.apache.log4j.xml.DOMConfigurator does exist in the slf4j repository. Is that a sign this is being addressed?

NDC Issue: This is a similar issue, where NDC is used within a legacy component, but my project also relies on that legacy usage of NDC for its contents to ultimately be apart of the log's pattern. This is subsequently used for reporting purposes. I came across the bug, that I can now not locate, where org.slf4j.NDC was added to slf4j-ext built atop org.slf4j.MDC with some basic functionality. NDC compiled fine using log4j-over-slf4j so I thought I was in the clear. I went ahead and wrote a class extending ClassicConverter that emulates log4j's NDC pattern so my new project that was using logback could output the NDC contents that the legacy component was controlling through org.apache.log4j.NDC. Nothing outputted to my log from the NDC pattern. I determined my NdcConverter class, conversion rule, and pattern were all correct. The break is between log4j-over-slf4j's org.apache.log4j.NDC and slf4j-ext's org.slf4j.NDC. org.apache.log4j.NDC is purely "bare bones" with all the methods but nothing within them. It doesn't make sense NDC, also seemingly unofficially supported by slf4j, has functionality in slf4j-ext but not the legacy bridge log4j-over-slf4j. This should be resolved in a similar manner as log4j-over-slf4j's org.apache.log4j.MDC and slf4j-api's org.slf4j.MDC where the former's methods call the latter's methods. Or would it be better design for the org.apache.log4j classes (MDC & NDC) to extend their org.slf4j countparts? I found SLF4J-161 that dismisses this NDC idea due to ...

"This would require a slf4j-ext dependency in log4j-over-slf4j. Because of that, log4j-over-slf4j would then require Java>=1.5."

... Has a log4j-over-slf4j-ext component been considered? Perhaps you could migrate the loosely supported items to such a component; e.g. org.apache.log4j.NDC, org.apache.log4j.PropertyConfigurator & org.apache.log4j.xml.DOMConfigurator.

While I'm designing things to be portable and allow for our legacy libraries to be purged and switched out with brand new code, it is not a possibility any time soon. I require those libraries to get other more crucial parts of the project into production. So slf4j is not an option for me despite my preference for it. These scenarios are not unique to me and I hope slf4j addresses them so it can become a more realistic option for those transitioning out of legacy code bases.

Happy trails.