[slf4j-dev] is there anyone out there?

[Niclas Hedhman]

On Monday 02 May 2005 05:00, robert burrell donkin wrote:
> On Sun, 2005-05-01 at 21:13 +0200, Ceki Gülcü wrote:
> > At 08:29 4/27/2005, Niclas Hedhman wrote:
> > >On Tuesday 26 April 2005 21:30, robert burrell donkin wrote:
>
> <snip>
>
> > >I hope that this project will set the playing field in a manner making
> > > such implementations possible, yet not hamper people who are not
> > > interested in them.
> >
> > Excluding class loader quacks, how could slf4j hamper a given
> > implementation's extension mechanism. I am sure it could be done
> > maliciously, but in good faith?
>
> i believe niclas is approaching this from an application framework
> perspective. most application frameworks provide some sort of logging
> framework. many employ a hierarchical approach (so, for example instance
> A is the child of instance B and so the logger for A is a child of the
> logger for B). good support for this was missed by JCL.

Yes, entirely correct.

Classloader management is required, but in App frameworks this must exist 
anyway, so it is not such a big deal.

If we take Log4J as an example of a typical "problem" compared to LogKit;

  * Somewhat weak definition of what constitutes API (client code usage),
    Impl (Log4J internals) and SPI (formatters, appenders etc.)

If this was a clear-cut case, _I_ could;

  - bundle the API separately and stick it very high up in the classloader
    hierarchy, depending on that it will rarely change.

  - provide the Impl separately, and update it on the fly when bugs has been
    fixed.

  - support SPI extensions to be loadable in runtime (as we do for LogKit),
    if/when need arises. A derivation of this is that I can create new 
    SPI extensions and load without restart of application.

(to be precise, LogKit does not provide this functionality, it is just nicely 
modular to support the framework to do these kind of tricks.)

This project will at least allow me to treat the API as a separate entity and 
Log4J as an implementation without SPI extension capability (can perhaps 
introduce this in Log4J over time as well :o) ).


Robert also mentioned the child logger management being part of the 
application framework's concern space. I would like to highlight that it is 
not desirable that the addChildLogger() is exposed in the Logger interface, 
but through some other well-define management interface, to avoid client 
abuse. This is perhaps not within the scope of this project.



Cheers
Niclas