commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: [slf4j-dev] Common Logging API
Date Fri, 05 Aug 2005 17:50:50 GMT
On Friday 05 August 2005 19:44, Ceki Gülcü wrote:
> Do you see any disadvantages to the ILoggerFactory injection approach?

It is ugly, and not the norm so far. Components are generally not expected to 
do "fabrication", and in the IoC folks view, getChildLogger() is not a 
fabrication, just plain retrieval of something that "exists".

> Alternatively, do you see any advantages?

Without checking classloading issues, possibly passing the Logger instance to 
the ILoggerFactory for the creation of a child logger is reasonable. (and not 
that ugly).
One could possibly define a separator for hierarchies, and just go by a 
logger.getName() + Logger.sep + "child"...


What I am about to say now has been up and about several times, I think.
Why not sponsor more than a single approach under the same umbrella ?
There are several ways to do it, but I think a better IoC support solution is 
desirable, yet without distracting other users.

1. Introduce a IoCLogger interface, and we discuss that with IoC peeps 
thoroughly, i.e. Spring, Pico, HiveMind and possibly Geronimo.

2. If possible, see if there is something that can be done at Factory level to 
allow frameworks to provide implementations that can make the bridge between 
normal and IoC codebases, so that the output is within comprehension.

3. Document the required behaviour when normal Loggers are used in IoC enabled 
frameworks.


AND this issue is more complex now, when Markers has been introduced, as I 
have personally not evaluated the "new possibilities" this can introduce.



Cheers
Niclas


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message