[slf4j-dev] Consolidating the LoggerFactory / A better plugin mechanism

[Boris Unckel]

Hi Eric,

now the mails occur in wrong order, thanks for the link, in my other 
mail I tried to find something about it.
Answers below.

Eric Crahen wrote:
> Please read the Service API docs.
> http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html
I got your mail just while sending my second answer, thanks for the link.
>
> The benefit over the current mechanism is that you have a type safe 
> plugin implementation & a clean separation between interface and 
> implementation.
I DO like the ServiceProvider approach.
>
> Today, including the LoggerFactory in each implementation jar; it 
> works only because the author of all the LoggerFactory classes 
> happened to use the same signature, there was no strong connection - 
> just careful coding. The compiler is able to help you whereas with the 
> current approach it cannot.
>
> With the Service API, you include and code against LoggerFactory that 
> delegates to one of several implementations of a LoggerFactoryService 
> interface. This is the class pImpl idiom. The benefit is that is very 
> easy to plugin in new service implementations, and its easier to write 
> them since you are only implementing and interface and not trying to 
> go line for line with some other file trying to match the correct 
> signature of a class. The compiler is able to help you whereas with 
> the static binding approach it cannot.
>
> The current method is called static binding, but that is actually not 
> what is happening - were it a static binding you would have compiled a 
> reference to a specific class into the LoggerFactory and that is not 
> what has happened. This still is a runtime binding.
yes.
>
> On 2/15/07, *Boris Unckel* <boris.unckel.mlg at gmx.net 
> <mailto:boris.unckel.mlg at gmx.net>> wrote:
>
>     > ......
>     >     factory = f;
>     >     if(f == null) {
>     >       // TODO: Should there be a simple fall back on a
>     System.out logger?
>     >       // TODO: Perhaps the simple loggers is included with
>     SLF4J-API and
>     >       // TODO: Is selected always, unless another implementation is
>     > provided
>     >     }
>
>     please do not do that: Put in an RuntimeException with a clear error
>     message what is missing.
>
>
> That is why this is labeled as a TODO, I'm not sure this is the right 
> thing to do.
>
> Saying this makes someone "too stupid" to use the system is an 
> ignorant statement that is in no way objective.
>
> Realizing that you have the *option* to deal with this error by 
> defaulting to a simple logger that prints to stderr. With the current 
> implementation you have a dead stop and thats it. Its not by design, 
> thats a consequence of the static binding approach we are using.
>
Yes, and I am against this fallback, but not against the ServiceProvider 
approach.
Fallback seems to me like mixing API.jar and implementation, SLF4J was 
delivered with a clean separation, once you mix it, you never get it 
clean again.
I think the separation is one of SLF4Js benefits and shows clean design 
and packaging.

<irony>
What about a default with java.util.logging? It is delivered with 
JDK1.4+ :-)
</iron>
> Many people place a great deal of value on having a working system out 
> of the box, and including a fallback to stderr in the case of 0 
> configuration (deploying the correct jar *is* a kind of configuration) 
> is one way to get that. There are various reasons that you might want 
> to do this, and there are reasons you might not want to do this. I 
> think falling back on the system.err logger as a default is a sane 
> option if you value a 0 configuration solution. If you haven't read 
> the docs and just want a working logger this is a good experience, if 
> you haven't read the docs and it doesn't work outright that is a bad 
> experience. If, like yourself, you have read the docs and *want* a 
> dead-stop because you take it to mean there was a deployment error, 
> perhaps you set a system property to prevent the default from kicking in.
>
SLF4J does work "out of the box" and will work "out of the box" with the 
ServiceProvider approach, no problem with it.
> This is especially valuable in a situation where you migrate people 
> away from log4j. Inevitably, when you are moving people away from what 
> they are familiar with - there are comparisons. So in the case of 
> migrating people away from log4j, when they forget to configure the 
> system correctly, there is a stderr default. If they make the same 
> error in slf4j there is an error and the program halts, the first 
> thing I'm bound to hear in this situation is, "Log4j wouldn't have 
> done that". However much you may disagree with log4j's approach, the 
> comparison is inevitable, and I have first hand experience to back 
> this claim up.
This is not a correct comparison: People cannot migrate from an full log 
API implementation to an log wrapper without choosing an underlying full 
log API.

People migrating away from a famous wrapper are disappointed about that 
wrapper because it has a dozen of options to configure (default and 
fallback implementation, service provider approach,
properties) and a dozen of possible misconfigurations. The wrapper 
itself is OK (very excellent documented code, excellent internal logging 
messages), but
the problem is the complexity.
>
> Again, this is an option that you have, I'm not demanding it
>
>     In other words:
>     The change of the implementation is done by replacing the
>     implementation
>     jar,
>
>
> Still true for what I proposed!
Yes, I have mentioned that. Again: I have no problems with the 
ServiceProvider approach, and I did not write that.
>
>     The next user comes with a proposal: Please put in a property, I
>     want to
>     deliver all implementations just in my war, the
>     customer should use a property when he wants to use my application.
>     Next one: My ugly application server offers "shared" or "common"
>     libraries. I have put this jar in path xy and that jar
>     in the application, it does not work? Could you offer a diagnostic
>     function?
>
>
> I don't understand your question/statement here; but with the 
> ServiceLoader API, a customer is able to provide thier own sl4f 
> implementations inside thier WAR file. As long as you don't deploy 
> slf4j implementations in the application servers shared classpath, 
> then there is no conflict - again, this is not different than the 
> current behavior.
>
> If you are talking about someone installing a webserver with all slf4j 
> implementations's installed and a system property lets a webapps 
> select which is loaded, then I don't think that makes a whole lot of 
> sense. The webapp is going to want to configure where the log goes, 
> and you have a deployment/configuration dependency on some slf4j 
> implementation. This is closer to a policy decision I don't think is 
> relevant to slf4j.

This is a completely different point: SLF4J has ONE way to configure. I 
think this is easy to understand, easy to maintain.
The problem in my sample usecase is not the configuration itself, but 
the if, else, else, else code in the LoggerFactory.

In short:
I am voting for a minimal, simple solution, avoiding any complexity not 
needed.
This is no call against the ServiceProvider....

Regards
Boris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-dev/attachments/20070215/713d0f7d/attachment.htm>