Обработка исключения домена во время оценки шаблона
Я разрабатываю страницу ошибки для определенного типа исключения.
<error-page>
<exception-type>xxx.AbstractConfigurableNotFoundException</exception-type>
<location>/xxx/page-not-found.xhtml</location>
</error-page>
Я использую OmniFaces и их фабрику исключений для обработки ошибок.
<factory>
<exception-handler-factory>org.omnifaces.exceptionhandler.FullAjaxExceptionHandler</exception-handler-factory>
</factory>
AbstractConfigurable — это доменный класс, и его экземпляр создается во время оценки шаблона*. Конструктор AbstractConfigurable может бросить AbstractConfigurableNotFoundException. Когда это происходит, это исключение в качестве причины оборачивается в исключения, специфичные для шаблона.
javax.servlet.ServletException
Caused by: javax.faces.view.facelets.TagAttributeException
Caused by: com.sun.faces.mgbean.ManagedBeanCreationException
...
Caused by: xxx.AbstractConfigurableNotFoundException
В результате выходит другой тип исключения и моя логика <error-page> не применяется.
Очевидно, я не хочу обращаться, javax.faces.view.facelets.TagAttributeException
<error-page>
<exception-type>javax.faces.view.facelets.TagAttributeException</exception-type>
<location>/xxx/page-not-found.xhtml</location>
</error-page>
но я хотел бы обработать любое исключение с помощью AbstractConfigurableNotFoundException в качестве причины.
Могу ли я что-нибудь с этим поделать?
Ответы 1
FullAjaxExceptionHandler поддерживает параметр контекста, чтобы установить полные имена типов исключений для развертывания. Ниже приведена выдержка из его документация:
Configuration
By default only
FacesExceptionandELExceptionare unwrapped. You can supply a context parameter "org.omnifaces.EXCEPTION_TYPES_TO_UNWRAP" to specify additional exception types to unwrap. The context parameter value must be a commaseparated string of fully qualified names of additional exception types. Note that this also covers subclasses of specified exception types.<context-param> <param-name>org.omnifaces.EXCEPTION_TYPES_TO_UNWRAP</param-name> <param-value>javax.ejb.EJBException,javax.persistence.RollbackException</param-value> </context-param>This context parameter will also be read and used by
FacesExceptionFilter.
Итак, в вашем конкретном случае вы можете использовать следующую конфигурацию в web.xml:
<context-param>
<param-name>org.omnifaces.EXCEPTION_TYPES_TO_UNWRAP</param-name>
<param-value>com.sun.faces.mgbean.ManagedBeanCreationException</param-value>
</context-param>
Обратите внимание, что javax.faces.view.facelets.TagAttributeException является расширением FacesException, которое по умолчанию уже развернуто, поэтому вам не нужно указывать это вместе.
Это был действительно странный пример... Обновлен с помощью реальной трассировки стека. Спасибо за ответ.
Верно. Ответ также обновлен соответственно. В следующих вопросах, пожалуйста, не запутывайте код/логику/поведение, которые находятся вне вашего контроля. Это сделало бы вопрос потенциально действительно запутанным для экспертов.
Это действительно странный пример. Пользовательское исключение, заключенное в NFE, которое, в свою очередь, заключено в IAE. Надеюсь, это просто пример? И я не понимаю, почему вы настроили расположение страницы с ошибкой, когда используете
FacesMessageExceptionHandlerвместоFullAjaxExceptionHandler. Какой из них вы действительно используете? Последний, согласно его javadoc, имеетorg.omnifaces.EXCEPTION_TYPES_TO_UNWRAP, который может быть полезен.