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>
<br>The benefit over the current mechanism is that you have a type safe
plugin implementation & a clean separation between interface and implementation.<br><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><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><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>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>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><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><br>The whole point of using the Service API is that you provide 1 core jar with LoggerFactory who loads the services from the additional implementation jar that you deploy.
<br><br></div>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><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><br>-- <br><br>- Eric