Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: 30 Apr 2003 20:56:33 -0000
Message-ID: <20030430205633.10767.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: cocoon-dev@xml.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 13186]  -
    after java exception in XSP, Cocoon continues with pipeline

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13186>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13186

after java exception in XSP, Cocoon continues with pipeline


------- Additional Comments From bruno@outerthought.org  2003-04-30 20:56 -------
This "bug" also occurs in the current Cocoon 2.1 (april 30, 2003).

The cause is that during the recycling of the TraxTransformer, an endDocument()
call will be forced upon the TransformerHandler, if an endDocument had not yet
occured earlier. This will then cause xalan to finish its transformation
process, pushing events in the rest of the pipeline, finally causing the
serializer to write it to the outputstream, appending it to the error message.

The reason this was introduced was because if xalan is used in incremental mode,
it would otherwise let its thread wait forever.

I first thought of fixing it by setting the result of the TransformerHandler to
a dummy result:
transformerHandler.setResult(new SAXResult(new DefaultHandler()));
before calling endDocument() (in the recycle() method)

This works when Xalan is not working in incremental mode, but unfortunately it
does not work in incremental mode.

Without changing things in Xalan (which will be rather impossible on first
sight), one possible way of solving this would be to set the outputstream of the
serializer to a dummy outputstream at the beginning of
AbstractProcessingPipeline.recycle(). This way, if there is any pipeline
component which would still try to emit SAX events during recycle, they would
not have any impact on the output.

A possible problem with this solution is that not all serializers might expect
that their outputstream is changed in the middle of pipeline execution. Another
solution would be to add some method to the Environment so that the outputstream
could be blocked (we already have our own wrapper around the outputstream, so
that should be possible).

Thoughts?