jax-rs-spec
  1. jax-rs-spec
  2. JAX_RS_SPEC-72

Standardization of ResourceContext / Solution for Integration of manually created, stateful sub resources

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0
    • Component/s: None
    • Labels:
      None

      Description

      Sub resources are created inside the root resource using the "new" operator. CDI Dependency injection just cannot work in this case.

      The problem: access to Session Beans / CDI managed beans is only possible with a "lookup".

      Jersey uses a proprietary extension to to "manage" a custom created class:

      import com.sun.jersey.api.core.ResourceContext;
      
       @Context
        protected ResourceContext resourceContext;
      
      
       @Path("{customerId}/")
          public CustomerResource getCustomerResource(@PathParam("customerId")
          Integer id) {
              CustomerResource resource = resourceContext.getResource(CustomerResource.class);
              resource.setId(id);
              return resource;
          }
      

      [from NetBeans 7 Samples Java Web Services -> REST: CustomerDB Java EE 5]

      A ResourceContext should create and integrate the resource as a CDI managed bean. JAX-RS, as well as CDI injection should work in this case.

      Essential: the path param @PathParam("customerId") should be directly accessible in the sub-resource via field-injection.

      It means:

      public class CustomerResource {
      
        @PathParam("customerId")
         protected Integer id;
      }
      

        Issue Links

          Activity

          Hide
          Marek Potociar added a comment -

          A couple of clarifying questions:

          • What would be the suggested default scope of the sub-resources created by the context?
          • Who should be the "owner" of the created sub-resource instances? JAX-RS runtime or CDI?

          Let me also provide my take:

          • Instantiated sub-resources should live in the (JAX-RS) request scope.
          • Owner should be JAX-RS runtime.
          Show
          Marek Potociar added a comment - A couple of clarifying questions: What would be the suggested default scope of the sub-resources created by the context? Who should be the "owner" of the created sub-resource instances? JAX-RS runtime or CDI? Let me also provide my take: Instantiated sub-resources should live in the (JAX-RS) request scope. Owner should be JAX-RS runtime.
          Hide
          abien added a comment -

          > A couple of clarifying questions:
          >
          > * What would be the suggested default scope of the sub-resources created by the context?

          Dependent scope. The scope would depend on the scope of the main resource.

          > * Who should be the "owner" of the created sub-resource instances? JAX-RS runtime or CDI?

          It depends what the main resource is. In case it is a @Stateless, then EJB, CDI managed bean, then CDI. JAX-RS then JAX-RS.

          >
          > Let me also provide my take:
          >
          > * Instantiated sub-resources should live in the (JAX-RS) request scope.
          > * Owner should be JAX-RS runtime.

          o.k. But: usually in my projects (what is not representative) JAX-RS resources are in most cases @Stateless EJBs in Java EE deployments.
          >
          >
          >

          Show
          abien added a comment - > A couple of clarifying questions: > > * What would be the suggested default scope of the sub-resources created by the context? Dependent scope. The scope would depend on the scope of the main resource. > * Who should be the "owner" of the created sub-resource instances? JAX-RS runtime or CDI? It depends what the main resource is. In case it is a @Stateless, then EJB, CDI managed bean, then CDI. JAX-RS then JAX-RS. > > Let me also provide my take: > > * Instantiated sub-resources should live in the (JAX-RS) request scope. > * Owner should be JAX-RS runtime. o.k. But: usually in my projects (what is not representative) JAX-RS resources are in most cases @Stateless EJBs in Java EE deployments. > > >
          Hide
          Marek Potociar added a comment -

          All right. So I still think that the default scope should be request, provided the sub-resource is managed by JAX-RS runtime. For all sub-resources managed by another container (EJB, CDI...) the default scope would be as defined by the managing container. Obviously any explicitly specified scope would override the defaults.

          Show
          Marek Potociar added a comment - All right. So I still think that the default scope should be request, provided the sub-resource is managed by JAX-RS runtime. For all sub-resources managed by another container (EJB, CDI...) the default scope would be as defined by the managing container. Obviously any explicitly specified scope would override the defaults.
          Show
          Marek Potociar added a comment - Introduced ResourceContext API. See: http://java.net/projects/jax-rs-spec/sources/git/revision/d6a07ec69f2f0bae5c93f641247a0a493434f52b
          Hide
          patriot1burke added a comment -

          From a CDI perspective, I'm against this idea as there is already sufficient APIs in CDI:

          #1 CDI's BeanManager interface provides this functionality already
          #2 The Sub-resource locator itself could be an injected CDI bean.
          #3 Components needed by the sub-resource locator could be injected into the parent and passed in via a constructor or setter methods

          BUT...

          Resteasy does have something similar to access JAX-RS @Context injected things programmatically.

          Show
          patriot1burke added a comment - From a CDI perspective, I'm against this idea as there is already sufficient APIs in CDI: #1 CDI's BeanManager interface provides this functionality already #2 The Sub-resource locator itself could be an injected CDI bean. #3 Components needed by the sub-resource locator could be injected into the parent and passed in via a constructor or setter methods BUT... Resteasy does have something similar to access JAX-RS @Context injected things programmatically.
          Hide
          Marek Potociar added a comment -

          Please note that the duplicate issue has a larger scope than CDI or EJB injection. As such evaluate the issue in this larger context.

          Show
          Marek Potociar added a comment - Please note that the duplicate issue has a larger scope than CDI or EJB injection. As such evaluate the issue in this larger context.

            People

            • Assignee:
              Marek Potociar
              Reporter:
              abien
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: