ViewExpiredException при каждой навигации после перехода с JSF 1.2 на JSF 2.0

Я пытаюсь перенести существующее приложение JSF с JSF 1.2 на JSF 2.0. Я использовал MyFaces 1.2.8 и хочу использовать MyFaces 2.0.5.

Что я испытываю с MyFaces 2.0.5, так это то, что первоначально запрошенная страница будет отображаться правильно, но любая попытка перейти на другую страницу приведет к ошибке ViewExpiredException. Сообщение:

Не удалось найти сохраненное состояние просмотра для идентификатора представления: /SomePageName.jsf (где SomePageName — это имя страницы, с которой я ухожу)

Если я вручную ввожу удобный для лиц URL-адрес страницы, на которую хочу перейти, например http://localhost:8080/MYAPP/SomeOtherPage.jsf , тогда другая страница будет отображаться правильно. Приложение также распознает, что у меня уже есть сессия и не пытается создать новую.

Мое приложение состоит исключительно из файлов JSP, как и следовало ожидать от приложения JSF 1.2. Я намерен сначала заставить приложение работать в JSF 2.0, а затем переписать каждую страницу как Facelet по одной за раз.

Некоторые из моих правил навигации выглядят так:

<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>

а некоторые выглядят так:

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

(Я понимаю, что результат REFRESH - не лучший способ сделать что-то, но он уже был в старом приложении 1.2, и я не планирую его удалять, пока не начну миграцию)

Может ли кто-нибудь сказать мне, что я могу делать неправильно, что может привести к такому взрыву навигации?


java jsf jsf-2 myfaces viewexpiredexception
person Jim Tough    schedule 27.05.2011    source источник
comment
Я подозреваю, что это специфично для MyFaces, у нас не было этой проблемы при переходе с Mojarra 1.2 на 2.0. Я бы предложил попробовать вместо этого, хотя это только для того, чтобы исключить одно и другое, чтобы вы могли в конечном итоге сообщить о проблеме мальчикам MyFaces.   -  person BalusC    schedule 27.05.2011
comment
У меня заканчиваются идеи, поэтому, возможно, единственная логичная альтернатива — попробовать другую реализацию JSF. Я сомневаюсь только потому, что мы используем надстройки MyFaces Tomahawk и Trinidad в переносимом мной приложении. Чтобы попробовать приложение с помощью Mojarra (или чего-то еще), мне придется удалить куски страниц, которые зависят от надстроек. О, ладно, я думаю, я должен перестать беспокоиться об этом и просто сделать это! :)   -  person Jim Tough    schedule 27.05.2011
comment
Tomahawk/Trinidad явно не требует MyFaces в качестве реализации JSF. Это (маркетинговый) миф. Просто они принадлежат одному и тому же поставщику (Apache). Для сторонних библиотек компонентов JSF требуется только JSF API. Импл (Mojarra, MyFaces и т. д.) действительно не должен иметь значения.   -  person BalusC    schedule 27.05.2011
comment
Вы были правы по всем пунктам! Во-первых, я заменил основные файлы JSF JAR MyFaces (API и внедрение) последними файлами Mojarra JAR (кажется, версии 2.1.1). У меня не было исключений для определения классов, и я думал, что вы ошибаетесь насчет Тринидада и Томагавка. Проблема оказалась в кеше скомпилированных JSP, которые все еще хотели использовать MyFaces. После очистки кеша JSP все вдруг заработало так, как раньше работало в JSF 1.2. MyFaces был выбран для этого проекта давно и без особых причин, поэтому я собираюсь заменить его при миграции. Спасибо за вашу помощь!   -  person Jim Tough    schedule 27.05.2011
comment
Пожалуйста. Я перепостил это как ответ.   -  person BalusC    schedule 27.05.2011

Ответы (2)


arrow_upward
2
arrow_downward

Я подозреваю, что это связано с MyFaces, у нас не было этой проблемы при переходе с Mojarra 1.2 на 2.0. Я бы предложил попробовать вместо этого, хотя это только для того, чтобы исключить одно и другое, чтобы вы могли в конечном итоге сообщить о проблеме мальчикам MyFaces.

У меня заканчиваются идеи, поэтому, возможно, единственная логичная альтернатива — попробовать другую реализацию JSF. Я сомневаюсь только потому, что мы используем надстройки MyFaces Tomahawk и Trinidad в переносимом мной приложении. Чтобы попробовать приложение с помощью Mojarra (или чего-то еще), мне придется удалить куски страниц, которые зависят от надстроек. О, ладно, я думаю, я должен перестать беспокоиться об этом и просто сделать это! :)

Tomahawk/Trinidad явно не требует MyFaces в качестве реализации JSF. Это (маркетинговый) миф. Просто они принадлежат одному и тому же поставщику (Apache). Для сторонних библиотек компонентов JSF требуется только JSF API. Импл (Mojarra, MyFaces и т. д.) действительно не должен иметь значения.

person BalusC    schedule 27.05.2011

arrow_upward
0
arrow_downward

Эта проблема была исправлена ​​на:

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

Обратите внимание, что в MyFaces 2.0.7 и 2.1.1 есть исправление.

person lu4242    schedule 25.06.2011