We are not using logkit: we are using Avalon Logger, and the default configuration shipped with Cocoon use the LogKit implementation of Avalon Logger (you say the same below).
true
Why do we really need logkit? I honestly don't know.
Because it's not bloated?
well ...I think keeping an abstraction layer is not a bad idea. But the question which one to use... so this would be more about commons-logging vs avalon logging vs UGLI.
As for the abstraction layers I cannot really say which one of those is more bloated than the other. But since we a lot of components are already relying on commons-logging the question is whether is makes sense to get rid of another dependency.
For 2.2 we have jdk 1.4 as a requirement so we *could* ship without *any* logging implementation ...and everyone could just plug in what ever he wants.
That's one thing...
Your proposal omits an important point: why do we use IoC loggers? The classical way of getting a Category in log4j is to use :
private static Logger logger = Logger.getLogger(Blah.class);
That leads to a topological organization of logger hierarchies (it's the class name) whereas IoC-style logger the way we do it using the "logger" attribute allows for a functional organization of hierarchies, as we can group logs of related components into a single category whatever their class name, thus easing filtering.
...if you chose to get the logger from the class. Which you don't have to do.
But you are right. I probably the most important question is: do we need or do we want IoC style logging.
- I certainly don't want to start again something similar to the migration from Loggable (logkit-specific) to LogEnabled (not talking also of Composable to Serviceable).
I hear you ...such big changes *are* a PITA. And we need see whether it's worth it. For me I see UGLI being ruled out until someone can provide a good reason to switch. As already being pointed out - we still need the isBlaEnabled stuff with it. No matter whether in source code or added at build time.
So I see it like that:
commons-logging o one dependencies less o not IoC o potential classloader issues(?)
avalon logging o nothing to change o IoC
...I am not a friend of IoC-logging anymore. But whether that's worth the change? Don't know...
cheers -- Torsten
