Пользовательская аннотация для метода JAX-RS и передачи параметров в метод JAX-RS от перехватчика - PullRequest
Новая
       65

Пользовательская аннотация для метода JAX-RS и передачи параметров в метод JAX-RS от перехватчика

0 голосов
/ 19 сентября 2018

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

Я хотел бы реализовать пользовательскую аннотацию @FilterResponse, чтобы аннотировать метод JAX-RS для фильтрации полей в ответе JSON.Для последних целей я использую механизм Джексона @JsonFilter.Идея состоит в том, чтобы включить использование точечной нотации для указания требуемых полей во всем графе объектов, начиная с возвращенной сущности в качестве корня.

Например, если у меня есть метод, который возвращает сущность Product, и я хочу вернуть только поле имени из поля Product и имя из связанной сущности CharacteristicValues ​​в Product, я сделаю что-то вроде этого ... 

@GET
@Produces("application/json")
@Path("/{pid}")
@FilterResponse(include = {"name", "characteristicValues.name"}, responseEntityClass = Product.class)
public Response get(@PathParam("pid") Integer pid) {
    Product result = productService.findSimpleProduct(pid);
    return Response.ok().entity((result)).build();

}

Под капотом, в реализации перехватчика для аннотации @FilterResponse, я выполняю все необходимые преобразования и настройку ObjectMapper.

Кроме того, внутри перехватчика я генерирую некоторые объекты, которые могут быть полезны в остальной части обработки запросов (в службах, в DAO и т. Д.), Поэтому Я хотел бы передать объекты, созданные в перехватчике (дляНапример, мой объект FieldTree создан из метаданных, указанных в аннотации @FilterResponse) для перехваченного метода JAX-RS ... И это моя проблема прямо сейчас.

ОБНОВЛЕНИЕ : Например,Переданный FieldTree может быть использован для восстановления JPA EntityGraph для извлечения только предпочтительных полей из базы данных.

Вот псевдокод перехватчика, чтобы проиллюстрировать идею ... 

@FilterResponse
@Interceptor
public class FilterResponseInterceptor {


@AroundInvoke
public Object intercept(InvocationContext context) throws Exception {

    List<String> fieldsToRetain = getIncludeListFromFilterResponseAnottationIn(context);

    FeildTree fieldTree = createFieldTreeFrom(fieldsToRetain);
    passFieldTreeToMethodInContext(fieldTree, context);

    Object response = context.proceed();

    return filteredResponseWithFields(response, fieldsToRetain);
}}

Когда япопробуйте объявить параметр, который я хочу передать перехваченному методу JAX-RS от перехватчика, как показано ниже ... 

@GET
@Produces("application/json")
@Path("/{pid}")
@FilterResponse(include = {"name", "characteristicValues.name"}, responseEntityClass = Product.class)
public Response get(@PathParam("pid") Integer pid, FieldTree requestedFieldTree) {
    Product result = productService.findSimpleProduct(pid);
    return Response.ok().entity((result)).build();

}

... Я получаю следующую ошибку ... 

RESTEASY002010: Failed to execute: javax.ws.rs.NotSupportedException: RESTEASY003200: Could not find message body reader for type: class app.fieldsfiltering.FieldTree of content type: */*

Есть ли способ заставить RESTEasy игнорировать некоторые параметры в методе JAX-RS или другой способ выполнить передачу параметров в перехваченный метод JAX-RS?

Извините за мойдлинный вопрос.

UPDATE2 : Некоторые пояснения к моей идее ... Я не упомянул, что хотел бы избежать "тривиальных" DTO, которые являются просто выбором некоторых полей из сущности доменабез изменения структуры.Итак ... EntityGraph, например, будет создан на уровне DAO или Service ... Но я чувствую, что «метаданные», необходимые для создания EntityGraph (например, предпочтительный граф полей или FieldTree, как я его назвал), должны быть помещены в метод JAX-RS,Зачем?В этом случае я передал бы FieldTree в служебную логику ... затем я бы создал соответствующий EntityGraph и охотно получил бы доменную сущность со всеми полями, определенными в FieldTree ... тогда я бы вернул доменную сущность методу JAX-RS и сохранил только поляопределено в FieldTree в ответе JSON, чтобы избежать исключения LazyInitialization, которое будет выдано, если Джексон попытается проанализировать некоторое ленивое поле в объекте сущности.

...