[slf4j-dev] is there anyone out there?

[robert burrell donkin]

On Mon, 2005-05-02 at 18:48 +0800, Niclas Hedhman wrote:
> 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) ).

the good news is that the models UGLI and JCl have been converging on is
probably closer to the one you outlined than previously. i really think
that it's impossible to solve the problems i'm interested in without
having a specified API, a bridging implementation of that API to a
logging system (log4j).  i believe that (given a good specification) it
should be possible for a framework to create an implementation of the
specified API which would allow components to call the API which would
be backed by the kind of architecture outlined above.

one of my personal aims would be for components developed against a new
API to be capable of deployment either as bricks or as part of a more
sophisticated framework. 


> 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.

interesting :)

requests for this kind of thing came along a number of times. could you
expand a little (to make sure i understand correctly)? 

- robert