[
https://issues.apache.org/jira/browse/WICKET-5008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588652#comment-13588652
]
bernard commented on WICKET-5008:
---------------------------------
Martin,
My apologies for appearing opinionated. No way would I want to have a negative
impact on your work which I much appreciate. Sorry.
Regarding the test case setup and documentation, It may well be that there is a
mix-up somehow with the files that I uploaded or the files that you are getting.
I see in web.xml:
<session-config>
<!-- Expiry minimal for testing purposes-->
<session-timeout>1</session-timeout>
</session-config>
The test case, when running, contains all the required instructions in clear
text in two pages.
When I write about the wrong constructor being called after expiry, in my
perception, please let me try to express this in the most general terms. This
is with the objective in mind of successful page recovery after expiry instead
of failure as in the current implementation, not some opinion on how wicket
should work in general.
1) If the page has page parameters which are encoded in the URL, then this can
be interpreted as client side state, and Wicket knows this - it does not have
to make an assumption which constructor to call. It does not want to throw this
state away by discarding the PageParameters as it currently does.
2) If the page does NOT have page parameters, as can be seen from the URL, then
Wicket should after page expiry call the default constructor. Currently it
calls the PageParameters constructor with empty parameters.
Perhaps I should have written this in the subject line - I am only concerned
with the page expiry situation. I don't want custom behavior. I want that
Wicket just does what it has in the API
getPageSettings().setRecreateMountedPagesAfterExpiry(true);
So we have two failures:
a) in case where the page does not have page parameters in the URL, the
constructor containing PageParameters is called which is not logical from this
perspective
b) in case where the page has page parameters in the URL, the correct
constructor is actually called, but the parameters are missing.
I am suggesting that the solution calls different constructors, with the
available parameter data, depending on a distinction based on checking the
content of the request URL (parameters).
> PageProvider#getPageInstance() calls wrong Page Constructor if pageParameters
> is null
> -------------------------------------------------------------------------------------
>
> Key: WICKET-5008
> URL: https://issues.apache.org/jira/browse/WICKET-5008
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.4.0
> Reporter: bernard
> Attachments: TestCase.zip
>
>
> I was wondering why my pages' default constructors aren't called anymore
> since after 1.4.
> The problem is that PageProvider#getPageInstance() does not distinguish
> between pages that have parameters and pages that don't.
> This creates a messy situation for pages that accept page parameters.
> One case I know of is ListenerInterfaceRequestHandler#respond() which calls
> ListenerInterfaceRequestHandler#getPage().
> If this call hits an expired page then the page crashes in the constructor
> Page(final PageParameters parameters) because of the bogus parameters.
> I would expect that the default constructor is called in this case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
