shouldnt this change be wider made to stateless pages? i think the
proper solution is making the error page stateless.

-igor

On Wed, Jun 1, 2011 at 1:27 PM, Martin Grigorov <[email protected]> wrote:
> not storing the error page causes troubles with redirect_to_render
> (RenderStrategy) or redirect_always (RedirectPolicy) because the page
> cannot be found after the redirect
>
> I have a local patch that changes the default RedirectPolicy from
> NEVER to AUTO in DefaultExceptionMapper and solves the problem,
> because this way redirect_to_buffer is used. The change looks sensible
> to me. I'll attach it to a ticket for review.
>
> On Wed, Jun 1, 2011 at 7:51 PM, Igor Vaynberg <[email protected]> wrote:
>> when a page is set to versioned=false it means that hierarchy
>> modifications, etc, do not dirty the page. it should not imply
>> anything else other then the dirty flag not being modified.
>>
>> stateless pages should not be stored. perhaps the error page (if it
>> has no callbacks - in which case it should be auto-marked as stateless
>> already) can override the stateless flag.
>>
>> makes sense?
>>
>> -igor
>>
>> On Wed, Jun 1, 2011 at 5:16 AM, Martin Grigorov <[email protected]> wrote:
>>> A proof : https://issues.apache.org/jira/browse/WICKET-3758
>>>
>>> What is the actual meaning of "versioned" ? Should not be stored or
>>> should not stored more than one version of this page ?
>>>
>>> On Wed, Jun 1, 2011 at 10:24 AM, Martin Grigorov <[email protected]> 
>>> wrote:
>>>> Hi,
>>>>
>>>> Yesterday while playing with the app from
>>>> http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp I found
>>>> that org.apache.wicket.page.PageAccessSynchronizer.lockPage(int) is
>>>> called as many times as PageProvider#getPage() is used.
>>>> So I did the following optimization:
>>>>
>>>> Index: 
>>>> wicket-core/src/main/java/org/apache/wicket/request/handler/PageProvider.java
>>>> ===================================================================
>>>> --- 
>>>> wicket-core/src/main/java/org/apache/wicket/request/handler/PageProvider.java
>>>>        (revision
>>>> 1130015)
>>>> +++ 
>>>> wicket-core/src/main/java/org/apache/wicket/request/handler/PageProvider.java
>>>>        (working
>>>> copy)
>>>> @@ -158,12 +158,13 @@
>>>>                if (pageInstance == null)
>>>>                {
>>>>                        pageInstance = getPageInstance(pageId, pageClass, 
>>>> pageParameters,
>>>> renderCount);
>>>> +                       if (pageInstance == null)
>>>> +                       {
>>>> +                               throw new PageExpiredException("Page 
>>>> expired.");
>>>> +                       }
>>>> +                       touchPageInstance(pageInstance);
>>>>                }
>>>> -               if (pageInstance == null)
>>>> -               {
>>>> -                       throw new PageExpiredException("Page expired.");
>>>> -               }
>>>> -               touchPageInstance(pageInstance);
>>>> +
>>>>                return pageInstance;
>>>>        }
>>>>
>>>> I.e. check whether to throw PageExpiredException or touch the page
>>>> only when it was just attempted to read from the page store, all
>>>> following calls to #getPage() work with the cached page (already
>>>> touched).
>>>> Everything is OK but just one test fails :
>>>> org.apache.wicket.ajax.InternalErrorCallsAjaxOnFailureTest.showsInternalErrorPage()
>>>> The problem is that
>>>> org.apache.wicket.markup.html.pages.ExceptionErrorPage.isVersioned()
>>>> returns false and this error page should not be stored.
>>>> org.apache.wicket.Page.dirty(boolean) takes into account isVersioned()
>>>> but 
>>>> org.apache.wicket.request.handler.PageProvider.touchPageInstance(IRequestablePage)
>>>> doesn't and always marks the page as candidate for storing.
>>>>
>>>> If above is a bug I suggest to add IManageblePage#dirty(boolean) and
>>>> use it instead session.getPageManager().touchPage(IRequestablePage).
>>>>
>>>>
>>>> --
>>>> Martin Grigorov
>>>> jWeekend
>>>> Training, Consulting, Development
>>>> http://jWeekend.com
>>>>
>>>
>>>
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>

Reply via email to