Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
From: Sylvain Wallez <sylvain@apache.org>
Subject: Re: [CVS] - Flow broken?
Date: Mon, 19 Jan 2004 11:25:29 +0100
Lines: 50
Message-ID: <bugbap$eha$1@sea.gmane.org>
References: <84F0A43A4248CE45B5C0E20F4C40779C667D40@naomi.webworks.nl>
 <400ACE4B.9010805@verizon.net> <buf1rc$e8t$1@sea.gmane.org>
 <400B23EF.5080508@verizon.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.5) Gecko/20031007
In-Reply-To: <400B23EF.5080508@verizon.net>
Sender: news <news@sea.gmane.org>

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

-- 
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