Hello, Ceki Gülcü wrote: >> 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? Yes, after the mail I thought again about it and wrote the patch. Different from the description above: There is no compile or runtime dependency for slf4j to depend on x4juli. There are just slf4j classes involved.
> >> 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". :-) Yes, sorry for beeing unprecise. There is still the interface and the o.s.i.MessageFormatter. I will setup a test with this constellation (only o.s.Logger interface and MessageFormatter in x4juli, slf4j.jar with the new version in Bugzilla #10) in Tomcat and JBoss (hopefully representative enough). >> 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. You are right. Everything will be statically linked, there is no need for reflection or ClassLoader tricky behaviour, but I cannot prove that it will work in any constellation. In generall I believe there is no critical point, since x4juli _must_ resist in the system classloader. I hope to release x4juli 0.7 soon. Can you estimate a timeframe when the next slf4j version will arrive? Can you give me a hint whether you accept the patch in Bugzilla #10 or not? Is the strategy to check the underlying log system something for the o.s.i.Log4jLoggerFactory to avoid wrapper classes when nlog4j is present? Regards Boris _______________________________________________ dev mailing list dev@slf4j.org http://slf4j.org/mailman/listinfo/dev