Bart Guijt wrote:

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




Reply via email to