<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Eric,<br>
<br>
now the mails occur in wrong order, thanks for the link, in my other
mail I tried to find something about it.<br>
Answers below.<br>
<br>
Eric Crahen wrote:
<blockquote
cite="mided0c429e0702151332t5c131601qad15c84c9b6be62a@mail.gmail.com"
type="cite">Please read the Service API docs.<br>
<a
href="http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html">http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html</a><br>
</blockquote>
I got your mail just while sending my second answer, thanks for the
link.<br>
<blockquote
cite="mided0c429e0702151332t5c131601qad15c84c9b6be62a@mail.gmail.com"
type="cite"><br>
The benefit over the current mechanism is that you have a type safe
plugin implementation & a clean separation between interface and
implementation.<br>
</blockquote>
I DO like the ServiceProvider approach.<br>
<blockquote
cite="mided0c429e0702151332t5c131601qad15c84c9b6be62a@mail.gmail.com"
type="cite"><br>
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. <br>
<br>
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.
<br>
<br>
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. <br>
</blockquote>
yes.<br>
<blockquote
cite="mided0c429e0702151332t5c131601qad15c84c9b6be62a@mail.gmail.com"
type="cite"><br>
On 2/15/07, <b class="gmail_sendername">Boris Unckel</b> <<a
href="mailto:boris.unckel.mlg@gmx.net">boris.unckel.mlg@gmx.net</a>>
wrote:
<div><span class="gmail_quote"></span>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">>
......<br>
> factory = f;<br>
> if(f == null) {<br>
> // TODO: Should there be a simple fall back on a System.out
logger?<br>
> // TODO: Perhaps the simple loggers is included with
SLF4J-API and<br>
> // TODO: Is selected always, unless another implementation is<br>
> provided<br>
> }<br>
<br>
please do not do that: Put in an RuntimeException with a clear error
<br>
message what is missing.</blockquote>
<div><br>
That is why this is labeled as a TODO, I'm not sure this is the right
thing to do.<br>
</div>
</div>
</blockquote>
<blockquote
cite="mided0c429e0702151332t5c131601qad15c84c9b6be62a@mail.gmail.com"
type="cite">
<div>
<div><br>
Saying this makes someone "too stupid" to use the system is an ignorant
statement that is in no way objective.
<br>
<br>
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.
<br>
<br>
</div>
</div>
</blockquote>
Yes, and I am against this fallback, but not against the
ServiceProvider approach.<br>
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.<br>
I think the separation is one of SLF4Js benefits and shows clean design
and packaging.<br>
<br>
<irony><br>
What about a default with java.util.logging? It is delivered with
JDK1.4+ :-)<br>
</iron><br>
<blockquote
cite="mided0c429e0702151332t5c131601qad15c84c9b6be62a@mail.gmail.com"
type="cite">
<div>
<div>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.
<br>
<br>
</div>
</div>
</blockquote>
SLF4J does work "out of the box" and will work "out of the box" with
the ServiceProvider approach, no problem with it.<br>
<blockquote
cite="mided0c429e0702151332t5c131601qad15c84c9b6be62a@mail.gmail.com"
type="cite">
<div>
<div>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.
<br>
</div>
</div>
</blockquote>
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.<br>
<br>
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,<br>
properties) and a dozen of possible misconfigurations. The wrapper
itself is OK (very excellent documented code, excellent internal
logging messages), but<br>
the problem is the complexity.<br>
<blockquote
cite="mided0c429e0702151332t5c131601qad15c84c9b6be62a@mail.gmail.com"
type="cite">
<div>
<div><br>
Again, this is an option that you have, I'm not demanding it<br>
</div>
<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">In
other words:
<br>
The change of the implementation is done by replacing the implementation<br>
jar,</blockquote>
<div><br>
Still true for what I proposed!<br>
</div>
</div>
</blockquote>
Yes, I have mentioned that. Again: I have no problems with the
ServiceProvider approach, and I did not write that.<br>
<blockquote
cite="mided0c429e0702151332t5c131601qad15c84c9b6be62a@mail.gmail.com"
type="cite">
<div><br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The
next user comes with a proposal: Please put in a property, I want to<br>
deliver all implementations just in my war, the<br>
customer should use a property when he wants to use my application.<br>
Next one: My ugly application server offers "shared" or "common"
<br>
libraries. I have put this jar in path xy and that jar<br>
in the application, it does not work? Could you offer a diagnostic
function?</blockquote>
<div><br>
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.
<br>
</div>
</div>
<br>
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.
<br>
</blockquote>
<br>
This is a completely different point: SLF4J has ONE way to configure. I
think this is easy to understand, easy to maintain.<br>
The problem in my sample usecase is not the configuration itself, but
the if, else, else, else code in the LoggerFactory.<br>
<br>
In short:<br>
I am voting for a minimal, simple solution, avoiding any complexity not
needed.<br>
This is no call against the ServiceProvider....<br>
<br>
Regards<br>
Boris<br>
<br>
</body>
</html>