Может ли кто-нибудь объяснить отображение сервлетов?

Question

Я пытаюсь написать веб-приложение с помощью SpringMVC. Как правило, я просто сопоставлял некоторые расшифрованные расширения файлов с фронт-контроллером Spring и жил счастливо, но на этот раз я собираюсь использовать URL-адреса REST, без расширений имени файла.

Картирование все под моим контексте пути к фронт-контроллера (назовем его «приложение») означает, что я должен заботиться о статических файлов также, то, что я предпочел бы не делать (зачем изобретать еще один водоворот?), поэтому некоторая комбинация с сервлетом по умолчанию tomcat (давайте назовем его «tomcat»), похоже, это путь.

я получил вещь, чтобы работать, делая что-то вроде

<servlet-mapping> 
    <servlet-name>app</servlet-name> 
    <url-pattern>/</url-pattern> 
</servlet-mapping> 

<servlet-mapping> 
    <servlet-name>tomcat</servlet-name> 
    <url-pattern>*.ext</url-pattern> 
</servlet-mapping> 

и повторяя последний для каждого из расширений файлов моего статического контента. Мне просто интересно, почему следующие настройки, которые для меня эквивалентны приведенному выше, не работают.

<!-- failed attempt #1 --> 
<servlet-mapping> 
    <servlet-name>app</servlet-name> 
    <url-pattern>/*</url-pattern> 
</servlet-mapping> 

<servlet-mapping> 
    <servlet-name>tomcat</servlet-name> 
    <url-pattern>*.ext</url-pattern> 
</servlet-mapping> 

<!-- failed attempt #2 --> 
<servlet-mapping> 
    <servlet-name>app</servlet-name> 
    <url-pattern>/</url-pattern> 
</servlet-mapping> 

<servlet-mapping> 
    <servlet-name>tomcat</servlet-name> 
    <url-pattern>/some-static-content-folder/*</url-pattern> 
</servlet-mapping> 

Может ли кто-нибудь пролить свет?

Answer 1

Думаю, я знаю, что происходит.

В вашем рабочем web.xml вы установили сервлет в качестве сервлета по умолчанию (сам по себе является сервлетом по умолчанию, если нет других совпадений), он ответит на любой запрос, который не соответствует другому сопоставлению.

В случае неудачи 1 ваше/* отображение действительно является допустимым сопоставлением пути. С отображением/* в web.xml он отвечает на все запросы, кроме других сопоставлений пути. В соответствии с отображением расширения спецификации подразумеваются неявные сопоставления, которые перезаписываются явными сопоставлениями. Вот почему карта расширения не удалась. Все было явно сопоставлено с приложением.

В Failed 2 приложение отвечает за все, кроме содержимого, которое соответствует отображению статического содержимого. Чтобы показать, что происходит в быстром тесте, я настроил. Вот пример. /some-static-content-folder/ содержит test.png

Попытка доступа test.png Я попытался:

/some-static-content-folder/test.png 

и файл не был найден. Однако попытка

/some-static-content-folder/some-static-content-folder/test.png 

оно приходит вверх. Похоже, что сервлет Tomcat по умолчанию (по крайней мере, 6.0.16) снижает отображение сервлета и будет пытаться найти файл, используя оставшийся путь. Согласно этому сообщению Servlet for serving static content Jetty дает поведение, которое вы и я ожидали.

Есть ли причина, по которой вы не можете сделать что-то вроде карты корневого каталога для ваших остальных вызовов. Что-то вроде приложения, сопоставленного с/rest_root/*, чем вы несете ответственность за все, что происходит в папке rest_root, но где-нибудь еще нужно обрабатывать Tomcat, если вы не сделаете другое явное сопоставление. Я предлагаю настроить сервлет вашего отдыха на сопоставление маршрутов, потому что он заявляет о намерении лучше. Использование/или/* кажется вам нецелесообразным, так как вы должны отображать исключения.Использование SO в качестве примера, мои остальные отображения будет что-то вроде

/пользователей/* для пользователя сервлета

/сообщений/* для сообщений сервлет

Mapping заказ

1. Явные (дорожные сопоставления)
2. Неявные (расширения)
3. По умолчанию (/)

Исправьте все, что у меня получилось.

Answer 2

Я никогда не пытался отобразить такой сервлет, но я ответил, что/* делает технически оба начинаются с/и заканчиваются на/*, хотя один и тот же символ используется для обоих совпадений.

Answer 3

Для справки, «неудачная попытка № 2» совершенно верна в версии Tomcat> = до 6.0.29.

Это был результат ошибки Tomcat, которые получают исправлены в версии 6.0.29:

https://issues.apache.org/bugzilla/show_bug.cgi?id=50026

<!-- Correct for Tomcat >= 6.0.29 or other Servlet containers --> 
<servlet-mapping> 
    <servlet-name>app</servlet-name> 
    <url-pattern>/</url-pattern> 
</servlet-mapping> 

<servlet-mapping> 
    <servlet-name>default</servlet-name> 
    <url-pattern>/some-static-content-folder/*</url-pattern> 
</servlet-mapping>