Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Aug 30, 2016 · 2 comments
Assignees
Labels
type: bug

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Aug 30, 2016

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:

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Aug 31, 2016

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Sep 1, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug
Projects
None yet
Development

No branches or pull requests

2 participants