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

Question

I'm attempting to migrate an existing JSF application from JSF 1.2 to JSF 2.0. I was using MyFaces 1.2.8 and want to use MyFaces 2.0.5.

What I'm experiencing with MyFaces 2.0.5 is that the initially requested page will render properly, but any attempt to navigate to another page will result in a ViewExpiredException. The message is:

No saved view state could be found for the view identifier: /SomePageName.jsf (where "SomePageName" is the name of the page that I am navigating away from)

If I manually type the Faces-friendly URL of the page I wanted to navigate to, such as http://localhost:8080/MYAPP/SomeOtherPage.jsf , then the other page will be properly rendered. The application also recognizes that I already have a session and does not try to create a new one.

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

Some of my navigation rules look like this:

<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 look like this:

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

(I realize that the REFRESH outcome is not the best way to do things, but that was already in the old 1.2 application and I'm not planning to remove it until I start the migration effort)

Can anyone tell me what I might be doing wrong that would cause the navigation to blow up like this?

Answer 1

I suspect that this is MyFaces specific, we didn't have this problem when migrating from Mojarra 1.2 to 2.0. I would suggest to try it instead, even though it's only to exclude the one and other so that you can eventually report the issue to MyFaces boys.

I'm running out of ideas, so maybe trying a different JSF implementation is the only logical alternative. I'm only hesitating because we are using the MyFaces Tomahawk and Trinidad add-ons in the application that I'm migrating. In order to try the app using Mojarra (or something else) I will have to remove chunks of the pages that depend on the add-ons. Oh well, I guess I should stop fretting about it and just do it! :)

Tomahawk/Trinidad doesn't explicitly require MyFaces as JSF impl. This is a (marketing) myth. They just happens to be from the same vendor (Apache). 3rd party JSF component libraries just require a JSF API. The impl (Mojarra, MyFaces, etc) really shouldn't matter.

Answer 2

This issue was fixed on:

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

Note MyFaces 2.0.7 and 2.1.1 has the fix.