Geek Answers Handbook

ViewExpiredException on every navigation after transition from JSF 1.2 to JSF 2.0

I am trying to migrate an existing JSF application from JSF 1.2 to JSF 2.0. I used MyFaces 1.2.8 and want to use MyFaces 2.0.5.

What I'm testing with MyFaces 2.0.5 is that the initially requested page will display correctly, but any attempt to go to another page will result in a ViewExpiredException . Message:

There is no saved view state for the view identifier: /SomePageName.jsf (where "SomePageName" is the name of the page I'm navigating from)

If I manually type in the Faces URL for the page I wanted to go to, for example http: // localhost: 8080 / MYAPP / SomeOtherPage.jsf , then the other page will display correctly. The application also acknowledges that I already have a session and is not trying to create a new one.

My application consists solely of JSP files, as you would expect from a JSF 1.2 application. My intention is to first get the application running in JSF 2.0 and then rewrite each page as one Facelet at a time.

Some of my navigation rules are as follows:

 <navigation-rule> <display-name>ManagePorts</displayName> <from-view-id>/ManagePorts.jsp</from-view-id> <navigation-case> <from-outcome>REFRESH</from-outcome> <to-view-id>/ManagePorts.jsp</to-view-id> </navigation-case> </navigation-rule>

and some are as follows:

 <navigation-rule> <navigation-case> <from-outcome>MANAGE_PORT_LIST</from-outcome> <to-view-id>/ManagePorts.jsp</to-view-id> </navigation-case> </navigation-rule>

(I understand that the result of REFRESH is not the best way to do something, but it was already in the old application 1.2, and I do not plan to delete it until I start the migration)

Can someone tell me what I can do wrong, which will cause the navigation to explode like this?

+4
source share
2 answers

I suspect this is a feature of MyFaces, we did not have this problem when porting from Mojarra from 1.2 to 2.0. I would suggest trying instead, although this is only to exclude both, so that you can ultimately report this issue to the MyFaces boys.

I'm running out of ideas, so maybe trying another JSF implementation is the only logical alternative. I only hesitate, because we use the add-ons MyFaces Tomahawk and Trinidad in the application that I am porting. To try the application using Mojarra (or something else), I will have to remove the pieces of pages that depend on add-ons. Well, I think I should stop worrying about it and just do it! :)

Tomahawk / Trinidad does not explicitly require the use of MyFaces as a JSF impl. This is a (marketing) myth. They simply come from the same provider (Apache). Third-party JSF component libraries require the JSF API. Implants (Mojarra, MyFaces, etc.) Really should not matter.

+2
source

This issue has been fixed:

https://issues.apache.org/jira/browse/MYFACES-3101

Note. MyFaces 2.0.7 and 2.1.1 have a fix.

0
source

More articles:


All Articles