To override the resources automatically exported using manual controllers the controllers written have to consider certain aspects to make sure, they're not picked up by the standard Spring MVC handler mapping:
use @BasePathAwareController instead of @Controller or @RestController
not use @RequestMapping on the type level
DATAREST-566 Investigate overriding Spring Data REST entity endpoints while using Spring Security
Also, are you sure these are the things to do to integrate custom controllers? Using SDR 2.3, I have a @Controller that uses @RequestMapping on the type and method level to override a SDR search URL (repository method that just returns Strings) and it works fine. If I deviate from that, using @BasePathAwareController, and just a @RequestMapping on the method (whether including the base path or not), I only ever get "PersistentEntity must not be null!" which is what I get when I leave it to the SDR implementation
@BasePathAwareController is definitely needed to support moving the base URI of the REST endpoints. For example, if you configure the service to be served from /api, @BasePathAwareController takes the burden off of you to know this.
So far, my usage of the annotation was wrapped around a custom controller that fetched entities using the related Spring Data repository. I haven't tinkered with it returning something else
I made some tweaks and submitted it for review at https://github.com/thinkbigthings/DATAREST-535/pull/1. You don't have to commit it, but can instead use the PR to review my comments and feedback. In my PR, there is never a "PersistentyEntity must not be null" when invoking the injected repository's listProducers() call
Greg, thanks for experimenting with this! Since your changes fixed the problem I experimented with it some more, and found another clue.
When I make the recommended changes to use @BasePathAwareController and remove /api from the method @RequestMapping (leaving all else the same, including security) it uses the SDR implementation based on the repository method, ignoring the controller. From there, if all I do is remove the @PreAuthorize("isAuthenticated()") from the controller method, then it uses the custom controller implementation which is what we actually want. So I think @PreAuthorize and Spring Security is somehow interfering with @BasePathAwareController
I removed @PreAuthorize from the controller method in my original project, and applied @BasePathAwareController with modified path in the @RequestMapping, and my original project works as you would expect now. So that solves my problem, I guess I didn't need that @PreAuthorize there anyway given the overall security configuration.
Maybe in the context of this jira issue, mention not to use security annotations at the controller method level?