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

[Eric Crahen]

On 2/19/07, Ceki Gülcü <listid at qos.ch> wrote:
>
> In practice, the sun.misc.Service may well give the same results as the
> current static approach. However, that is not the point. The point is the
> difficulty of debugging the logging configuration by the end-user who
> might
> not be familiar with sun.misc.Service or properties files or reflection.
> However, even junior java developers are somewhat familiar with Java's
> basic class loading mechanism.
>

One of the features that I think you are missing is that by using the
Service api, you don't need your clients to understand anything about
properties files, classloading - or the fact that there is a service api.
You'll be able to emit an extremely human friendly error message that says,
"I didn't find any implementations deployed, you should choose one and
deploy it. You can read about this here http://link/to/relevant/docs", or "I
found that you've actually deployed several implementations, are you sure
you know what you are doing? You probably didn't mean to do this, you should
choose one and deploy it. You can read about this here
http://link/to/relevant/docs". Or variations where you can enumerate what
implementations were found, where they were and so on. This isn't a stretch
of the imagination, this is something thats quite straightforward to do.

This can become extremely user friendly. Even junior developers who don't
know how a class loading mechanism works can read those error messages.
Simpler implementation does not always equal simple end-user experience. In
this case, its actually the opposite. The difficulty of configuration is not
greater than the static binding, and the debugging is actually easier.


-- 

- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-dev/attachments/20070219/6d90caf4/attachment.htm>