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

Sven Meier updated WICKET-6386:
-------------------------------
    Affects Version/s: 8.0.0-M6

> 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, 8.0.0-M6
>         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)

Reply via email to