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

[Ceki Gülcü]

Hello,

It is a bit clearer now. I think the discussion boils down to a question of 
splitting the work and responsibility. In the current set up, SLF4J is 
oblivious to the existence of X4JULI and I would like to keep it that way. 
With the changes you propose, given that slf4j-jdk14.jar would become dual 
purpose (JUL and X4JULI). Thus, I'd need to test that slf4j-jdk14.jar 
worked with JUL and X4JULI, additional responsibility which at present time 
I would like to avoid.

Conversely, you would prefer to be unburdened by the need to synchronize 
your code with SLF4J without needing to fetch source code from the SLF4J 
branch. I propose to review the difficulty of synchronization in a few 
months time after we have more hindsight on the matter. Would that be OK 
with you?


At 09:52 PM 1/9/2006, Boris Unckel wrote:
>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

-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/