On Nov 19, 2009, at 2:24 PM, Igor Vaynberg wrote:

> On Thu, Nov 19, 2009 at 2:15 PM, Hawk Newton <hnew...@cobaltgroup.com> wrote:
>> 2. Extend WebRequestCycle.onRuntimeException() to redirect the browser back 
>> to the target page instead of the "expired session" error page.  This 
>> approach has the drawback that the model will be reset which will cause the 
>> page to revert to default values.  Ultimately, initializing the page using 
>> values from a cookie or some other stateful store that is not tied to the 
>> user's session would be ideal, if possible.
> 
> unless you encode the page class into every url there is no way to
> know what page was being accessed once the session is expired.

I got this working today provided each page is mounted as bookmarkable.  I 
might be missing some of the long-reaching implications, but here's the code if 
anyone is interested in it:
        // In my WicketApplication class:
        public RequestCycle newRequestCycle(Request request, Response response) 
{
                return new WebRequestCycle(this, (WebRequest)request, 
(WebResponse)response) {
                        @Override
                        public Page onRuntimeException(Page page, 
RuntimeException e) {
                                if(e instanceof PageExpiredException) {
                                        IRequestCycleProcessor processor = 
WicketApplication.this.getRequestCycleProcessor();
                                        RequestParameters params = 
request.getRequestParameters();
                                        
                                        // We're just looking for the original 
page, not a component on that page.
                                        String interfaceName = 
params.getInterfaceName();
                                        
                                        // Strip the interfaceName from the 
request so we can get the original target
                                        params.setInterfaceName(null);
                                        IRequestTarget target = 
processor.resolve(this, params);
                                        params.setInterfaceName(interfaceName);
                                        
                                        if(target != null && target instanceof 
BookmarkablePageRequestTarget) {
                                                Class<? extends Page> pageClass 
= ((BookmarkablePageRequestTarget)target).getPageClass();
                                                
                                                RequestCycle.get();     // I'm 
not 100% on why I need this.
                                                CharSequence path = 
processor.getRequestCodingStrategy().pathForTarget(
                                                                new 
BookmarkablePageRequestTarget(pageClass));
                                                
                                                if(path != null) {
                                                        // This is a 
bookmarkable page, so lets send the user to the bookmark
                                                        
RequestCycle.get().setRedirect(true);
                                                        throw new 
RestartResponseException(pageClass);
                                                }
                                        }
                                }
                                return null;
                        }
                };
        }


> 
>> 3. Use an external store instead of the J2EE session (like a RDBMS) with a 
>> data-retention policy so high the chance of a ajax request being issued 
>> against a page which has expired is practically nil.  We'd also probably 
>> need to implement our own encoder to ensure the session id is placed on 
>> every link to survive J2EE session invalidation.
> 
> or simply set the j2ee session timeout to a high value. servlet
> containers these days can swap inactive sessions to disk to keep the
> memory overhead low. same effect and no need to deal with a database.
> 
> -igor

Thank you, with a high enough session timeout and a disk-backed session 
overflow we should be good.

-- Hawk

Reply via email to