There are several issues with getting a meaningful stack trace from the
execution of the pipeline:
1) The pipeline itself is not executed by the TreeProcessor but instead
by a Pipeline processor. The sitemap source locations of the pipeline
elements are not currently available to the ProcessingPipeline..
2) Source location information of the input to each pipeline stage is
normally lost during the transformation steps.
So I would propose something like the following:
1) Have the TreeProcessor pass the sitemap source location in
setGenerator(), addTransformer(), and setSerializer() to the
ProcessingPipeline.
2) In "Debug" mode instrument the PipelineProcessor to write the output
of each stage to a temporary file and regenerate SAX events from the
temporary file (with location information). The PipelineProcessor would
catch any exception thrown by a pipeline component and generate a
"Cocoon" stack trace that includes the source location of the temp file.
The Cocoon error reporter could even display the source code (maybe in
tab-panes or whatever) of the pipeline intermediate results together
with the stack trace. Hypothetically the label or tooltip on the
tab-pane would be something like:
C:\TEMP\Pipeline_1060734815693.xml (output of
C:\cocoon\build\webapp\samples\sitemap.xmap::66:16)
where the sitemap location refers to a <map:generate> or <map:transform>
instruction.
WDYT?
Chris
- Re: Pipleline Execution Stack Trace (was Cocoon Stack T... Christopher Oliver
- Re: Pipleline Execution Stack Trace (was Cocoon St... Vadim Gritsenko
- Re: Pipleline Execution Stack Trace (was Cocoo... Christopher Oliver
