Возможно ли внедрить ResourceInfo в EntityProvider, например MessageBodyReader и MessageBodyWriter?

Question

Существует требование:

Для каждого ресурсного метода RESTful существует набор файлов метаданных OXM. Мне нужно загрузить эти файлы при создании JAXBContext. Поэтому мне нужно знать ресурс ResourceInfo по запросу и затем сопоставлять некоторые аннотации по методу ресурсов, которые могут указывать, какой набор файлов метаданных OXM должен быть загружен.

1. Является ResourceInfo по запросу?
2. Могу ли я получить метод (метод ресурсов) для каждого запроса внутри EntityProvider, например MessageBodyReader и MessageBodyWriter?
3. Что вы предпочитаете, метаданные OXM между JPA Entity и XML/JSON или между TO и XML/JSON? Поскольку я предполагаю, что за услугу TO может настроить представление класса домена на клиента.

Answer 1

У меня была аналогичная проблема. После нескольких часов исследований я получил то, что хочу от непосредственного поставщика инъекций, способного разрешить метод ресурсов:

@Inject 
Provider<RoutingContext> routingContextProvider; 


    log.info("routing method == " + routingContextProvider.get().getResourceMethod()); 

Answer 2

После нескольких исследований и экспериментов, наконец, я совершил прорыв.

1. Является ResourceInfo по запросу? [ANS] Да, как описано в javadoc.

2. Могу ли я получить метод (метод ресурсов) для каждого запроса внутри EntityProvider, например MessageBodyReader и MessageBodyWriter? [ANS] В JIRA есть дефект, который очень похож на это, он говорит, что ResourceInfo не может быть введен в фильтры, перехватчики, найденные, возможно, он будет исправлен в некоторой версии для команды glassfish.jersey.

3. Что вы предпочитаете, метаданные OXM между JPA Entity и XML/JSON или между TO и XML/JSON? Поскольку я предполагаю, что за услугу TO может настроить представление класса домена на клиента. [ANS] Наконец, я решил использовать TO, кроме JPA Entities, как концепцию экспорта модулей. Поскольку их жизненный цикл разработки отличается, а также существуют ограничения на использование JPA Entity с OXM. a. Жизненный цикл разработки: TO спроектирован как экспортируемый с интерфейсами к другим модулям или службам верхнего уровня, они должны быть определены на этапе проектирования случая в соответствии с требованиями, и поскольку он поставляется с интерфейсом, содержание TO должно быть относительно стабильным, изменения должны также следуют управлению версиями. Но дизайн сущностей гораздо более гибкий, и он время от времени меняется, эти изменения должны скрываться от клиентов этого модуля, а иногда внутри есть бизнес-логики. Я знаю, что какая-то компания или архитектура подвергает объекты другим модулям, или есть только 1 модуль, поэтому это не имеет значения. Но я предпочитаю скрывать классы домена. b. При использовании объекта JPA Entity на уровне обслуживания MOXy может быть хорошим выбором с предоставлением Mapping JPA Entity и тела RESTful Entity. Затем из-за некоторого требования к ленивой загрузке структуры ORM выполняют некое преобразование класса или генерации байтового кода, а некоторые дополнительные поля, связанные с загрузкой Lazy, будут загружаться во время выполнения или генерироваться во время компиляции, и эти поля будут приводить к некоторым скучным ошибкам в MOXy, тогда как OXM с использованием FIELD в качестве типа доступа. Вы должны переключиться на режим PROPERTY или определить поля, которые известны вам в ваших метаданных OXM, чтобы скрыть их. В противном случае Getters и Setters должны были быть определены в классе JPA Entity, что приведет к дополнительной экспозиции.

и представить уменьшит сложность ОХМ работы, будет использоваться гораздо меньше файлов метаданные с аннотациями на К классу, может быть нулевыми файлами ОХМЫ метаданных, и я думаю, что файлы ОХМЫ метаданные предназначены для интеграции разные системы, кроме соединительных модулей внутри одной системы. Таким образом, ответ:

I PERFER TO JPA Entities.