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

Florian Braun commented on WICKET-5539:
---------------------------------------

Hi Martin,

Thanks for taking a look at this and sorry for joining the conversation late, I 
was on vacation for a few days.

With the proposed solution for Wicket 6 developers need to know that mountPage 
should not be used (if PageParameters need to be preserved on page recovery). 
We are maintaining a BaseWebApplication that is used by many separate Wicket 
applications and I’m concerned developers will miss this and continue using 
mountPage. And we can’t override mountPage in our BaseApplication since it is 
final.
Would it be possible to remove final from mountPage so we can provide the 
overridden MountedMapper to all consumers? 
Or can you think of a another way this can be handled more globally (instead of 
having to address it with every page mount)?

> 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