Stefano Mazzocchi wrote:
I don't want to go into a bikeshedding war about logging but *EVERY SINGLE TIME* I install a cocoon application I have to completely rewrite the logging defaults.3) is solved with 2.2 - in addition, adding new categories, targets or even factories can be done by just adding a new logging configuration that is included from the main logkit.xconf - like we do for the cocoon.xconf. So, if you want to change the logging for the portal block, go into the WEB-INF/xconf directory and edit the portal.logkit
Not tweak or improve: start over! And it's starting to piss me off.
It's insane the amount of crap that gets generated in the logs because the {throwable} clauses are all over the place... do we really think its useful to know each and every line that was involved in understanding that the sitemap didn't know how to process a URL?
You work on your application for a few minutes and you have a megabyte of crap: try to understand what's signal and what's noise.
Sure, it's configurable: there is a way to turn all that crap off, but:
1) logkit has the most unintuitive configuration schema ever imagined.
2) there is no centralized archive of the default logging channels used by the various parts of the system, so even if somebody wanted to do the filtering herself, there is no way unless looking into million lines of code
3) some parts of the system (apples! slide!) get put there by default, no matter if I turn their blocks on or not.
Configurable is nice, but too much crap is not: it increases the noise and reduces the signal.
Now tell me, am I the only one frustrated by this?
file.
And you all know my famous rt about changing logging in cocoon....
Ok, let's be more helpfull: actually I don't care about the logkit configuration. What really bugged me was that changing log levels is way too hard. So again 2.2 has a solution for this, which might look a little bit hacky, but is in fact really handy:
You can specify a system property "org.apache.cocoon.override.loglevel" with the log level you want and all categories defined in the logkit.xconf use this loglevel. So changing from the default to DEBUG is just starting Cocoon with the property, and turning everything off is easy as well.
(2.2 has a lot of new configuration features that I wanted to discuss as soon as my prototyping is finished)
I really think that having one log channel with one log configuration file and one log level would be just fine. People might decide to tune it later, if they need and don't use the 'tail|grep' filtering tecnique (or log4j chainsaw kindatools, which work the same way)
-- Stefano.
