[slf4j-dev] x4juli and slf4j

[Boris Unckel]

Hello,

this thread started at the user's list, but Ceki asked to answer on the
delevopers list for points regarding the implementation:

Ceki Gülcü wrote:
> A quick look at org.x4juli.X4JuliLogger and
> org.slf4j.impl.X4JuliLoggerFactory indicates that you have done a very
> good job. It is not exactly trivial to juggle between all these
> different systems.
Thanks.
>
> Did any parts of SLF4J give you a hard time? If so, I would
> appreciate if you could air your comments here or at dev at slf4j.org.
>
Due to parallel development I had to implement the different versions (i.E.
the one with the markers). This was more a part of sedulity (in German
"Fleissarbeit"), not a "hard time" in sense of design or implementation.
One of the best decisions was to use java.lang.String instead of Object for
the message. On the one hand for "my" implementation, on the other for a
good interface. It also allows the parallel implementation of
org.apache.commons.logging.Log and org.slf4j.Logger. In older versions I had
to provide two different implementations, which is bad for use in mixed
environments.

One part I personally like very much is the concept of "simple": Developers
in my project always had trouble with bad logging facades. In example:
Static methods with similiar method signature of non-static methods for
different tasks. Or "Level" as wrapper object (something like
WrapperClass.log(MyCustomLevelClass level, String message, Throwable t)).
Keep slf4j simple, many people will use it just for this reason.

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.

I have followed the discussion of "trace" and "fatal": I can follow an
argumentation that there is no use case behind it,
when you analyse it, both levels lead to abuse and bad design. OK. For
freedom of choice (I am a smoker, each package tells me that
I might get cancer, impotent or die slowly :-) ) it is better to offer such
things and spread the usage of the API, than making people build their own
(sometimes bad) wrapper. Projects without a consens about which kind of
thing belongs to a special level have a problem anyway (I had a discussion
with a developer who never had to keep things in production running: He used
debug XOR error, in a system with a wrapper which had ONE (sic!) logger
(category) for user code.)

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.

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?

> On the slf4j side, as soon as I get a chance, I'll update the
> slf4j.org web site so that it refers to x4juli under the native
> implementations section.
>
Great, open source - open mind.

Regards
Boris