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.
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?
There's something that must be cleaned up: some of the subclasses of CascadingException log the exception and the chained exceptions, when JDK since version 1.4 (or 1.3?) does the same itself. So we could reduce the amount of redundant and verbose exception information that way.
About the particular "no match" message, we could simply avoid logging the exception in that particular case. However, this is a ResourceNotFoundException, just like when e.g. the source of a generator is not found. We should distinguish both cases with a new NoPipelineMatchException.
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.
There are too much debug logs in Cocoon. They were written when the components were being developed, and we may now remove most of them in components that have been stable for years.
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.
Really? I have no problems explaining it to people. Well, it would be maybe more understandable if the element names for targets were fixed e.g. "<target type="blah">" rather than defined by the TargetFactory name.
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
What do you mean by "logging channel"? The categories defined by the "logger" attribute? They aren't hardcoded?!?!
Now what I personally do when starting a new Cocoon app is to trash the whole category configuration in logkit.xconf and log everything in a single file (+ the filter for error.log). The current logkit.xconf shows all that is possible but it's really too much.
3) some parts of the system (apples! slide!) get put there by default, no matter if I turn their blocks on or not.
Uh? Problem in block-build.xml?
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?
A bit, but not as much as you ;-)
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
