[slf4j-dev] Review of slf4j

[Niclas Hedhman]

On Friday 06 May 2005 22:11, Ceki Gülcü wrote:
> How many pojo's are there that take a Logger in their constructor? Phrased
> differently, is it the job of the App framework to provide loggers to the
> objects that it instantiates?

Yes, either in constructor or via some framework specific lookup mechanism. 

This is a fairly important aspect of IoC frameworks.
Effectively, the idea that each API provides its own discovery/lookup 
mechanism is the (really low) underlying reason for the JCL issue, but also 
many similar (but less frequent) ones.
Ultimately, it leads to;

 *  API provides a discovery/lookup mechanism.
 *  API is not allowed to do classloader management.
 *  API (with all its dependencies) will end up in some top level classloader.
 *  API extensions are not runtime deployable.

If the API does not provide the discovery/lookup mechanism, and instead rely 
on the Inversion-of-Control principles, that each object must be provided the 
services it needs, then all of the above "goes away".
Unfortunately, not everyone program according to IoC, so I doubt it can be 
made a rule to have Loggers provided to the components. BUT, if the component 
must identify itself to the LoggerFactory, then the framework would have a 
chance to figure things out.

The Log4J principle that the object itself should manage where in the Logger 
tree it should be placed, is IMHO a wacko idea, and I have so far not seen 
any reasonable solution (other than the standard class hierarchy) how that is 
managed.


ULogger logger = LoggerFactory.getInstance( this ).getLogger( subdomain );

getInstance( this ) is giving the Loggeractory provider (i.e. the framework) a 
chance to figure out which instance is requesting a Logger, and try to 
identify the associated logger for it, whether that be thru class 
hierarchies,  application structure or user sessions.

the "getLogger( subdomain )" is about a object may have more than one logging 
channel it won't to distinguish between. (Once upon a time (97/98) I actually 
used that for info, debug, warn distinctions, and didn't need so many methods 
in the Logger interface, and made the management tools a lot easier to 
write).


Anyway, I am only providing ideas and some of my ways are probably not 
appreciated by a larger audience, but I think Tomcat, JBoss, Geronimo, Spring 
et al, would be able to provide more feedback on Logger impact on frameworks 
and classloader management.


Cheers
Niclas