Jacob, thanks for spending the time you have thus far looking at this
problem. Is there a solution in sight here as far as you know? I
thought that was one of the main reasons for subclassing ViewHandler
-- to provide different URL mapping strategies. Part of the problem
is that the ViewExpiredException is terribly non-specific, offering
little in the way to suggest how I might "fix" my strategy here. All
I want it to do is process the restoreView for the same view ID that
was successfully createView'd and displayed only moments ago! :) It
seems so simple. Surely "expired" is misnomer as not much time has
passed at all.
If all else fails, do you have any other suggestions on how to
provide my own URL->view mapping strategy that will avoid this
ViewExpiredException? In my case the postfix/prefix functionality
provided by JSF just isn't powerful enough.
Ryan
On Sep 23, 2005, at 3:00 PM, Ryan Dewell wrote:
> At step #4 I have a properly displayed view on the client. The
> form action rendered in this view is:
>
> action="/nextup/view"
>
> because that is what I intentionally returned in step #3.
>
> At step #6, after I have pressed a commandButton within the form of
> the rendered view, I receive an HTTP error 500 with a root cause of:
>
> javax.faces.FacesException
> com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:
> 279)
> com.sun.faces.lifecycle.LifecycleImpl.execute
> (LifecycleImpl.java:109)
> javax.faces.webapp.FacesServlet.service(FacesServlet.java:181)
>
> The stack trace in the error logs reveals the more detailed cause
> ViewExpiredException that I outlined in a previous message below.
>
> Is that what you were looking for? Both step #2 and #6 pass up to
> "super" the same real file path "/view.xml" no matter what the
> request URL is.
>
> On a side note, view.xml is acting as a kind of "templating
> controller"... The templates it includes are determined elsewhere
> in a managed bean. Thus the reason that every request gets handled
> by the same "real file".
>
>
>
>
> On Sep 23, 2005, at 2:31 PM, Jacob Hookom wrote:
>
>> 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
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-
>> unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail: users-
>> help_at_javaserverfaces.dev.java.net
>>
>>
>>
>>
>