Как исключить какой-то url из фильтра трикотажа?

Фильтры привязки имен

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

Также проверьте этот ответ для некоторых примеров с фильтрами привязки имен.

Глобальные фильтры

Если вас по-прежнему устраивает подход с использованием глобального фильтра, вы можете рассмотреть возможность использования UriInfo, чтобы получить подробную информацию о запрошенном URI. Используйте один из следующих подходов, чтобы получить экземпляр UriInfo:

1. Использование @Context аннотация:

   @Provider
   public class AuthFilter implements ContainerRequestFilter {
   
       @Context
       private UriInfo info;
   
       @Override
       public void filter(ContainerRequestContext requestContext) throws IOException {
           ...
       }
   }
   

1. Получение его из ContainerRequestContext < / а>:

   @Override
   public void filter(ContainerRequestContext requestContext) throws IOException {
       UriInfo info = requestContext.getUriInfo();
       ...
   }
   

• getAbsolutePath() < / a>: получить абсолютный путь запроса.
• getBaseUri() < / a>: получить базовый URI приложения.
• getMatchedResources() < / a>: получить доступный только для чтения список экземпляров класса ресурсов, совпадающих в данный момент.
• getMatchedURIs() < / a>: получить доступный только для чтения список URI для сопоставленных ресурсов.
• getPath() < / a>: получить путь к текущему запросу относительно базового URI в виде строки.
• getPathSegments() < / a>: получить путь к текущему запросу относительно базового URI в виде списка из PathSegment.
• getRequestUri() < / a>: получить абсолютный URI запроса, включая любые параметры запроса.
• { {X0}}: преобразовать URI в соответствие с текущим URI запроса.
• { {X0}}: разрешить относительный URI по отношению к базовому URI приложения.

Для получения дополнительных сведений см. {{X0} } документации.

Если запрошенный URI не соответствует URI, к которому вы хотите применить фильтр, просто используйте инструкцию return:

@Override
public void filter(ContainerRequestContext requestContext) throws IOException {
    UriInfo info = requestContext.getUriInfo();
    if (!info.getPath().contains("secured")) {
        return;
    }
}

Динамическое связывание…

Другой подход - динамическое связывание . Он позволяет динамически назначать фильтры и перехватчики методам ресурсов. Привязка имен, упомянутая выше, использует статический подход, и изменения привязки требуют изменения исходного кода и перекомпиляции. С помощью динамической привязки вы можете реализовать код, который определяет привязки во время инициализации приложения.

Следующий пример извлечен из документации Джерси. показывает, как реализовать динамическое связывание:

@Path("helloworld")
public class HelloWorldResource {

    @GET
    @Produces("text/plain")
    public String getHello() {
        return "Hello World!";
    }

    @GET
    @Path("too-much-data")
    public String getVeryLongString() {
        String str = ... // very long string
        return str;
    }
}

// This dynamic binding provider registers GZIPWriterInterceptor
// only for HelloWorldResource and methods that contain
// "VeryLongString" in their name. It will be executed during
// application initialization phase.
public class CompressionDynamicBinding implements DynamicFeature {

    @Override
    public void configure(ResourceInfo resourceInfo, FeatureContext context) {
        if (HelloWorldResource.class.equals(resourceInfo.getResourceClass())
                && resourceInfo.getResourceMethod().getName().contains("VeryLongString")) {
            context.register(GZIPWriterInterceptor.class);
        }
    }
}

Привязка выполняется с помощью поставщика, который реализует DynamicFeature интерфейс. Интерфейс определяет один метод configure с двумя аргументами, ResourceInfo и FeatureContext.

ResourceInfo содержит информация о ресурсе и методе, к которому может быть произведена привязка. Метод конфигурации будет выполняться один раз для каждого метода ресурсов, определенного в приложении. В приведенном выше примере провайдер будет выполнен дважды: один раз для метода getHello() и один раз для getVeryLongString() (один раз resourceInfo будет содержать информацию о методе getHello() и один раз он будет укажите на getVeryLongString()).

Если поставщик динамической привязки хочет зарегистрировать любого поставщика для фактического метода ресурсов, он сделает это, используя предоставленный FeatureContext, расширяющий конфигурируемый API JAX-RS. Могут использоваться все методы регистрации классов или экземпляров фильтров или перехватчиков. Такие динамически регистрируемые фильтры или перехватчики будут привязаны только к фактическому методу ресурса. В приведенном выше примере GZIPWriterInterceptor будет привязан только к методу getVeryLongString(), что вызовет сжатие данных только для этого метода, а не для метода getHello().

Обратите внимание, что фильтры и перехватчики, зарегистрированные с использованием динамической привязки, являются только дополнительными фильтрами, выполняемыми для метода ресурса. Если есть какие-либо поставщики с привязкой к имени или глобальные поставщики, они все равно будут выполняться.

Дополнительные сведения см. В документации Джерси. про фильтры и перехватчики.