I ended up taking your advice on using a servlet filter + request
wrapper. Ultimately returning something from getServletPath seems to
have done the trick!
Thanks for the tip,
Ryan
On Sep 25, 2005, at 6:42 PM, Jacob Hookom wrote:
> If you are extending Facelets, have you tried just overriding
> FaceletViewHandler.buildView(FacesContext, UIViewRoot) ?
>
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: users-
> help_at_javaserverfaces.dev.java.net
>
>
>
>