[
https://issues.apache.org/jira/browse/WICKET-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094411#comment-13094411
]
Martin Grigorov commented on WICKET-4002:
-----------------------------------------
We can catch this only in org.apache.wicket.Component.setResponsePage(Class<C>,
PageParameters) because there we know the current component (and eventually its
page). But if the user application directly uses
org.apache.wicket.request.cycle.RequestCycle.setResponsePage(Class<? extends
IRequestablePage>, PageParameters) then extracting the current page is a bit
problematic.
Using IRequestCycleListener looks better to that the logic in 1.4 because it is
non-obtrusive. We can move it from -devutils to -core and register it always in
DEV mode.
> setResponsePage to itself causes infinite loop & stackoverflow
> --------------------------------------------------------------
>
> Key: WICKET-4002
> URL: https://issues.apache.org/jira/browse/WICKET-4002
> Project: Wicket
> Issue Type: Improvement
> Reporter: selckin
> Priority: Minor
> Attachments: WICKET-4002.patch, setrepsonse-infite-loop.tar.gz
>
>
> If you have a setResponsePage in onInitialize to the same page that calls
> setRepsonse again, it will go into a loop to re-render the page till it
> stackoverflows.
> It is off-course very silly to be calling setResponsePage this way, but due
> to making changes & little bugs it could happen, and if your page is fairly
> complex and takes a while to render, it can take multiple min till it
> rendered enough pages to stackoverflow.
> It would be nice to maybe have a limit on the amount of times you are allowed
> to call setRepsonsePage in the same render cycle, or something similar to
> mitigate this and error out faster.
> Thanks
> http://paste.pocoo.org/show/i9XcjFHWcI6YR2x4z6G2/
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
