[slf4j-dev] x4juli and slf4j

[Ceki Gülcü]

At 10:35 AM 12/23/2005, Boris Unckel wrote:
>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.


This is essentially what you have proposed in bug report #10.
http://bugzilla.slf4j.org/show_bug.cgi?id=10

Correct?

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

How could you remove all slf4j classes given that the dependency on
o.s.Logger interface would still persist? Maybe you mean something 
different when you say "remove". :-)

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

I think the refactoring you propose in report #10 has its merits. However, 
I fail to see how it could help in resolving the problem at hand.

>Regards
>Boris

-- 
Ceki Gülcü

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