[
https://issues.apache.org/jira/browse/WICKET-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Rain updated WICKET-6386:
-------------------------------
Description:
After upgrading from 6.24.0 to 7.6.0 and to 7.7.0 (affects both) I noticed that
the newly introduced method
org.apache.wicket.request.handler.render.WebPageRenderer#shouldRenderPageAndWriteResponse
doesn't return the same boolen value as the expression before.
The cause is the part *notNewAndNotStatelessPage(isNewPageInstance(),
isPageStateless())* - both function arguments get evaluated and the call to
isPageStateless() calls getPage().
This wasn't the case with *getPageProvider().isNewPageInstance() &&
!getPage()..isPageStateless()* because the first condition could be false and
terminate the evaluation.
I think this "new" behavior wasn't intended because *getPage()* is explicitly
called on line 231 (after conditions are evaluated) to force the page creation.
My problem is that even normally I would end with *shouldRedirectToTargetUrl*
beeing true and redirectTo would be called, the *getPage()* call in the first
condition causes another redirect is called (in my page constructor in some
conditions) and I end with end-less loop and stack overflow.
I have an workaround with my custom WebPageRenderer and its provider, but I
still think this is a bug.
Question is if reverting this back would not cause problem with others' people
project because they can expect this "new" behavior.
was:
After upgrading from 6.24.0 to 7.6.0 and to 7.7.0 (affects both) I noticed that
the newly introduced method
org.apache.wicket.request.handler.render.WebPageRenderer#shouldRenderPageAndWriteResponse
doesn't return the same boolen value as the expression before.
The cause is the part *notNewAndNotStatelessPage(isNewPageInstance(),
isPageStateless())* - both function arguments get evaluated and the call to
isPageStateless() calls getPage().
This wasn't the case with targetUrl.equals(currentUrl) &&
getPageProvider().isNewPageInstance() && !getPage().
.isPageStateless() because any of the elements could be false and terminate the
evaluation.
I think this "new" behavior wasn't intended because getPage() is explicitly
called on line 231 (after conditions are evaluated) to force the creation.
My problem is that even normally I would end with shouldRedirectToTargetUrl
beeing true and redirectTo would be called, the getPage() call in the first
condition causes another redirect is called (in my page constructor in some
conditions) and I end with end-less loop and stack overflow.
I have an workaround with my custom WebPageRenderer and its provider, but I
still think this is a bug.
Question is if reverting this back would not cause problem with others' people
project because they can count with this behavior.
> Simplification of the code in WICKET-3347 is not consistent with previous
> behavior
> ----------------------------------------------------------------------------------
>
> Key: WICKET-6386
> URL: https://issues.apache.org/jira/browse/WICKET-6386
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 7.7.0
> Environment: Windows 8.1 64-bit, Oracle JDK 1.8.0_121, Jetty 9
> Reporter: David Rain
> Labels: easyfix
>
> After upgrading from 6.24.0 to 7.6.0 and to 7.7.0 (affects both) I noticed
> that the newly introduced method
> org.apache.wicket.request.handler.render.WebPageRenderer#shouldRenderPageAndWriteResponse
> doesn't return the same boolen value as the expression before.
> The cause is the part *notNewAndNotStatelessPage(isNewPageInstance(),
> isPageStateless())* - both function arguments get evaluated and the call to
> isPageStateless() calls getPage().
> This wasn't the case with *getPageProvider().isNewPageInstance() &&
> !getPage()..isPageStateless()* because the first condition could be false and
> terminate the evaluation.
> I think this "new" behavior wasn't intended because *getPage()* is explicitly
> called on line 231 (after conditions are evaluated) to force the page
> creation.
> My problem is that even normally I would end with *shouldRedirectToTargetUrl*
> beeing true and redirectTo would be called, the *getPage()* call in the first
> condition causes another redirect is called (in my page constructor in some
> conditions) and I end with end-less loop and stack overflow.
> I have an workaround with my custom WebPageRenderer and its provider, but I
> still think this is a bug.
> Question is if reverting this back would not cause problem with others'
> people project because they can expect this "new" behavior.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
