jersey
  1. jersey
  2. JERSEY-1004

Support resource interfaces by including implemented interfaces in ScanningResourceConfig's search for @Path annotations

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.12
    • Fix Version/s: 2.0-m09
    • Component/s: core
    • Labels:
      None

      Description

      It's sometimes quite handy to be able to split resources into an interface annotated as root resource and a concrete implementing class.
      As an example:

      package com.foo;
      
      import javax.ws.rs.GET;
      import javax.ws.rs.Path;
      
      
      @Path("/hello")
      public interface IHelloResource {
      
        @GET
        public String sayHello();
      
      }
      

      and

      package com.bar;
      
      public class HelloResourceImpl implements IHelloResource {
      
        @Override
        public String sayHello() {
      	return "Hello Jersey";
        }
      }
      

      This is working fine so long as you manually configure HelloResourceImpl as a root resource class, but using Jersey's otherwise so convenient PackagesResourceConfig to automatically scan in specific packages (say in this case com.bar) for resources will ignore HelloResourceImpl.
      ScanningResourceConfig only looks for @Path or @Provider annotations inside the actual classes themselves. While it is possible to overload the @Path annotation (or any other JAX RS annotation) in the concrete implementation, it kind of beats the purpose, scattering the resource configuration across multiple locations.

      It would be great if ScanningResourceConfig were to either look for some new type targeting annotation, such as @Resource, that could be used to manually annotate root resource classes even if they do not themselves have the @Path annotation. Better yet of course, would be to inspect all classes found in the specified resource packages more thoroughly and see not only if they implement @Path directly but whether they implement any interfaces which in turn are annotated with @Path.

        Issue Links

          Activity

          Hide
          Marek Potociar added a comment -

          Package scanning needs to be fixed to find also these resources, or the javadoc should be updated.

          Show
          Marek Potociar added a comment - Package scanning needs to be fixed to find also these resources, or the javadoc should be updated.
          Hide
          Martin Matula added a comment -

          I think we need to implement the following:
          1) scanning should never add a class that is not a resource (i.e. non-instantiable class) - this definitely needs to be fixed
          2) if feasible (from perf. perspective), scanning should look at inherited annotations (if no annotations declared directly on the inspected type)

          If we implement this, I think it should not matter where the superclass/interface that defines the annotation resides (only the location of the resource class itself should matter). I.e. I can put the interface into a package that is not scanned, and just have the resource class implementing the interface in the scanned package and it should work IMO. If I do include the interface in the same package, the scanning must not include the interface (based on bullet 1)) in the set of resources, just the class should be included. (e.g. in the current Jersey 2.0 snapshot even if I put annotations on the class itself, it fails, because the scanning still includes the interface as well, which is wrong).

          Show
          Martin Matula added a comment - I think we need to implement the following: 1) scanning should never add a class that is not a resource (i.e. non-instantiable class) - this definitely needs to be fixed 2) if feasible (from perf. perspective), scanning should look at inherited annotations (if no annotations declared directly on the inspected type) If we implement this, I think it should not matter where the superclass/interface that defines the annotation resides (only the location of the resource class itself should matter). I.e. I can put the interface into a package that is not scanned, and just have the resource class implementing the interface in the scanned package and it should work IMO. If I do include the interface in the same package, the scanning must not include the interface (based on bullet 1)) in the set of resources, just the class should be included. (e.g. in the current Jersey 2.0 snapshot even if I put annotations on the class itself, it fails, because the scanning still includes the interface as well, which is wrong).
          Hide
          Marek Potociar added a comment -

          We decided for performance reasons that during scanning the interfaces will be ignored. Also we fixed that Jersey will not try to instantiate interfaces.

          Show
          Marek Potociar added a comment - We decided for performance reasons that during scanning the interfaces will be ignored. Also we fixed that Jersey will not try to instantiate interfaces.
          Hide
          mumrah added a comment -

          Any chance of this getting back ported to 1.x?

          Show
          mumrah added a comment - Any chance of this getting back ported to 1.x?

            People

            • Assignee:
              Marek Potociar
              Reporter:
              Andreas Klein
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: