[ 
https://issues.apache.org/jira/browse/WICKET-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090747#comment-14090747
 ] 

Guillaume Smet commented on WICKET-5539:
----------------------------------------

Martin,

As for now, I was trying to find a mostly working solution for 6.

As for future development, I think that what you propose would work. And I 
think it could also fix elegantly the problem worked around by the 
PageParameterAwareMountedMapper of Johannes (namely having a page which doesn't 
respect the parameter because another page with the pageId already exists for 
this user): we could check that the "vital" parameters are *exactly* the same 
before considering the page instance is the one you want EVEN if the page id is 
ok.

I'm wondering if it shouldn't be the responsability of the developer to define 
the "vital" parameters for its pages. The default could be to use the named 
path parameter but it could be nice to be able to override it.

As for PageParameters, I concur we should have a better separation between the 
various types of parameters.

> Incorrect recreation of page in case of PageExpire
> --------------------------------------------------
>
>                 Key: WICKET-5539
>                 URL: https://issues.apache.org/jira/browse/WICKET-5539
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 6.14.0
>            Reporter: Ilia Naryzhny
>            Assignee: Martin Grigorov
>              Labels: expiration, mountBookmarkablePage
>             Fix For: 6.17.0
>
>         Attachments: wicket5539.zip
>
>
> There is a bookmarkable page mounted, for example, to:
> /page/${entityId}
> This page contains StatelessForm.
> Submitting of form after session expire lead to following:
> org.apache.wicket.core.request.mapper.MountedMapper invokes 
> AbstractBookmarkableMapper.processListener to obtain IRequestHandler to 
> handle submitting of form. 
> But there is cleaning of PageParameters within processListener on line 256 
> (Wicket 6.14) which cleaning "entityId" parameter as well and created page 
> finally has no "enityId" and (in our case) redirects to 404.
> I see that this cleaning of page parameters was implemented due to 
> Wicket-4594. But I think, just checking for pageId is unsufficient, because 
> pageId might be not null, but actual page may be already expired and new 
> instance should be created.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to