[slf4j-dev] x4juli and slf4j

[Ceki Gülcü]

Comments inline.

At 10:26 PM 12/20/2005, Boris Unckel wrote:
[snip]

>I think one of the most important design decisions (espescially in open
>source) is freedom of choice within a custom (propietary) implementation.
>A wrapper should (as slf4j does) be an interface so people can implement it
>as they like. If they have crude ideas, no problem, it never will be the
>offered in the provided default implementation. There is an excellent
>solution to provide this freedom of choice in slf4j -> Logger and
>ILoggerFactory as interface, binding can be changed.

Imposing 'message' to be a String instead of Object (in printing methods of 
org.slf4j.Logger interface) was quite a difficult decision. I wonder how it 
affected you as a developer of x4juli. If I understand correctly, it had an 
effect but I wonder why... :-)

>One wish at the end from x4juli point of view:
>Please keep your interface (as it is) compatible with java.util.logging and
>org.apache.commons.logging.Log
>so that a wrapper class is not needed to provide comfort for
>java.util.logging users.

Except for the addition of new parameterized printing methods accepting 
Object[], I do not foresee any changes to org.slf4j.Logger any time soon. 
If possible, I would like to see o.s.Logger to be frozen after version 
1.0final.

>Finally a question to classloading issues:
>The provider of a J2EE container (i.E. Tomcat, but not focussed on this
>implementation) server decides for x4juli, the server has
>parent first classloading enabled for security reasons.
>There is an app (read carefully, I did not write webapp) using slf4j in
>third party JAR and log4j natively (for whatever reason):
>Where does the log of the third party JAR appear, if both x4juli and log4j
>are configured to serve a root category? Why is static binding a solution
>for this problem, what is the advantage?

If I am not mistaken, the way x4juli is packaged now, either the x4juli's 
SLF4J binding or log4j's binding for SLF4J would win, which is actually OK, 
except that it would not be possible to predict which binding would win, 
which is *bad*.

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.

>Great, open source - open mind.

Thank you.

>Regards
>Boris

--
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/
   Improve your Sudoku skills at http://www.sudoku-grok.com/