[slf4j-dev] x4juli and slf4j

[Boris Unckel]

Good Morning,

> To address this problem, you could split x4juli to x4juli.jar and 
> slf4j-x4juli.jar (with the former depending on the latter). In this 
> setting, slf4j-x4juli.jar would contain slf4j classes (o.s.Logger, 
> o.s.ILoggerFactory, etc.) plus o.s.impl.StaticLoggerBinderbound to 
> o.s.impl.X4JuliLoggerFactory. x4juli jar would contain everything else, 
> that is the classes from org.x4juli. The down side of this solution is 
> requiring to jar files. On the up side, slf4j-x4juli.jar could be 
> replaced with another binding, if that is what the end-user really wanted
> to do. 

There may be another solution: The only difference betwen the default
JDK14LoggerFactory and X4JuliLoggerFactory is that X4JuliLoggerFactory has a
compile-time dependendy to x4juli and detects wheter to use native interface
or the normal wrapper class approach.
It would be easy to remove the compile-time dependency with the use of
reflection.
Second, the test whether to use native or wrapper approach, runs ONCE per
loading of the class (static constructor).
If slf4j would recognize a native implementation (not especially x4juli) in
their default distribution of JDK14Logger jar, I could remove all slf4j
classes.

>From an x4juli point of view there is currently one nasty dependency to the
interface classes of sl4fj and JCL. I already thought about putting them
into the default jar. There may be Classloader issues, when someone casts a
interface from the system classloader (where x4juli must stay as design of
java.util.logging, not by design of x4juli!) to an interface somewhere in a
child(grandchild) classloader.
But it is worth to discuss and try it.

What do you think?

Regards
Boris