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

[Eric Crahen]

On 2/15/07, Boris Unckel <boris.unckel.mlg at gmx.net> wrote:
>
>
>  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.
>
> 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.
>
> 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,
>

I agree it isn't a fair comparison, but that doesn't matter - what matters
is peoples perception of what is easier if you want an API to be successful.
What you have to realize is that you are trying to push a 4th logging API on
a large user based on the planet earth who by an large, mostly use the
Logger interface. If you are used to not doing anything at all to get
messages printed on stderr, which I would say most folks are, then you will
have a bad experience if you switch to SLF4J and don't configure yourself
correctly.

As I said, deploying the correct implementation jar IS a kind of
configuration, weather you call it that or not.


Yes, I have mentioned that. Again: I have no problems with the
> ServiceProvider approach, and I did not write that.
>

All I did was quote your message, you might want to check what you wrote.


-- 

- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-dev/attachments/20070215/31232eb0/attachment.htm>