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.
That would help.
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.
I really don't care how this is done, as long as simple things end up with simple log messages and the signal is used for when things break down.
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.
I don't mind the existance of debug logs, I *DO* mind that we ship with them turned on and for no reason whatsoever!
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.
For example.
The other thing that bothers me is not really logkit per se, but the way we have the log system setup: log messages *SHOULD NOT* be copied to different channels by default, it's incredibly noisy.
What I end up doing is to have everything logged into a single channel and then do something like
tail -f /var/log/cocoon.log | grep this | grep -v but_not_that
where something is what I'm interested in, it's a way more flexible way of doing things.
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.
Bingo. That's my point.
If everyone of us is doing this, then why in hell we don't ship it that way already?
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?
don't know where, but it happens, try removing all the blocks and look at the logkit conf file.
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 ;-)
Yeah and unfortunately it shows.
-- Stefano.
