2 Replies Latest reply on Aug 12, 2014 12:39 PM by scrublet

    JAX-RS Sub-resource Locator Issue from AS7 to Wildfly 8.1

    scrublet

      I'm not sure if I've found a bug, or if I'm unaware of a change or am doing something wrong. I have a couple layers of nested sub-resources, as follows:

       

      @Path("/rootResource")
      @Stateless
      public class MyRootResource {
      
           @EJB
           private SecondLayerResource injectedResource;
      
           @Path("/secondLayer")
           public SecondLayerResource getSecondLayer () {
                return injectedResource;
           }
      }
      

       

      @Stateless
      public class SecondLayerResource {
           @EJB
           private ThirdLayerResource injectedResource;
      
           @Path("/thirdLayerResource")
           public ThirdLayerResource getThirdLayer () {
                injectedResource.initialize();
                return injectedResource;
           }
      }
      

       

      @Stateless
      public class ThirdLayerResource {
      
           private SomeObject someObject;
      
           public void initialize() {
                List<SomeObject> dbList= getObjectListFromDatabase();
                if (dbList.isEmpty()) {
                     throw new WebApplicationException("There must be an object in the database to work on!");
                } else {
                     System.out.println("Look, we found a object! ------ " + dbList.get(0).getId());
                }
                this.someObject = dbList.get(0);
           }
      
           @POST
           @Consumes({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
           @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
           public Response createNewObject () {
                someObject.someMethod();
                // appropriate return code for Response
           }
      }
      

       

      The basic idea here is that the ThirdLayerResource gets what it needs before it is returned in the sub-resource locator. The problem is someObject exists in the initialize() method, but is null when used in the actual endpoint createNewObject() method. I have verified that the code works when deployed on AS7, but does not work when deployed on Wildfly.

       

      Basically, it appears that Resteasy is doing something differently in Wildfly between locating the sub-resource and using the sub-resource. Has anyone seen behavior like this? I can't find anything in the JAX-RS 2.0 specification or Resteasy documentation to suggest that sub-resources behave any differently.

        • 1. Re: JAX-RS Sub-resource Locator Issue from AS7 to Wildfly 8.1
          jaikiran

          That's a wrong use of *stateless* EJBs. You can't expect the state to be maintained in a stateless bean between business method invocations.

           

          To fix this, what you need to do is:

           

          1) Mark your initialize() method in the @Stateless bean with a @PostConstruct so that the EJB container will call it whenever a new instance of the bean is created:

           

           

          @Stateless  
          public class ThirdLayerResource {  
            
               private SomeObject someObject;  
            
               @PostConstruct
               public void initialize() {  
                  ...
               }  
          

           

          2) Do *not* explicitly call the initialize method. So remove the call to that method from your SecondLayerResource.getThirdLayer() method

          • 2. Re: JAX-RS Sub-resource Locator Issue from AS7 to Wildfly 8.1
            scrublet

            That was a stupid mistake on my part. The root of this mistake, and the reason I'm even using the EJBs to begin with, is an issue I'm having with trying to use ResourceContext.initResource in the subresource locator and THAT not working properly. But I'm redoing some architecture with the resources now anyways, and if that problem persists when I'm done I'll create a separate post specifically for ResourceContext rather than keep this post going.

             

            Thanks!