Для обслуживания всех запросов из приложения Spring, а также /favicon.ico и файлов JSP из / WEB-INF / jsp / *, которые будет запрашивать SpringU AbstractUrlBasedView, вы можете просто переназначить сервлет jsp и сервлет по умолчанию:
<servlet>
<servlet-name>springapp</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>jsp</servlet-name>
<url-pattern>/WEB-INF/jsp/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>/favicon.ico</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>springapp</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
Мы не можем полагаться на шаблон URL * .jsp при стандартном отображении для сервлета jsp, поскольку шаблон пути / / * сопоставляется до того, как проверяется любое сопоставление расширения. Отображение сервлета jsp в более глубокую папку означает, что он сопоставляется первым. Совпадение /favicon.ico точно происходит до сопоставления с шаблоном пути. Подойдут более глубокие совпадения путей или точные совпадения, но никакие совпадения расширений не могут пройти после совпадения пути '/ *. Отображение «/» в сервлет по умолчанию не работает. Можно подумать, что точный символ '/' превзойдет шаблон пути '/ *' в springapp.
Приведенное выше решение для фильтрации не работает для переадресованных / включенных запросов JSP из приложения. Чтобы заставить его работать, мне пришлось применить фильтр непосредственно к Springapp, после чего сопоставление URL-паттерна было бесполезным, так как все запросы, поступающие в приложение, также попадают в его фильтры. Поэтому я добавил сопоставление с шаблоном в фильтр, а затем узнал о сервлете jsp и увидел, что он не удаляет префикс пути, как это делает сервлет по умолчанию. Это решило мою проблему, которая была не совсем такой же, но достаточно распространенной.