users@javaserverfaces.java.net

Re: ViewExpiredException on postback

From: Ryan Dewell <ryan_at_dewell.org>
Date: Fri, 23 Sep 2005 13:32:24 -0700

Hmm, that's not encouraging. I wish I knew I why it can't restore
the view. :)

I'm using client state saving. On a whim I tried server state
saving, and the same error occurs:

----
45982 [http-8080-Processor4] DEBUG <CLIP>.hosted.HostViewHandler  -  
restoreView: /nextup/view, /view.xml
Sep 23, 2005 1:23:59 PM com.sun.faces.lifecycle.LifecycleImpl phase
WARNING: executePhase(RESTORE_VIEW  
1,com.sun.faces.context.FacesContextImpl_at_b42535) threw exception
javax.faces.application.ViewExpiredException: viewId:/nextup/view -  
View /nextup/view could not be restored.
         at com.sun.faces.lifecycle.RestoreViewPhase.execute 
(RestoreViewPhase.java:148)
etc...
----
The first line comes from my code.  /nextup/view is the view id  
coming into restoreView, and "/view.xml" is what I'm passing up to  
super.restoreView.  "/view.xml" is also the same thing that was  
originally passed to supert.createView.
The lifecycle from my ViewHandler is something like so:
1) Request: /nextup/product/neospeech
2) createView = super.createView(ctx, "/view.xml);
3) getActionUrl = return "/nextup/view"
4) VIEW is displayed perfectly on the client.
5) Postback the view via a command link.
6) restoreView =  super.restoreView(ctx, "/view.xml")
#6 is where the problem occurs.  So one oddity I guess is that the  
GET URL is different than the POST URL...
Any ideas?  I'm willing to try anything.  Does my actionUrl need to  
end with ".xml" or something?  I wouldn't think the actionUrl really  
matters since I override restoreView accordingly.
Thanks,
Ryan
On Sep 23, 2005, at 1:14 PM, <jacob_at_hookom.net> <jacob_at_hookom.net>  
wrote:
>
> Basically that exception occurs when the ResponseStateManager  
> recognizes
> the request as a postback (FacesRequest) and tries to recover the
> VIEW_STATE, but can't.
>
> Are you using state-saving server or client?
>
> -- Jacob
>
> Ryan Dewell <ryan_at_dewell.org> wrote on 09/23/2005, 09:57:35 PM:
>
>> Hello, I'm using JSF 1.2 via the latest build of Facelets.
>>
>> I'm using a very light ViewHandler implementation over the top of the
>> Facelets view handler implementation (double decorator, I guess).
>> The purpose of my ViewHandler is to provide some simple / extra
>> mapping functionality not solvable by prefix or extension mapping.
>>
>> Everything works fine on the GET.  I override createView to call
>> super.createView with the path of the "real" file.  I override
>> getActionUrl to point to my custom path.
>>
>> The ViewExpiredException comes up in the postback.  restoreView is
>> called on my ViewHandler and I pass the same "real" file path that I
>> originally passed to "createView" back to super.restoreView.
>>
>> FYI: I'm emailing this list instead of Facelets because their impl
>> simply calls super.restoreView as well.
>>
>> So, I'm hoping that someone with more knowledge than I can tell me
>> what causes a ViewExpiredException?  I can see that it has something
>> to do with the StateManager, but from there I get lost in the source
>> code.  I don't feel like I can solve the problem or come up with a
>> workaround until I get a better understanding of the conditions that
>> lead up to ViewExpiredException in the first place...
>>
>> In short, I'm ultimately passing the exact same "path" to both
>> createView and restoreView, so I can't understand why createView
>> works fine, and restoreView fails on the postback.
>>
>> Any help is appreciated!
>>
>> Best regards,
>>
>> Ryan
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users- 
>> unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail: users- 
>> help_at_javaserverfaces.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: users- 
> help_at_javaserverfaces.dev.java.net
>
>
>
>