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

[Eric Crahen]

On 2/16/07, Jukka Zitting <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-dev/attachments/20070216/aab45d63/attachment.htm>