RESTEasy
  1. RESTEasy
  2. RESTEASY-732

Subresource with unbound type parameter throws exception: Unable to resolve type variable

    Details

    • Type: Bug Bug
    • Status: Closed Closed (View Workflow)
    • Priority: Minor Minor
    • Resolution: Done
    • Affects Version/s: 2.3.3.Final
    • Fix Version/s: 3.0-beta-5
    • Component/s: jaxrs
    • Labels:
      None
    • Environment:
      Windows 7
    • Workaround Description:
      Hide

      Just add '{}' to end of object declaration so that resteasy can get at
      the generic type.

      @Override
      public SubImpl<Integer> getSub(String path)
      {
         return new SubImpl<Integer>(path){};
      }
      
      Show
      Just add '{}' to end of object declaration so that resteasy can get at the generic type. @Override public SubImpl< Integer > getSub( String path) { return new SubImpl< Integer >(path){}; }
    • Similar Issues:
      Show 10 results 

      Description

      org.jboss.resteasy.spi.UnhandledException: java.lang.RuntimeException: Unable to resolve type variable

      Testcase:

      public class ParameterizedSubResourceTest
      {
      private static Dispatcher dispatcher;

      @BeforeClass
      public static void before() throws Exception

      { dispatcher = EmbeddedContainer.start().getDispatcher(); dispatcher.getRegistry().addPerRequestResource(RootImpl.class); }

      @AfterClass
      public static void after() throws Exception

      { EmbeddedContainer.stop(); }

      public static interface Root
      {
      @Path("sub/

      {path}

      ")
      public Sub getSub(@PathParam("path") String path);
      }

      public static interface Sub

      { @GET @Produces("text/plain") public String get(); }

      public static interface InternalInterface<T extends Number>

      { @PUT void foo(T value); }

      @Path("/path")
      public static class RootImpl implements Root
      {
      @Override
      public SubImpl<Integer> getSub(String path)

      { return new SubImpl<Integer>(path); }

      }

      public static class SubImpl<T extends Number> implements Sub, InternalInterface<T>
      {
      private final String path;

      public SubImpl(String path)

      { this.path = path; }

      @Override
      public String get()

      { return "Boo! - " + path; }

      @Override
      public void foo(T value)

      { System.out.println("foo: " + value); }

      }

      @Test
      public void test()
      {
      ClientRequest request = new ClientRequest(generateURL("/path/sub/fred"));
      ClientResponse<String> response = null;
      try

      { response = request.get(String.class); Assert.assertEquals(HttpResponseCodes.SC_OK, response.getStatus()); Assert.assertEquals("Boo! - fred", response.getEntity()); }

      catch (Exception e)

      { throw new RuntimeException(e); }

      }
      }

        Activity

        Hide
        Peter Murray
        added a comment -

        The InternalInterface is interrogated for methods during the findAnnotatedIntefaceMethod() routine. This is true even if the @PUT annotation is removed from the InternalInterface method (which, I think, is the author's original intent). The problem is that the type variable T is not resolved because the type is never concretely bound in a specific subclass - it is erased entirely at runtime.

        I think the Types.getImplementingMethod should do something more robust if it encounters an unbound type variable. I have a fix and will submit a pull request. But it is a bit ugly.

        Should the type inference / navigation mechanism should be reconsidered as part of the new master branch development? It seems that some parameterized type information is currently left "on the table" during resource introspection that could serve users well if it was preserved.

        Show
        Peter Murray
        added a comment - The InternalInterface is interrogated for methods during the findAnnotatedIntefaceMethod() routine. This is true even if the @PUT annotation is removed from the InternalInterface method (which, I think, is the author's original intent). The problem is that the type variable T is not resolved because the type is never concretely bound in a specific subclass - it is erased entirely at runtime. I think the Types.getImplementingMethod should do something more robust if it encounters an unbound type variable. I have a fix and will submit a pull request. But it is a bit ugly. Should the type inference / navigation mechanism should be reconsidered as part of the new master branch development? It seems that some parameterized type information is currently left "on the table" during resource introspection that could serve users well if it was preserved.
        Hide
        Bill Burke
        added a comment -

        Not sure if this was broken prior to 3.0-beta-5 so I'll just close it. See the workaround to solve this issue.

        Show
        Bill Burke
        added a comment - Not sure if this was broken prior to 3.0-beta-5 so I'll just close it. See the workaround to solve this issue.

          People

          • Assignee:
            Bill Burke
            Reporter:
            Shane D
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: