Sylvain Wallez wrote:
Christopher Oliver wrote:
If you don't mind, can you explain how it fixes the problems reported by Unico and Antonio? What was happening before your fix and what will happen now when you have
Sorry, I'm quite busy and didn't took the time for the minimal explanations.
The important difference between internal and external requests is that:
- for external requests, Processor.process() is called, and the result is output to the environment's OutputStream as soon as we reach a <map:serialize> or <map:read>
- for internal requests (i.e. SitemapSource) Processor.buildPipeline() is called, and the Processor does nothing more than assemble the pipeline.
When a foward occurs (i.e. redirect to "cocoon:") within an internal request, we must build a pipeline for the new URI, and have the resulting pipeline be the result of the original call to Processor.buildPipeline().
To solve this problem, the redirector was setting a flag indicating a forward which was later checked at the end of the tree evaluation in TreeProcessor.process(). The bad side effect of this was that the new request was not processed as part of the call to redirector.redirect().
The change I made yesterday corrects this: the redirector now uses the same InvokeContext than the original call to Processor.processInternal, and this allows to return the correct Pipeline instance, since it is created and held by the invoke context.
The "attempt to process and incomplete pipeline" message occurs when a different pipeline instance is created when the forward is processed, which is what occurs if Interpreter.forwardTo() is implemented similarily to processTo().
Hope it was clear :-/
In short: never manually call Processor.process() to process a request if you want it to function properly when the request is internal. Use Redirector.redirect().
Sylvain
