[slf4j-dev] [Bug 225] New: log4j-over-slf4j Compatibility Enhancements: PropertyConfigurator, DOMConfigurator, NDC.

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=225

           Summary: log4j-over-slf4j Compatibility Enhancements:
                    PropertyConfigurator, DOMConfigurator, NDC.
           Product: SLF4J
           Version: 1.6.x
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: log4j-over-slf4j
        AssignedTo: slf4j-dev at qos.ch
        ReportedBy: jmsteward at gmail.com


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 Bug 170 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.

-- 
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.