Обработка исключений JAX-RS в Websphere Liberty

Это ожидаемое поведение, основанное на Разделе 3.3.4 (и 4.5.1) JAX-RS 2.0 Spec. В этих разделах описывается, как обрабатываются исключения из ресурсов и поставщиков JAX-RS — вкратце:

1. Если исключением является WebApplicationException, то оно автоматически сопоставляется с Response.
2. Если есть зарегистрированный ExceptionMapper, который может обработать выброшенное исключение, то он будет использоваться для генерации ответа.
3. Непроверенные исключения распространяются на контейнер (т. е. код реализации Liberty JAX-RS).
4. Несопоставленные исключения должны обрабатываться через исключение, специфичное для контейнера, а затем должным образом распространяться на базовый контейнер — в этом случае веб-контейнеру необходимо передать ServletException.

JaxRsRuntimeException используется для выполнения шага 4.

В этом сценарии встроенный провайдер JSON (на основе Jackson 1.X) выдает ошибку EOFException. Поскольку для EOFException (или любого из его суперклассов) не существует сопоставителей исключений, оно в конечном итоге сопоставляется с ServletException посредством JaxRsRuntimeException.

Чтобы приложение могло справиться с этим сценарием, существует несколько различных вариантов:

1. Вы можете зарегистрировать ExceptionMapper, специфичный для этого типа исключения (EOFException или любого из его суперклассов, т.е. IOException). Вам не нужно регистрировать сопоставитель для JaxRsRuntimeException, так как это исключение используется только внутри Liberty и не должно сопоставляться. Если вы видите, что JaxRsRuntimeException передается ExceptionMapper, вам следует обратиться в службу поддержки IBM, так как это, скорее всего, ошибка.

С помощью ExceptionMapper<EOFException> вы можете возвращать определенный ответ всякий раз, когда EOFException вызывается поставщиком или ресурсом.

2. Вы можете зарегистрировать свой собственный MessageBodyReader, который будет преобразовывать JSON в объекты (используя Jackson или любой другой код сериализации JSON), но будет обрабатывать пустые тела сообщений так, как вы хотите, например, преобразовывая его в null или используя какой-то экземпляр объекта по умолчанию. . Поскольку зарегистрированные пользователем провайдеры имеют приоритет над встроенными провайдерами, этот MBR будет использоваться вместо MBR Liberty на основе Джексона.

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

3. Зарегистрируйте поставщика ContainerRequestFilter, который прервется, когда тело сообщения будет пустым. Вот пример:

   @Provider
   public class EmptyBodyCheckFilter implements ContainerRequestFilter {
   
       @Override
       public void filter(ContainerRequestContext crc) throws IOException {
           if (crc.getEntityStream().available() < 1) {
               crc.abortWith(Response.status(400).entity("Invalid request - empty message body").build());
           }
       }
   }
   

Я успешно протестировал варианты 1 и 3 с помощью бета-версии WebSphere Liberty, выпущенной в мае 2018 года. Я лично не тестировал вариант 2 для этого сценария, но, основываясь на использовании пользовательских MBR в прошлом, это должно работать.

Следует иметь в виду, что когда Liberty GA реализует функцию jaxrs-2.1, она будет использовать JSONB в качестве встроенного поставщика для сериализации/десериализации JSON вместо Jackson. Я протестировал ваш сценарий с использованием JAX-RS 2.1 (также в майской бета-версии), и вместо EOFException код JSONB выдает NoSuchElementException. Если вы думаете, что можете перейти на JAX-RS 2.1, я бы предложил вариант 2 или 3. Вариант 1 требует, чтобы вы создали новый ExceptionMapper для JAX-RS 2.1.

Надеюсь это поможет,

Энди

Не прямой ответ на "почему WLP оборачивает исключение ..etc", но, возможно, добавьте перехватчик исключений, как вы это сделали, но on"ExceptionMapper<Exception>"и рекурсивно повторите "причины", чтобы проверить, является ли java.io.EOFException одной из этих...