Hi all,
I am using Cocoon for almost a year now and if one thing bugs me, it is
this: if something fails to operate successfully, the Java stacktraces fail
most of the time to correctly show how the error occurred.
In Cocoon, we use sitemaps, XSL transformers, (additional) Java components
and URI resolving to get the job done. If something fails, we get a
(possibly very deep!) stacktrace from the SAX pipeline, a compiled XSLT
stylesheet, the appserver and the treeprocessor in no particular order, with
sometimes very misleading information.
What about a stacktrace like this:
Error <foo bar> occurred at:
Java: org.apache.cocoon.components.SomeComponent.Configure:237:4
Sitemap: /test/sitemap.xmap:25 (map:generate src="..."
type="SomeComponent")
Sitemap: /test/sitemap.xmap:24 (map:match pattern="someresource")
Sitemap: /sitemap.xmap:20 (map:mount check-reload="yes" src="{1}/"
uri-prefix="{1}" - {1}="test")
Sitemap: /sitemap.xmap:19 (map:match pattern="*/**")
URI: cocoon://test/someresource
XSLT: /xsl/foo-bar.xslt:454:53 (document())
XSLT: /xsl/foo-bar.xslt:25:10 (template: /)
Sitemap: /sitemap.xmap:30 (map:transform src="xsl/foo-bar.xslt")
Sitemap: /sitemap.xmap:28 (map:match pattern="page.html")
URI: page.html
The information provided is probably mentioned somewhere in the Cocoon logs,
but is scattered all over the place. The logs are a collection of events in
no particular order (multiple users) and are not traceable to a single
session. Even if you could trace these events leading to failure, it is a
PITA to figure out what the execution stacktrace actually was!
I don't know much about any Cocoon treeprocessor internals (Sylvain?), but
is such a thing possible? It would probably be a little difficult with the
XSLT part, but even then: Xalan fires trace events which are perfectly
suitable for this job.
So... how about it?
For the Cocoon 2.2 version of course!!
Cheers,
Bart Guijt
