有一项要求：
对于每个RESTful资源方法，都有一组OXM元数据文件。我需要在创建JAXBContext时加载这些文件。所以我需要了解每个请求的ResourceInfo，然后从资源方法的一些Annotation进行映射，这可以指示应该加载哪个OXM元数据文件集。
答案 0 :(得分：0)
我可以在EntityProvider中的每个请求中获取Method（资源方法），例如MessageBodyReader和MessageBodyWriter吗？ [ANS] JIRA中存在一个与此非常相似的缺陷，它表示ResourceInfo无法注入到过滤器，拦截器中，可能会在某些版本中为glassfish.jersey团队修复。
您更喜欢哪种，JPA实体和XML / JSON之间或TO和XML / JSON之间的OXM元数据？由于我假设每个服务TO可以自定义域类到客户端的视图。 [ANS]最后，我决定使用除JPA实体之外的TO作为模块导出的概念。因为它们的开发生命周期不同，并且将JPA实体与OXM一起使用也存在一些限制。 一个。开发生命周期：TO被设计为可导出的，具有与其他模块或上层服务的接口，它们可以根据需要在案例设计阶段确定，并且由于它是通过接口提供的，因此TO的内容应该相对稳定，更改应该也遵循版本管理。但是实体设计更加灵活，并且它会不时地更改，这些更改应该隐藏在此模块的客户端之外，并且有时会出现业务逻辑。我知道有一些公司或架构将实体暴露给其他模块，或者只有一个模块，所以没关系。但我选择隐藏域类。 湾在服务层使用JPA Entity公开时，MOXy可以是提供Mapping JPA Entity和RESTful Entity主体的不错选择。然后由于一些延迟加载要求，ORM框架隐式地执行一些类转换或字节代码生成工作，并且一些额外的延迟加载相关字段将在运行时加载或在编译时生成，并且这些字段将导致MOXy中的一些无聊错误OXM使用FIELD作为访问器类型。您必须切换到PROPERTY模式或在OXM元数据中定义神知道字段以隐藏它们。否则必须在JPA实体类上定义Getters和Setter，这将导致额外的曝光。
引入TO将降低OXM工作的复杂性，更少使用元数据文件，在TO类上注释，可以有零OXM元数据文件，我认为OXM元数据文件旨在集成除了以外的不同系统连接一个系统内的模块。所以答案是：
I PERFER TO比JPA实体。
答案 1 :(得分：0)
我有类似的问题。经过几个小时的研究，我通过直接注入能够解析资源方法的提供者得到了我想要的东西：
@Inject
Provider<RoutingContext> routingContextProvider;
log.info("routing method == " + routingContextProvider.get().getResourceMethod());