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
>
>
>
>