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/
_______________________________________________
dev mailing list
dev@slf4j.org
http://slf4j.org/mailman/listinfo/dev
