ResourceProcessor is not invoked if RepositoryEntityController does not return a subtype of Resources [DATAREST-881]

[spring-projects-issues]

Matthew Borger opened DATAREST-881 and commented

There is a regression from SDR 2.4 to 2.5 where ResourceProcessors are not invoked for CrudRepositories but are invoked for JpaRepositories. I have provided an example project with tests. You can switch between Spring Boot 1.3 and 1.4 in the build script.

We think we traced the issue down to line 154 in ResourceProcessorHandlerMethodReturnValueHandler where it checks if Resources can be assigned from the targetType. It appears that in the CrudRepository case, where findAll returns a Resources<T>, the isAssignableFrom implementation from Spring Core is returning false where as in the JpaRepository case findAll returns a PagedResources<T> and isAssignableFrom returns true. I feel like both of these scenarios should return true for the ResourceProcessor logic to work as expected

---

Affects: 2.5.2 (Hopper SR2)

Attachments:

• resource-processor-test.zip (56.21 kB)

Issue Links:

• SPR-14648 ResolvableType for a raw type is not assignable to generic types of the same class
  ("depends on")

Backported to: 2.5.3 (Hopper SR3)

[spring-projects-issues]

Oliver Drotbohm commented

Looks like this is caused by a bug in Spring's ResolvableType and that hasn't been unveiled yet as the tests for ResourceProcessorHandlerMethodReturnValueHandler haven't been strict enough. Tightening those unveiled a couple more tiny issues I'll fix for that ticket.

[spring-projects-issues]

Oliver Drotbohm commented

I've filed a ticket and pushed a fix for the problem in Spring HATEOAS as we've moved the affected types to it and use them from current master (Ingalls). I've also applied those fixes to the classes residing in Spring Data REST for the Hopper maintenance branch.

Note however that these fixes will require Spring Framework 4.2.8 (Hopper) or 4.3.3 (Ingalls) to work. The fix is currently only available in snapshots. We will upgrade to those release versions once Spring Framework has shipped those fixes in releases itself