javax.faces.application.ViewExpiredException, по-видимому, игнорируется

Я поместил в свой web.xml следующее:

    <error-page>
    <exception-type>javax.faces.application.ViewExpiredException</exception-type>
    <location>/expiredIndex.jsf</location>
</error-page>
<error-page>
    <exception-type>java.lang.Throwable</exception-type>
    <location>/error.jsf</location>
</error-page>
<session-config>
    <session-timeout>1</session-timeout>
</session-config>

Когда я запускаю свое приложение и жду 1 минуту, если я затем попытаюсь взаимодействовать с ним (JSF 1.2, h:commandButton), я получаю сообщение об ошибке

 SEVERE: Servlet.service() for servlet Faces Servlet threw exception
javax.faces.application.ViewExpiredException: viewId:/index.jsf - View /index.jsf could not be restored.
    at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:185)
    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
    at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:103)
    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
    at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
    at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388)
    at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
    at java.lang.Thread.run(Unknown Source)

Может кто-нибудь сказать мне, почему не забирают javax.faces.application.ViewExpiredException? Я ищу самую простую возможную настройку срока действия и, конечно же, все, что необходимо в веб-дескрипторе.

Спасибо

ИЗМЕНИТЬ

Теперь в моем web.xml есть следующее:

<filter>
    <filter-name>Error</filter-name>
    <filter-class>myClient.ErrorFilter</filter-class>
</filter>

<filter-mapping>
    <filter-name>Error</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

    <error-page>
        <exception-type>javax.servlet.ViewExpiredException</exception-type>
        <location>/expiredIndex.jsf</location>
    </error-page>

(эти записи являются последними записями фильтра в файле web.xml) и новый фильтр с методом doFilter, как описано в этот пост. Что должно произойти сейчас, так это rootCause должно развернуть исключение ViewExpiredException, которое, таким образом, должно перенаправить пользователя на мою expiredIndex страницу по истечении времени ожидания сеанса сервлета. Вместо этого я получаю 500. Я не вижу, что еще мне нужно для правильного перенаправления в этой ситуации. Помощь!

ИЗМЕНИТЬ 2

Ошибка от 500:

javax.faces.application.ViewExpiredException: viewId:/index.jsf - View /index.jsf could not be restored.
    com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:185)
    com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
    com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:103)
    com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
    javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
    org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
    org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
    org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388)
    org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515)
    prismClient.ErrorFilter.doFilter(Unknown Source)

который, я думаю, является стандартным.


java jsf viewexpiredexception
person volvox    schedule 17.01.2011    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Это потому, что ViewExpiredException -как все остальные FacesException- под крышками были завернуты в ServletException. Он используется для поиска совпадений на объявленных страницах ошибок. Ближайшее совпадение - java.lang.Throwable, поэтому отображается соответствующая страница с ошибкой.

Если бы совпадение не было найдено, то основная причина ServletException была бы развернута, и будет выполнен второй проход по объявленным страницам ошибок с развернутым исключением. Если вы удалите запись java.lang.Throwable, вы увидите, что это сработает.

Если вы хотите сохранить java.lang.Throwable, то лучше всего создать Filter, который разворачивает любые FacesException из ServletException и повторно бросает их.

Смотрите также:

person BalusC    schedule 17.01.2011
comment
Интересно - я вижу, что страница expiredIndex настроена правильно, но я не обрабатываю базовое исключение java в серверной части. Спасибо! - person volvox; 18.01.2011
comment
Я отредактировал свой вопрос, так как у меня есть еще один вопрос. Еще раз спасибо за ваш вклад. - person volvox; 18.01.2011
comment
Возможно, здесь уместна одна мысль - не следует ли мне явно приводить бросок rootCause как ViewExpiredException вместо RuntimeException, чтобы заблокировать его, или это не очень хорошая идея? - person volvox; 18.01.2011
comment
В этом нет необходимости. Приведение просто изменяет тип среды выполнения, но не фактический тип. Сравнение на объявленных страницах ошибок происходит с фактическим типом (с использованием instanceof под водой и т. Д.). Если только вы не захотите перебросить все остальные RuntimeExceptions равнины. Что касается вашей новой проблемы, каковы именно те 500, которые у вас есть? Страница ошибок по умолчанию для java.lang.Throwable? Если нет, то каков след? - person BalusC; 18.01.2011
comment
А, я вижу, полное квалифицированное имя ViewExpiredException в <exception-type> неверно. Он должен быть javax.faces.application.ViewExpiredException, как в вашем первоначальном объявлении, а не javax.servlet.ViewExpiredException, как в обновленном объявлении. Неправильного вообще не существует. - person BalusC; 18.01.2011
comment
@BalusC хорошо заметен! Это мой первый удар по фильтрам, и ваша помощь действительно очень ценится. - person volvox; 19.01.2011

arrow_upward
0
arrow_downward

См. Блог, посвященный аналогичной проблеме, здесь: он менее громоздкий и достаточно эффективный. Не забудьте включить теги "обработчик просмотра" в теги "приложения", у меня это сработало, ура.

person user6745578    schedule 01.09.2012
comment
Сообщения в блогах могут изменяться, поскольку они находятся вне контроля Stack Overflow. Пожалуйста, подумайте о том, чтобы написать краткое изложение подхода к блогу, чтобы ваш комментарий был полезен, даже если блог переместится или исчезнет в будущем. - person GargantuChet; 02.09.2012
comment
Использование нескольких источников также является хорошей идеей. Если блог изменился, у вас может быть профессиональный резервный источник - person imulsion; 22.09.2012