Looking at the steps below:
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")
The postback within the rendered view-- what is it outputting?
Ryan Dewell wrote:
> 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
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: users-help_at_javaserverfaces.dev.java.net
>
>
--
Jacob Hookom - Minneapolis
--------------------------
http://hookom.blogspot.com