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

[Ceki Gülcü]

As this time SLF4J's scope is to provide a simple to follow recipe for
delaying the choice of the underlying logging system, especially in
complex environments. I can assure you that even such a unambitious
scope is not easy to achieve.

One of the reasons why SLF4J is relatively successful is due to its
simplicity. SLF4J only does static-binding and ito fails-fast. If
there is no slf4j-binding available SLF4J prints an error message and
dies immediately (it fails-fast).

The ServiceProvider interface is only available in JDK 1.6. Moreover,
it used the thread context class loader. SLF4J is not going to go on
that road in the immediate future. We first need to cut a stable 1.3
release with the low-tech approach we currently have. Anything more
sophisticated will have to wait for later.

At 09:50 AM 2/16/2007, Eric Crahen wrote:
>On 2/16/07, Jukka Zitting 
><<mailto:jukka.zitting at gmail.com>jukka.zitting at gmail.com> wrote:
>>Exactly, and I think this should be the *only* configuration SLF4J
>>would ever need. Any solution that requires extra configuration
>>properties or explicit precedence settings is IMHO too much.
>>
>>The fact that SLF4J always uses the implementation jar that is first
>>available in the classloading hierarchy is simple and easy to
>>understand. I don't see any good use cases that would require anything
>>more complex.
>
>You don't need to get as complicated as doing precedence, but I still 
>think that including the stderr logger as the fallback and default is the 
>way to go. This is exactly 0 configuration to get a working logger, deploy 
>slf4j-api jar. Additionally, it gives you a logger to report error 
>messages on when someone deploys multiple implementation jars. To get any 
>other logger, you deploy the implementation jar and it will be used instead.
>
>This is no extra configuration, its not really different from what we are 
>doing now.
>What you get out of it is:
>* a 0 config option - non existant now
>* a sane descriptive error reporting mechanism - non existant now.
>
>
>Those couple of legitimate cases you mentioned are valid (logback-access 
>for jetty logging, something else in a webapp for instance); but these are 
>detectable because we can still look at the ClassLoader that loaded the 
>logging implementation and only issue warning when there is more than one 
>in the same ClassLoader and not just more than one.
>
>--
>
>- Eric

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch