Пользовательские страницы ошибок не работают в Jetty - PullRequest
Новая
       41

Пользовательские страницы ошибок не работают в Jetty

3 голосов
/ 11 марта 2011

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

Итак, я создал небольшой файл "servlet-error.html", включил его в свое веб-приложение и сослался на него из файла web.xml.

Мой web.xml выглядит так: 

<web-app>
  ..
  <error-page>
    <error-code>500</error-code>
    <location>/servlet-error.html</location>
  </error-page>
  <error-page>
    <error-code>503</error-code>
    <location>/servlet-error.html</location>
  </error-page>
</web-app>

Файл WAR выглядит так: 

servlet-error.html
WEB-INF/web.xml
...

Когда у меня нет раздела <error-page>, я получаю стандартную ошибку Jetty (с backtrace), когда она у меня появляется, я просто получаю белую страницу в Firefox и стандартное сообщение об ошибке браузера в Chrome. В журналах Jetty нет ошибок типа «servlet-error.html не найден».

Я попытался изменить web.xml с /servlet-error.html на /servlet-error-xxx.html, но изменений не было (= белая страница и ошибки в журнале Jetty). Поэтому я подозреваю, что он не может найти по HTML-файлу.

Дополнительная информация: приложение написано в Wicket, приложение находится в «режиме развертывания» Wicket, исключение, вызывающее ошибку, выдается в конструкторе приложения (которое, кажется, обходит обработку ошибок Wicket и скрытие исключения обратная трассировка в режиме развертывания?). Заявка на калитку включается через <servlet>, а не <filter>.

P.S. Этот Jetty находится за Apache, так что это даже правильный способ справиться с этим, или я должен добавить что-то в конфигурацию Apache, то есть «если Jetty возвращает! = 200, тогда игнорировать то, что Jetty возвращает, и вместо этого отобразить эту страницу ошибки ... «

Редактировать : я исправил первоначальную причину ошибки (т.е. приложение теперь работает без ошибок), и теперь я могу перейти на http://mydomain.com/context-root/servlet-error.html,, тогда как раньше я получал ошибку 500, если Я перехожу к этой статической HTML-странице. Я вижу, что у меня есть в моем web.xml: 

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

Я подозреваю, что, когда Jetty пытается выполнить обычный запрос, видит ошибку, затем он пытается извлечь страницу servlet-error.html, которую он также выбирает, используя web.xml, который снова попадает в попытку перейти к приложение, которое снова генерирует ошибку .. И, по-видимому, чтобы остановить бесконечный цикл, оно просто отображает в браузере пустую страницу, хотя что-то в журнале было бы неплохо!

Но я все еще не уверен, что это правильный способ решить ....

Я добавил следующее, но это не помогло. 

<servlet-mapping>
  <servlet-name>default</servlet-name>
  <url-pattern>*.html</url-pattern>
</servlet-mapping>

Ответы [ 2 ]

1 голос
/ 24 марта 2011

Это только для ошибок в конструкторе приложения Wicket? Это обрабатывается Jetty.

Ошибки на страницах Wicket переходят на страницу, которую можно указать в IApplicationSettings (в конструкторе приложения): 

IApplicationSettings settings = getApplicationSettings();
settings.setAccessDeniedPage(AccessDeniedPage.class);
settings.setPageExpiredErrorPage(PageExpiredPage.class);
settings.setInternalErrorPage(InternalErrorPage.class);

Страницы ошибок Jetty могут быть установлены в файле web.xml:

Пример кода ошибки: 

<error-page>
  <error-code>404</error-code>
  <location>/jspsnoop/ERROR/404</location>
</error-page>

Пример исключения: 

<error-page>
  <exception-type>java.io.IOException</exception-type>
  <location>/jspsnoop/IOException</location>
</error-page>

Источник: Jetty Wiki

1 голос
/ 21 марта 2011

Обновление: Нет, даже это не работает. Теперь CSS-файлы и т. Д., Такие как /resources/com.myapp.MyPage/styles.css, не обслуживаются Wicket (вместо этого они возвращают стартовую страницу в HTML), вероятно, из-за того, что информация о пути пуста и т. Д. Я ненавижу это, почему я не могу просто установить приложение Java и теперь имею Исключения, напечатанные в браузере, почему он не может просто работать!?

Оригинальный ответ: Решение состоит в том, чтобы заменить отображение сервлета Wicket на: 

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

т.е. изменить /* на /; но оставьте только директивы об ошибках и правило * .html.

Причина: этот ответ дает порядок / приоритет, в котором сопоставляются <url-pattern> s (увы, ссылки на спецификацию сервлета, похоже, больше не работают):

  1. Строка, начинающаяся с символа ‘/’ и заканчивающаяся суффиксом ‘/ *’, используется для отображения пути.
  2. Строка, начинающаяся с префикса ‘*.’, Используется как отображение расширения.
  3. Строка, содержащая только символ ’/’, обозначает сервлет «по умолчанию» приложения. В этом случае путь сервлета является URI запроса минус путь контекста, а информация о пути равна нулю.
  4. Все остальные строки используются только для точных совпадений.

Мне нужно, чтобы правило "match * .html" подчинялось предпочтению правилу "отправлять все запросы в Wicket". И /*, и / соответствуют всем запросам, но первое является первым правилом (подчиняется предпочтению * .html), тогда как второе является третьим правилом (соответствие * .html подчиняется предпочтению).

...