4

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?

Jim Tough
  • 14,843
  • 23
  • 75
  • 96
  • 1
    I suspect that this is MyFaces specific, we didn't have this problem when migrating from [Mojarra](http://javaserverfaces.java.net) 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. – BalusC May 27 '11 at 14:34
  • 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! :) – Jim Tough May 27 '11 at 15:18
  • 1
    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. – BalusC May 27 '11 at 15:19
  • You were correct on all counts! First, I replaced the MyFaces core JSF JARs (API and impl) with the latest Mojarra JARs (version 2.1.1 I think). I started having no class def exceptions and was thinking that you were wrong about Trinidad and Tomahawk. The problem turned out to be a cache of compiled JSPs that still wanted to use MyFaces. With the JSP cache cleared, suddenly everything worked the way it used to work under JSF 1.2. MyFaces was chosen a long time ago for this project for no particular reason, so I'm going to replaced it during the migration. Thanks for your help! – Jim Tough May 27 '11 at 17:42
  • You're welcome. I reposted it as an answer. – BalusC May 27 '11 at 18:07

2 Answers2

2

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.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
0

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.

lu4242
  • 2,318
  • 1
  • 15
  • 15