Hey Ryan,
I was just checking in some portlet support issues for Facelets and was
going to start looking again at the problem. Another option would be to
put a filter up front on your application?
The heart of it is that you are rendering /view.xml, but at that time of
rendering, the state is saved, probably bound to /view.xml. So I
believe the issues you are seeing are concentrated around the fact that
the UIViewRoot needs to be both /nextup/view and /view.xml at the same
time. Between everything, I don't think there's a proper way to catch it.
Really, the view in the error message that you want restored is
"/view.xml", not "/nextup/view". Because "/view.xml" was the view
rendered and stored, that's the view that should've been stored. Now,
the next step I would take in making sure you have all of your bases
covered is to decorate the statemanager and intercept the view ids being
passed around there.
-- Jacob
Ryan Dewell wrote:
> 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
>>>> <mailto:jacob_at_hookom.net>> <jacob_at_hookom.net
>>>> <mailto: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 <mailto: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
>>>>>>>> <mailto:unsubscribe_at_javaserverfaces.dev.java.net>
>>>>>>>> For additional commands, e-mail: users-
>>>>>>>> help_at_javaserverfaces.dev.java.net
>>>>>>>> <mailto:help_at_javaserverfaces.dev.java.net>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --------------------------------------------------------------------
>>>>>>> -
>>>>>>> To unsubscribe, e-mail: users-
>>>>>>> unsubscribe_at_javaserverfaces.dev.java.net
>>>>>>> <mailto:unsubscribe_at_javaserverfaces.dev.java.net>
>>>>>>> For additional commands, e-mail: users-
>>>>>>> help_at_javaserverfaces.dev.java.net
>>>>>>> <mailto:help_at_javaserverfaces.dev.java.net>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-
>>>>>> unsubscribe_at_javaserverfaces.dev.java.net
>>>>>> <mailto:unsubscribe_at_javaserverfaces.dev.java.net>
>>>>>> For additional commands, e-mail: users-
>>>>>> help_at_javaserverfaces.dev.java.net
>>>>>> <mailto:help_at_javaserverfaces.dev.java.net>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> users-unsubscribe_at_javaserverfaces.dev.java.net
>>>>> <mailto:users-unsubscribe_at_javaserverfaces.dev.java.net>
>>>>> For additional commands, e-mail: users-
>>>>> help_at_javaserverfaces.dev.java.net
>>>>> <mailto:help_at_javaserverfaces.dev.java.net>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> users-unsubscribe_at_javaserverfaces.dev.java.net
>>>> <mailto:users-unsubscribe_at_javaserverfaces.dev.java.net>
>>>> For additional commands, e-mail:
>>>> users-help_at_javaserverfaces.dev.java.net
>>>> <mailto: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
>>> <mailto:users-unsubscribe_at_javaserverfaces.dev.java.net>
>>> For additional commands, e-mail:
>>> users-help_at_javaserverfaces.dev.java.net
>>> <mailto:users-help_at_javaserverfaces.dev.java.net>
>>>
>>>
>>>
>>>
>>
>
--
Jacob Hookom - Minneapolis
--------------------------
http://hookom.blogspot.com