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