Re: [slf4j-dev] [Bug 10] Enhancement for support of native implementations in JDK14Logger

[Boris Unckel]

Hello,

I quoted from two messages regarding the same point, sorry, but
they belong together:
> Given that you already have this code in X4JuliLoggerFactory class, there 
> is no benefit in replicating it in JDK14LoggerFactory.

>From http://article.gmane.org/gmane.comp.java.slf4j.devel/437
> Although a benign refactorization,  I tend to decline the patch for the 
> sample reason that it does not have any practical effect. Unless I 
> misunderstood something, it does not solve the x4juli+slf4j+log4j
> problem (you would still need to split x4juli into two parts).
There would remain some classes in x4juli: o.s.Logger
o.s.i.MessageFormatter. I would not provide an slf4j-x4juli.jar because
there is already one: the slf4j-jdk14.jar which detects the native
implementation.
This seems to me a solution for the x4juli+slf4j+log4j case. If the user
wants to use JDK logging (and has x4juli in the backenend of the JDK
logging) he gets the optimal solution (without any tricks, just by putting
slf4j-jdk14.jar on the classpath and remove any other). If the user wants to
use slf4j-log4j12.jar with logj4 (or any other), he puts in that jar.

There would be no need for an slf4j-x4juli.jar, because the intention of the
user is clearly expressed when using slf4j-jdk14.jar.
By the design of JUL (not! by x4juli) you cannot choose between x4juli and
JUL in the same JVM at runtime. No user will enable x4juli and wonder why
his JDK logging goes through it. But he will wonder, if slf4j-log4j12.jar
x4juli.jar is present and the slf4j calls go through x4juli.

> Your refactorization puts additional onus on the JDK14LoggerFactory 
> class. 
> It would now have to be aware that other implementation of JDK14Logger 
> such as X4JULI exist. 
Yes, once per load of the class, and without any tricky detecting (Is there
a problem with instanceof I am not aware of?)

> Moreover, x4juli can achieve the same result by replacing 
> JDK14LoggerFactory class with X4JULILoggerFactory, which you have already 
> done. 
Yes, thats right. But I would have to split the jars and have additional
work with keeping all other slf4j classes in sync with the slf4j source
tree. That would not be needed if the patch has been applied.
Once the interface of slf4j has a release status, changes will affect all
using code and therefor less likely.

Please review the patch again under two points: Which disadvantages are
there for users who do not use x4juli and want to use (the patched)
slf4j-jdk14.jar with JUL? How fast can a bugfix regarding the factory/any
other feature of slf4j be passed to x4juli without a copy of the classes in
the x4juli source tree?

Regards
Boris