Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <41FBC900.2090008@apache.org>
Date: Sat, 29 Jan 2005 18:33:52 +0100
From: Sylvain Wallez <sylvain@apache.org>
Organization: Anyware Technologies
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Sitemap problem... help! :-)
References: <A737D9F4-7004-11D9-B003-000A95D6B56C@comcast.net>
 <373F094E-7218-11D9-A6CF-000A95D6B56C@comcast.net>
In-Reply-To: <373F094E-7218-11D9-A6CF-000A95D6B56C@comcast.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Mark Lundquist wrote:

>
> I posted the following a couple of days ago on the users list.  I've 
> discovered a wee bit more information (see below).  Anyway, the 
> problem (I'm using Cocoon 2.1.6):
>
> On Jan 26, 2005, at 5:42 PM, Mark Lundquist wrote:
>
>> Hi, I'm having trouble figuring out this problem...
>>
>> I have a flowscript that displays a form using form.showForm(), does 
>> its thing, and calls cocoon.sendForm().
>>
>>  The Problem:
>>
>> If I submit an invalid form, the request invoked by sendForm() gives 
>> me "No pipeline matched request."!  This is the same request that was 
>> processed the first time through to display the form, but for some 
>> reason it misses in the sitemap the second time when the form is 
>> being redisplayed!
>>
>> If I submit a valid form, then I get the same "No pipeline matched 
>> request" for the final sendPage() of the flowscript.  So, it's like 
>> internal redirects after the continuation is resumed are broken, or 
>> something.
>>
>> The flowscript is being called from a subsitemap, if that matters.
>>
>> I set sitemap logging to DEBUG, but that didn't turn up any clues.  
>> Obviously it's something I'm doing, because forms+flow in a 
>> subsitemap work just fine in the samples...  BTW this application 
>> worked w/ Cocoon 2.1.5... but I might have made a few other changes 
>> since porting it to 2.1.6, before I became aware of this problem.
>>
>> Any ideas where I might look to try and debug this?
>> Thanks a lot!
>> �ml�
>
>
> This morning I modified o.a.c.matching.AbstractPreparableMatcher to 
> log failed matches, and I can see that it's trying to match the 
> request in the _root_ sitemap, not in the subsitemap.  BTW, right 
> before sitemap processing I see this:
>
>     DEBUG   (2005-01-29) 08:41.31:245   [sitemap] 
> (/newsletters/7e403a2a6b8f557450733b7d1c6d2f417b241c1f.continue) 
> PoolThread-4/EnvironmentWrapper: Setting uri (prefix=null, 
> uris=subscription-no-id-form.old.standard)
>
> Since the prefix is null, we should process in the current context, 
> right?  And you can see that the URI doesn't start w/ "/" (remember, 
> we're down in the showForm() validation loop, and this is the same URI 
> that matched successfully the first time the form was displayed in the 
> same flow...
>
> Any ideas?


Weird... What is the URL you use in form.showForm()? Does it start with 
a "/"?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }