cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] [Cocoon 2.2] Stacktraces in context
Date Thu, 19 Jun 2003 08:27:42 GMT
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



Mime
View raw message