users@javaserverfaces.java.net

Re: ViewExpiredException on postback

From: Ryan Dewell <ryan_at_dewell.org>
Date: Fri, 23 Sep 2005 14:07:48 -0700

I'm just leaving the UIViewRoot creation and setting of the viewId to
the superclass.

When I debug renderView, I can see that the initial request has the
viewId set to "/view.xml" which is the "real file" I pass during
super.createView. Is that not the correct viewId? If not, where/when
would I set it, and what viewId should I use?



On Sep 23, 2005, at 1:48 PM, <jacob_at_hookom.net> <jacob_at_hookom.net>
wrote:

>
> And you are making sure that you are setting that ViewId on the
> UIViewRoot instance?
>
> Ryan Dewell <ryan_at_dewell.org> wrote on 09/23/2005, 10:32:24 PM:
>
>> 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 .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,
>> 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 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
>>>
>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
>