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

[Boris Unckel]

Hello,

Eric Crahen wrote:
> I've been using the SLF4J API in some of my work and one thing about 
> it that makes it very awkward, from a dependency mangement standpoint, 
> is that one of the core APIs - the LoggerFactory - is actually not a 
> part of the slf4j-api package. Instead, its actually reimplemented in 
> each of the slf4j implementations. This is awkward for various reasons,
> ......
>     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.
SLF4J has a very nice concept:
api.jar + implementation.jar => working system
If someone does not understand that, he is
a) ignorant to documentation
b) too stupid to understand the documentation
(Sorry, I could not resist, I do not want to start a flame war...)

In other words:
The change of the implementation is done by replacing the implementation 
jar,
do not change this for any case.
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?

Regards
Boris