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

["Sven Meier (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sven Meier reassigned WICKET-6386:
----------------------------------

    Assignee: Sven Meier

This is one of the scariest code parts of Wicket, so kudos for tracing this down.

I'm clearly in favor of following the single most important rule I know about WebPageRenderer: create the page as late as possible.

I'll investigate further and would propose to revert to the previous handling, i.e. call isPageStateless() lazily as you have suggested,

> 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
>            Assignee: Sven Meier
>              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)