[slf4j-dev] x4juli and slf4j

[Boris Unckel]

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