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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]