Джерси Асинхронный ContainerRequestFilter

Это не встроено в Джерси с версии 2.7.

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

ОБНОВЛЕНИЕ - есть и другие способы...

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

Guice AOP – ошибка

Я использую Guice для DI (внедрение Guice для работы с Джерси — это подвиг сам по себе!), поэтому я решил, что могу использовать Guice AOP, чтобы обойти эту проблему. Хотя внедрение Guice работает, невозможно заставить Guice создавать классы ресурсов с помощью Джерси 2, поэтому Guice AOP не может работать с методами классов ресурсов. Если вы отчаянно пытаетесь заставить Guice создавать классы ресурсов с помощью Jersey 2, не тратьте время понапрасну, потому что это не сработает. Это хорошо известная проблема.

HK2 AOP — РЕКОМЕНДУЕМОЕ РЕШЕНИЕ

HK2 недавно выпустила функцию AOP, см. этот вопрос, чтобы узнать, как заставить ее работать.

Мониторинг — тоже работает

Это не для слабонервных, и это совершенно не рекомендуется в документах по Джерси. . Вы можете зарегистрировать и ApplicationEventListener и переопределить onRequest, чтобы вернуть RequestEventListener, который прослушивает RESOURCE_METHOD_START и вызывает службу аутентификации/авторизации. Это событие запускается из потока @ManagedAsync, что и является здесь всей целью. Одно предостережение: метод abortWith не работает, поэтому он не будет работать так же, как обычный ContainerRequestFilter. Вместо этого вы можете создать исключение, если аутентификация не удалась, и зарегистрировать ExceptionMapper для обработки вашего исключения. Если кто-то достаточно смелый, чтобы попробовать, дайте мне знать, и я опубликую код.

Я не уверен, что это то, что вы искали, но заглядывали ли вы в Spring OncePerRequestFilter? В настоящее время я использую его для своего уровня авторизации, где каждый запрос проходит через некоторый фильтр, который расширяет этот OncePerRequestFilter в зависимости от того, как мои фильтры сопоставляются с URL-адресами. Вот краткий обзор того, как я его использую:

Аутентификация/авторизация ресурс в Dropwizard

Я не очень хорошо разбираюсь в частях асинхронной отправки этих фильтров, но я надеюсь, что эта ссылка хотя бы прольет свет на то, чего вы пытаетесь достичь!

Мы используем безопасность Spring для аутентификации/авторизации. Я решил проблему, используя локатор подресурсов с пустым путем, как показано ниже:

@Path("/customers")
public class CustomerResource {
    @Inject
    private CustomerService customerService;

    @Path("")
    public CustomerSubResource delegate() {
        final Authentication auth = SecurityContextHolder.getContext().getAuthentication();
        return new CustomerSubResource(auth);
    }

    public class CustomerSubResource {
        private final Authentication auth;           

        public CustomerSubResource(final Authentication auth) {
            this.auth = auth;
        }

        @POST
        @Path("")
        @Produces(MediaType.APPLICATION_JSON)
        @Consumes(MediaType.APPLICATION_JSON)
        @ManagedAsync
        public void createCustomer(final Customer customer, @Suspended final AsyncResponse response) {
            // Stash the Spring security context into the Jersey-managed thread
            SecurityContextHolder.getContext().setAuthentication(this.auth);

            // Invoke service method requiring pre-authorization
            final Customer newCustomer = customerService.createCustomer(customer);

            // Resume the response
            response.resume(newCustomer);
        }
    }
}