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

[Boris Unckel]

Good evening,

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

The dual purpose is correct. For JUL and any native combination of JUL and
SLF4J. There are not many ways to combine a different interface with JUL
than overwriting Logger and supply a different LogManager under the hood.
Do you see this as problem of your personal workload? I can provide
additional unit tests (not this week anymore) and contribute additional
changes for the build process for testing.

> 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? 

It is o.k. My goal is to keep x4juli in line with slf4j and have good
support for it. I will split the jars for x4juli 0.7 to provide slf4j users
the freedom of choice between x4juli and safe use of a different
sl4fj-xyz-log implementation.

Additionally there is a good argument for this strategy - slf4j is nearly
production ready and I will not speed up running with x4juli releases,
because quality is more important than a 1.0 which has a quality of an bad
alpha release. (This is open source, no need for aggressive time to market).
Think of JDOM, which had a really long 0.x releases over years.

Regards
Boris