Is it possible to inject ResourceInfo into EntityProvider, such as MessageBodyReader and MessageBodyWriter?

Question

There is a requirement:

For each RESTful resource method, there is a set of OXM metadata file. I need to load those files while creating JAXBContext. So I need to know per-request ResourceInfo, and then mapping from some Annotation on the Resource Method, which can indicate which set of OXM metadata file should be loaded.

1. Is ResourceInfo per-request?
2. Can I obtain the Method (resource method) per request inside EntityProvider, such as MessageBodyReader and MessageBodyWriter?
3. Which do you prefer, OXM metadata between JPA Entity and XML/JSON or between TO and XML/JSON? Since I assume per service TO can customize the view of domain class to client.

Answer 1

I had similar problem. After several hours of research I got what I want by directly injecting provider capable to resolve resource method:

@Inject
Provider<RoutingContext> routingContextProvider;


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

Answer 2

After a few research and experiments, finally I made the breakthrough.

1. Is ResourceInfo per-request? [ANS] Yes, as documented in javadoc.

2. Can I obtain the Method (resource method) per request inside EntityProvider, such as MessageBodyReader and MessageBodyWriter? [ANS] There is a defect in JIRA which is very similar with this, it says that ResourceInfo cannot be injected into Filters, interceptors as found, maybe it will be fixed at some version for glassfish.jersey team.

3. Which do you prefer, OXM metadata between JPA Entity and XML/JSON or between TO and XML/JSON? Since I assume per service TO can customize the view of domain class to client. [ANS] Finally I decide to use TO other than JPA Entities as a concept of module exports. Because their development lifecycle are different, and there is also some restrictions to use JPA Entity with OXM. a. Development Lifecycle: TO is designed as exportable with interfaces to other modules or upper layer services, they are suppose to be determined while case designing phase according to requirement, and since it's delivered with interface, the content of TO should be relatively stable, changes should also follow versioning management. But entity design is much more flexible, and it changes time to time, those changes should be hide from the clients of this module, and sometime there is business logics inside. I know there are some company or architecture expose entities to other modules, or there is only 1 module, so it does not matter. But I choose to hide domain classes. b. While using JPA Entity exposing at service layer, then MOXy can be a good choice with providing Mapping JPA Entity and RESTful Entity body. Then due to some Lazy Loading requirement, ORM frameworks does some class transformation or byte code generation work implicitly, and some additional Lazy loading related fields will be loaded at runtime or generated at compile time, and those fields will lead some boring errors in MOXy while OXM using FIELD as accessor-type. You have to switch to PROPERTY mode or to define the god-know fields in your OXM metadata to hide them. Otherwise Getters and Setters had to be defined on JPA Entity class, which will lead to additional exposure.

And introduce TO will reduce the complexity of OXM work, much less metadata files will be used, with annotations on TO class, there can be zero OXM Metadata files, and I think OXM Metadata files are designed to integrate different systems other than connecting modules inside one system. So the answer is :

I PERFER TO than JPA Entities.