on 6/18/03 4:39 PM 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.
Yeah, damn, don't tell me, this have been bugging me from Cocoon 1.0! ;-)
> 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.
Yes, this is very true.
> 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
oh, god, I would *LOVE* to see that implemented. A *real* Cocoon
stacktrace instead of a useless java one.
whomever come out with something like this becomes my personal hero!
> 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, how about it? does anybody have a clue on how we could implement
something like the above?
Anyway, dude, great RT, I love the concept, those mile-long stacktraces
aren't really giving us any useful information to trace where the real
problem is.
--
Stefano.
