2014-09-21 5 views
6

Есть ли способ, чтобы мои методы @ExceptionHandler имели доступ к атрибутам модели, заполненным методом @RequestMapping, который вызвал рассматриваемое исключение?Модельное население весной MVC @ExceptionHandler

Или, более конкретно, для моей проблемы: мои модели, переданные моим представлениям, имеют некоторые данные, заполненные из @ModelAttribute (например, подробная информация об учетной записи пользователя), и я хотел бы, чтобы они также были установлены в моих методах @ExceptionHandler ,

Например, поскольку моя страница просмотра ошибок использует тот же заголовок и меню, что и другие мои страницы, я хочу показать текущее имя пользователя (и другую информацию, например, количество непрочитанных сообщений и т. Д.).

Я знаю, что @ExceptionHandler существует за пределами @Transaction (как и должно быть!), Поэтому я, очевидно, не могу просто (и не хочу) запускать некоторые запросы снова. Скорее, я хотел бы предварительно заполнить ModelMap или ModelAndView или что-то еще, и убедитесь, что обработчик исключений справляется с этим - или, по крайней мере, данные модели становятся доступными при визуализации представления.

Я надеюсь, что этот вопрос имеет смысл, я довольно новый для Spring MVC, так что я может быть смешиванием нескольких концепций здесь и там ...

ответ

1

Мысли его можно, но:

http://spring.io/blog/2013/11/01/exception-handling-in-spring-mvc

Важное примечание. Модель не может быть параметром любого метода 44ExpertHandler. Вместо этого настройте модель внутри метода с помощью ModelAndView, как показано выше в handleError().

Кажется, вы должны отказаться от ModelAndView, как и в любом другом контроллере, поэтому его необходимо еще раз построить + получить возможные значения из HttpServletRequest.

3

В javadoc из ExceptionHandler гласит следующее в отношении аргументов, которые могут быть переданы методу обработчика:

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

1. An exception argument: declared as a general Exception or as a more specific exception. This also serves as a mapping hint if the annotation itself does not narrow the exception types through its value(). 
2. Request and/or response objects (Servlet API or Portlet API). You may choose any specific request/response type, e.g. ServletRequest/HttpServletRequest or PortletRequest/ActionRequest/RenderRequest. Note that in the Portlet case, an explicitly declared action/render argument is also used for mapping specific request types onto a handler method (in case of no other information given that differentiates between action and render requests). 
3. Session object (Servlet API or Portlet API): either HttpSession or PortletSession. An argument of this type will enforce the presence of a corresponding session. As a consequence, such an argument will never be null. Note that session access may not be thread-safe, in particular in a Servlet environment: Consider switching the "synchronizeOnSession" flag to "true" if multiple requests are allowed to access a session concurrently. 
4. WebRequest or NativeWebRequest. Allows for generic request parameter access as well as request/session attribute access, without ties to the native Servlet/Portlet API. 
5. Locale for the current request locale (determined by the most specific locale resolver available, i.e. the configured LocaleResolver in a Servlet environment and the portal locale in a Portlet environment). 
6. InputStream/Reader for access to the request's content. This will be the raw InputStream/Reader as exposed by the Servlet/Portlet API. 
7. OutputStream/Writer for generating the response's content. This will be the raw OutputStream/Writer as exposed by the Servlet/Portlet API. 
8. Model as an alternative to returning a model map from the handler method. Note that the provided model is not pre-populated with regular model attributes and therefore always empty, as a convenience for preparing the model for an exception-specific view. 

Так что для того, чтобы заполнить модель представления будет использоваться для отображения ошибки, вы, вероятно, придется идти с WebRequest

+0

В случае, если это полезно для всех, кто найдет это, как у меня, - на момент написания статьи Javadocs, связанный выше, включал 8-й вариант: «Модель как альтернатива возврату модели модели из метода обработчика. при условии, что модель не предварительно заполнена обычными атрибутами модели и поэтому всегда пуста, в качестве удобства для подготовки модели для конкретного исключения vi РЭБ». Это довольно явно противоречит сообщению в блоге, связанному с ответом freakman, который, насколько я могу судить по экспериментам, правилен, и Javadocs ошибаются. Спасибо Spring :) – DaveyDaveDave

+0

@DaveyDaveDave Спасибо за комментарий. Я добавил 8-й вариант. – geoand

+0

К сожалению - я хотел добавить, после немного большего количества расследований я заметил, что 8-й вариант был добавлен только некоторое время между версиями v4.1.7 и v4.2.2.Чтобы быть ясным, параметр модели здесь не та же модель, что и у вас, если бы метод контроллера продолжался без исключения; это новая пустая модель, готовая к заполнению и использованию на вашей странице ошибок. – DaveyDaveDave

Смежные вопросы