You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Mark Lundquist <ml...@comcast.net> on 2005/01/29 18:07:11 UTC
Sitemap problem... help! :-)
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?
thanks,
Mark
Re: Sitemap problem... help! :-)
Posted by Mark Lundquist <ml...@comcast.net>.
On Jan 29, 2005, at 9:07 AM, Mark Lundquist wrote:
> <...snip> This morning I modified
> o.a.c.matching.AbstractPreparableMatcher to log failed matches
actually it is
o.a.c.components.treeprocessor.sitemap.PreparableMatchNode that I
instrumented.
— mark
Re: Sitemap problem... help! :-)
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Jan 30, 2005, at 3:07 AM, Leszek Gawron wrote:
>>>
> You should have errors in your log files when getting this kind of
> InvalidContinuationException:
>
>> if (!kont.interpreterMatches(interpreterId)) {
>> getLogger().error(
>> "WK: Continuation (" + kont.getId()
>> + ") lookup for wrong interpreter. Bound
>> to: "
>> + kont.getInterpreterId() + ", looked up
>> for: "
>> + interpreterId);
>> return null;
>> }
>
Yep... too bad I'm using 2.1.6 :-)
>
> What you request is not a trivial change. Currently it is the
> interpreter that is resolved first (based on current sitemap context).
> Then it is interpreter's responsibility to lookup and resume a proper
> continuation. I do not know if it is possible to invert the behaviour:
> - first the continuations gets looked up
> - the sitemap context is changed based on the interpreter info stored
> in continuation (the id is not enough as it is a resource path that
> would have to get parsed every time)
> - the flow interpreter bound to sitemap is being invoked with ready to
> go WebContinuation.
That's just what I had in mind! :-)
—mark
Re: Sitemap problem... help! :-)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 30.01.2005 21:32, Mark Lundquist wrote:
> It can be argued that it should be possible to match any continuation
> resource in any context and have it resumed correctly. The rationale is
> the intuition that the sitemap context is part of the control thread
> being resumed.
I agree. Isn't it possible to handle a wrong interpreter like a not
matching matcher and resume searching for another handler of the
continuation? We also don't throw an exception when the first matcher
does not match ...
Joerg
Re: Sitemap problem... help! :-)
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Jan 30, 2005, at 5:21 AM, Sylvain Wallez wrote:
> I don't think we should go that far: IMO, having an exception with a
> clear reason message is enough, as it shows that there is a bug in the
> application that needs to be fixed. Mark had no such exception, and
> that's why he spent much time to find the problem.
Good summary. Thanks to both of you.
It can be argued that it should be possible to match any continuation
resource in any context and have it resumed correctly. The rationale
is the intuition that the sitemap context is part of the control thread
being resumed. IOW, in 2.1.7 I get an exception telling me I need to
fix my "bug", and this a good thing. Arguably, what I did should not
be a "bug" in the first place, but that's a separate issue.
Best Regards,
— mark
Re: Sitemap problem... help! :-)
Posted by Sylvain Wallez <sy...@apache.org>.
Leszek Gawron wrote:
> Sylvain Wallez wrote:
>
>> Mark Lundquist wrote:
>>
>>>
>>> OK, I figured out the problem (qv.
>>> http://marc.theaimsgroup.com/?t=110701945100004&r=1&w=2).
>>>
>>> I had one matcher in the root sitemap that handled all continuation
>>> URIs, even those that are generated from pipelines in subsitemaps.
>>>
>>> So apparently, the context for the redirector invoked from the
>>> flowscript after the continuation is resumed is the context that
>>> matched the continuation resource, *not* the context that originally
>>> invoked the flow.
>>
> You should have errors in your log files when getting this kind of
> InvalidContinuationException:
>
>> if (!kont.interpreterMatches(interpreterId)) {
>> getLogger().error(
>> "WK: Continuation (" + kont.getId()
>> + ") lookup for wrong interpreter. Bound
>> to: "
>> + kont.getInterpreterId() + ", looked up
>> for: "
>> + interpreterId);
>> return null;
>> }
>
>
>
>>>
>>> You guys who know this stuff inside and out are probably saying,
>>> "well, of course!" :-)... but am I weird to find this
>>> counterintuitive? WDYT?
>>
> I' have to put an appropriate comment in the docs about that.
>
>>
>>
>>
>> Leszek could tell more about this, but there has been some recent
>> modifications to forbid this: a continuation can only be called
>> within the sitemap where it was created.
>
>
> It is YOU that have to assure that the continuations gets resumed in
> the same context. As you see in the code pasted above current
> implementation of ContinuationsManager requests the flow interpreter
> to identify itself. Interpreter ID is being compared to the one stored
> in continuation - if it doesn't match you won't be able to resume it.
>
> What you request is not a trivial change. Currently it is the
> interpreter that is resolved first (based on current sitemap context).
> Then it is interpreter's responsibility to lookup and resume a proper
> continuation. I do not know if it is possible to invert the behaviour:
> - first the continuations gets looked up
> - the sitemap context is changed based on the interpreter info stored
> in continuation (the id is not enough as it is a resource path that
> would have to get parsed every time)
> - the flow interpreter bound to sitemap is being invoked with ready to
> go WebContinuation.
I don't think we should go that far: IMO, having an exception with a
clear reason message is enough, as it shows that there is a bug in the
application that needs to be fixed. Mark had no such exception, and
that's why he spent much time to find the problem.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Sitemap problem... help! :-)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Sylvain Wallez wrote:
> Mark Lundquist wrote:
>
>>
>> OK, I figured out the problem (qv.
>> http://marc.theaimsgroup.com/?t=110701945100004&r=1&w=2).
>>
>> I had one matcher in the root sitemap that handled all continuation
>> URIs, even those that are generated from pipelines in subsitemaps.
>>
>> So apparently, the context for the redirector invoked from the
>> flowscript after the continuation is resumed is the context that
>> matched the continuation resource, *not* the context that originally
>> invoked the flow.
You should have errors in your log files when getting this kind of
InvalidContinuationException:
> if (!kont.interpreterMatches(interpreterId)) {
> getLogger().error(
> "WK: Continuation (" + kont.getId()
> + ") lookup for wrong interpreter. Bound to: "
> + kont.getInterpreterId() + ", looked up for: "
> + interpreterId);
> return null;
> }
>>
>> You guys who know this stuff inside and out are probably saying,
>> "well, of course!" :-)... but am I weird to find this
>> counterintuitive? WDYT?
I' have to put an appropriate comment in the docs about that.
>
>
>
> Leszek could tell more about this, but there has been some recent
> modifications to forbid this: a continuation can only be called within
> the sitemap where it was created.
It is YOU that have to assure that the continuations gets resumed in the
same context. As you see in the code pasted above current implementation
of ContinuationsManager requests the flow interpreter to identify
itself. Interpreter ID is being compared to the one stored in
continuation - if it doesn't match you won't be able to resume it.
What you request is not a trivial change. Currently it is the
interpreter that is resolved first (based on current sitemap context).
Then it is interpreter's responsibility to lookup and resume a proper
continuation. I do not know if it is possible to invert the behaviour:
- first the continuations gets looked up
- the sitemap context is changed based on the interpreter info stored in
continuation (the id is not enough as it is a resource path that would
have to get parsed every time)
- the flow interpreter bound to sitemap is being invoked with ready to
go WebContinuation.
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Sitemap problem... help! :-)
Posted by Sylvain Wallez <sy...@apache.org>.
Mark Lundquist wrote:
>
> OK, I figured out the problem (qv.
> http://marc.theaimsgroup.com/?t=110701945100004&r=1&w=2).
>
> I had one matcher in the root sitemap that handled all continuation
> URIs, even those that are generated from pipelines in subsitemaps.
>
> So apparently, the context for the redirector invoked from the
> flowscript after the continuation is resumed is the context that
> matched the continuation resource, *not* the context that originally
> invoked the flow.
>
> You guys who know this stuff inside and out are probably saying,
> "well, of course!" :-)... but am I weird to find this
> counterintuitive? WDYT?
Leszek could tell more about this, but there has been some recent
modifications to forbid this: a continuation can only be called within
the sitemap where it was created.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Sitemap problem... help! :-)
Posted by Mark Lundquist <ml...@comcast.net>.
OK, I figured out the problem (qv.
http://marc.theaimsgroup.com/?t=110701945100004&r=1&w=2).
I had one matcher in the root sitemap that handled all continuation
URIs, even those that are generated from pipelines in subsitemaps.
So apparently, the context for the redirector invoked from the
flowscript after the continuation is resumed is the context that
matched the continuation resource, *not* the context that originally
invoked the flow.
You guys who know this stuff inside and out are probably saying, "well,
of course!" :-)... but am I weird to find this counterintuitive? WDYT?
— mark
Re: Sitemap problem... help! :-)
Posted by Sylvain Wallez <sy...@apache.org>.
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 }