You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Martin Grigorov (Commented) (JIRA)" <ji...@apache.org> on 2011/11/16 08:30:51 UTC

[jira] [Commented] (WICKET-4229) Expired Ajax Link Referencing Invalid PageID and Valid RenderCount Will Result In a ComponentNotFound Exception When The CallBack References A Component Built During A Page's onRender() Method - like GridView Components

    [ https://issues.apache.org/jira/browse/WICKET-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13151071#comment-13151071 ] 

Martin Grigorov commented on WICKET-4229:
-----------------------------------------

Can you attach a quickstart app ?
This will save us some time.
Thanks !
                
> Expired Ajax Link Referencing Invalid PageID and Valid RenderCount Will Result In a ComponentNotFound Exception When The CallBack References A Component Built During A Page's onRender() Method - like GridView Components
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-4229
>                 URL: https://issues.apache.org/jira/browse/WICKET-4229
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.5.3
>         Environment: Wicket 1.5.3
>            Reporter: gotama
>
> While Wicket 1.5.3 addresses a situation where an ajax callback references a not yet existing component because the Session may have expired and the PageID referenced in the ajax callback link is invalid and returns a null page - and in turn, creates a new page via reflection - this will only work for accessing components which are created in the constructor of that newly created page, not the components created during the page's onRender() method, such as when GridView components are built by the page, this will result in a ComponentNotFound Exception.
> (example Wicket Ajax CallBack)
> ?11-3.IBehaviorListener.0-MyPanelNum1-MyPanelWithinAPanel-rows-19-cols-20-MyGridViewItemPanel-myContainerPanelCreatedDuringOnRender
> In the above Wicket rendered ajax link, the "11" refers to the PageID. The "3" is the RenderCount. The "rows" number and the "cols" number refers to components built by a GridView. GridView components are created during onRender(), not during the constructor. As such, if the Page is instantiated via reflection, the constructor is executed, not the onRender(), and therefore stepping through the Wicket 1.5.3 source code shows that in the above ComponentPath of "MyPanelNum1-MyPanelWithinAPanel-rows-19-cols-20-MyGridViewItemPanel-myContainerPanelCreatedDuringOnRender", this ComponentPath becomes invalid at "MyPanelNum1-MyPanelWithinAPanel-rows" (it has no child componets including "19") - this shows that while in fact the Wicket 1.5.3 fix to patch the situation where the PageID of "11" is invalid, and the isPageInstanceFresh() is true (the page was just created - as a new page is created if the PageID is a page store cache hit miss) and a new RenderPageRequestHandler is scheduled and the request recovers, the subsequent situation where this fix created that page, yet did not render it and its components, later becomes a cache hit and fails to find the components which are suppose to be created during onRender() and in turn missing during getComponent().
> Further complicating this scenario is that if in fact the referenced RenderCount ("3" in this example) in the ajax callback is in fact invalid, this situation is not reproducible because a stale page exception is thrown instead. However, in the edge case where the ajax callback is invalid due to the Session invalidating (a valid PageID may then now be 1 perhaps, not 11) and the RenderCount in the callback matches the stored page's RenderCount (just a matter of time for the RenderCounts to match), this will result in the ComponentNotFound exception - essentially a ticking RuntimeException to blow up the page, while tough to reproduce, is in fact valid and will occur. 
> As a method of attempting to reproduce this issue, one can hi-jack the creation of this Wicket CallBack URL and induce this situation as follows:
> //        int randomPageID = (int) (10 * Math.random());
>         int randomPageID = 5;
>         String myCallBackURL = myComponent.getCallbackUrl().toString();
>         myCallBackURL = "?" + randomPageID + "-0" + myCallBackURL.substring(myCallBackURL.indexOf("."));

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira