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?
Yeah, error reporting isn't perfect in Cocoon :-/
For the treeprocessor, we have to distinguish the two phases of request handling :
- pipeline building (matchers, selectors, actions) : this is under control of the treeprocessor, which could log the location of the error in the sitemap.
- pipeline execution (generator, transformer, serializer) : this is more difficult because of the streamed nature of the processing.
Something which could help for both phases is to add the sitemap statement location in the parameters. This would allow any component to know the location of its invocation and reports it in its exception.
Exceptions raised in the second phase out of control of sitemap components (e.g. in an XSLT processor) are much more difficult to handle. We could have a special implementation of the pipeline that shields each element of the pipeline by exception handlers that log the error with its location (I whish we still had SAXConnectors...).
For the Cocoon 2.2 version of course!!
As this isn't disruptive, this can go in any version... once it's done !
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
