Search code examples
jaxbjax-rsmoxyglassfish-4

How to specify and organize OXM_METADATA_SOURCE in glassfish v4 MOXy Provider?


I am a fan of both Glassfish and MOXy, and it's good news for me that MOXy had been bundled into Glassfish v4.

I had read and tried a few of MOXy examples on the internet, I like the dynamic OXM_META_DATA_SOURCE part, since while providing RESTful services, the "client perspective" is very flexible than domain classes.

So here is the problem:

Different RESTful services can have different views from same domain classes, and in my work it's very common case. So there can be a lot of binding OXM metadata files for every service. And as we know a single OXM metadata file can only correspond to a single java package. So there will be much more OXM metadata files to maintain.

Back to JAX-RS, Is there any framework to design patterns or best practices to finish the mapping between OXM metadata file set and the service itself?


Solution

  • You can try new feature called Entity Filtering which has been introduced in Jersey 2.3. Even though Entity Filtering is not based on OXM_META_DATA_SOURCE you can achieve your goal with it:

    Let's assume you have a following domain class (annotations are custom entity-filtering annotations):

    public class Project {
    
        private Long id;
    
        private String name;
    
        private String description;
    
        @ProjectDetailedView
        private List<Task> tasks;
    
        @ProjectAnotherDetailedView
        private List<User> users;
    
        // ...
    }
    

    And, of course, some JAX-RS resources, i.e.:

    @Path("projects")
    @Produces("application/json")
    public class ProjectsResource {
    
        @GET
        @Path("{id}")
        public Project getProject(@PathParam("id") final Long id) {
            return ...;
        }
    
        // ...
    }
    

    Now, we have 2 detailed views defined on domain class (via annotations) and the resource class. If you annotate getProject resource method with:

    • @ProjectDetailedView - returned entity would contain id, name, description AND a list of tasks from Project
    • @ProjectAnotherDetailedView - returned entity would contain id, name, description AND a list of users from Project

    If you leave the resource method un-annotated the resulting entity would contain only: id, name, description.

    You can find more information about Entity Filtering in the User Guide or you can directly try it in our example: entity-filtering.

    Note 1: Entity Filtering works only with JSON media type (via MOXy) at the moment. Support for other media types / providers is planned to be added in the future.

    Note 2: Jersey 2.3 is not integrated into any (promoted) build of GF 4.0. The next Jersey version that should be part of GF 4.0 is 2.4. We plan to release 2.4 in the next few weeks.