Случайная ошибка JSF: состояние сохраненного состояния не найдено

Question

У меня очень странная ошибка: для идентификатора вида не найдено сохраненного состояния представления: /mypage.xhtml
Проблема в том, что она отображается случайным образом, 10% пользователей/исполнений.

Сервер приложений: Apache Tomee 1.5.2 stable/1.6.0-2013.09.20 dev (Это происходит на обоих). Я использую дистрибутив MyFaces, который поставляется с каждым из них, поэтому 2.1.10/2.1.12, поэтому ничего нового не добавлено.

Часть web.xml:

 <context-param> 
     <param-name>org.apache.myfaces.USE_ENCRYPTION</param-name> 
     <param-value>false</param-value> 
     </context-param> 
     <context-param> 
     <param-name>javax.faces.STATE_SAVING_METHOD</param-name> 
     <param-value>client</param-value> 
     </context-param> 

Таким образом, ни одно государство вид исключение не должно произойти, потому что государство на стороне клиента. Он был установлен на сервере раньше, но я подумал, что клиент может это исправить, но ничего. На самом деле не было никакой разницы в возникновении этой ошибки.

Выполнение потока:
1. Клиент открывает страницу xhtml (JSF).
2. Клиент нажимает на командную кнопку для выполнения различных действий, кнопка, связанная с общедоступным методом void JSF @ViewScoped ManagedBean.
3. Да, метод недействителен, потому что мне не нужно возвращать String для перенаправления на другую страницу. Мне нужно перенаправить на/page/id (пример:/market/24,/profile/43), поэтому методы, возвращающие строку в качестве навигационных целей, бесполезны, потому что я использую: FacesContext.getCurrentInstance().getExternalContext().redirect(path);
4. В ~ 90% случаев, все работает отлично, и пользователи перенаправляются на каждую конкретную страницу. В остальной части ~ 10 (случайным образом) они получат No saved view state could be found for the view identifier: /pagename.xhtml

Я бы очень признателен за помощь здесь, потому что я понятия не имею, как это исправить.
Большое спасибо.

PS. Я использую PrimeFaces, и у меня также есть несколько собственных фильтров в web.xml, но это не должно быть проблемой. Надеюсь, что так.

Стек трассировки для одной из страниц:

25-Sep-2013 07:39:26.380 SEVERE [http-bio-80-exec-15] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [Faces Servlet] in context with path [] threw exception [/dashboard/edit-profile.xhtmlNo saved view state could be found for the view identifier: /dashboard/edit-profile.xhtml] with root cause 
javax.faces.application.ViewExpiredException: /dashboard/edit-profile.xhtmlNo saved view state could be found for the view identifier: /dashboard/edit-profile.xhtml 
     at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:132) 
     at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:170) 
     at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) 
     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197) 
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) 
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) 
     at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:77) 
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) 
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) 
     at org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:199) 
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) 
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) 
     at com.pingushare.boundary.filter.ActivateAccountFilter.doFilter(ActivateAccountFilter.java:37) 
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) 
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) 
     at com.pingushare.boundary.filter.SecurityFilter.doFilter(SecurityFilter.java:36) 
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) 
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) 
     at com.pingushare.boundary.filter.ForceFreshPageAndWWWFilter.doFilter(ForceFreshPageAndWWWFilter.java:49) 
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) 
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) 
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) 
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) 
     at org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45) 
     at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) 
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) 
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) 
     at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953) 
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) 
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) 
     at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023) 
     at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) 
     at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) 
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
     at java.lang.Thread.run(Thread.java:724) 

Answer 1

После долгих обсуждений на форумах MyMaces и Tomee/списках рассылки мне удалось устранить эту проблему: I переключил реализацию JSF в этом проекте на Majorra 2.1.26. Ошибка больше не появлялась до сих пор.

Поскольку эта ошибка не имела никакого смысла (после проверки источника как моего проекта, так и MyFaces) и не могла быть воспроизведена, мы не смогли на самом деле найти исправление для него, но по крайней мере этого не происходит в Майорре, поэтому это может быть полезно, если кто-то другой получит эту ошибку.

Упоминание: это не базовое «состояние сохраненного состояния просмотра не может быть найдено», которое получают многие разработчики JSF. Это где-то еще где-то скрывается.

Answer 2

Эта проблема хорошо изучена, и это происходит потому, что если сервер будет перезапущен или приложение заново, новый ключ шифрования генерируется по умолчанию. Решение сгенерирует ваш собственный ключ и настроит его в файле web.xml. Таким образом, MyFaces будет использовать один и тот же ключ во все времена. См. http://wiki.apache.org/myfaces/Secure_Your_Application

Описание утверждает, что шифрование отключено, и я проверил код, и все в порядке, оно работает как ожидается (шифрование эффективно отключено). Если шифрование не является проблемой, я считаю, что в вашей логике приложения есть ошибка. Не вызывайте перенаправление таким образом, используйте стандартную форму, используя mypage.xhtml? Faces-redirect = true. Проблема может быть вызвана истечением срока действия сеанса (только просмотр объектов области видимости для клиента переходит к клиенту в версии 2.0/2.1, но сфера активности сеанса истек).