[jira] [Updated] (WICKET-6386) Simplification of the code in WICKET-3347 is not consistent with previous behavior

["David Rain (JIRA)" <ji...@apache.org>]

     [ 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)