Feature regression : Spring Data REST controller must not use @RequestMapping on class level as this would cause double registration with Spring MVC

[yyvess]

On latest version @RequestMapping isn't more allowed at class level due to this change =>

46dc6e0

@RequestMapping is now only allowed on method level but that isn't an valid option for method on an abstract controller.

@RepositoryRestController
@RequestMapping("/api/widgets")
public class WidgetController  extends BaseControler {
    // ...
}

public class BaseControler {
    @GetMapping("/get")
    public ResponseEntity<String> get() {
        return ResponseEntity.ok().body(....);
    }
}

Proposition of fix =>

Add a field "path/value" on the annotation @RepositoryRestController to be able to set a root path at class level.

@RepositoryRestController("/api/widgets")
@RequiredArgsConstructor
public class WidgetController  extends BaseControler {
    // ...
}
public class BaseControler {
    @GetMapping("/get")
    public ResponseEntity<String> get() {
        return ResponseEntity.ok().body(....);
    }
}

Stackoverflow discussion =>
https://stackoverflow.com/questions/69825704/spring-data-rest-controller-must-not-use-requestmapping-on-class-level-as-this

[luvarqpp]

I was hit also by this change and moving request mapping into class level does behave differently than mapping on class level. There is perhaps involved some miss-configuration (or miss-use) of paths. My change on simple (showcase for this problematic update) project, which caused uri routing for my case to broke: luvarqpp/poc-springRequestMapping@5606c6e

[terje2001]

This issue is also blocking us from upgrading to 2.5.6 or later. We do use abstract controllers extensively and we know of no other work-around. Any chance we could get some movement on the associated pull request?

[odrotbohm]

We unfortunately cannot move back to the original arrangement as those declarations, in combination with how Spring MVC handles controllers in the 5.x generation, is effectively the reason for a CVE.

I'll review what it'd mean to support type level mappings on our very own @RepositoryRestController but the workaround for the 2.5.x branch is to move to path definitions on the individual method level. Reuse of common prefixes can be achieved through defining constants for the paths in use.

[sambernet]

We unfortunately cannot move back to the original arrangement as those declarations, in combination with how Spring MVC handles controllers in the 5.x generation, is effectively the reason for a CVE.

I'll review what it'd mean to support type level mappings on our very own @RepositoryRestController but the workaround for the 2.5.x branch is to move to path definitions on the individual method level. Reuse of common prefixes can be achieved through defining constants for the paths in use.

We're absolutely fine with not going back to the old solution, but we'd like to avoid having to just duplicating constant values from our abstract controller classes onto a load of methods (also increasing the risk of future additions ignoring or not adhering to the current base paths). That really feels like moving backwards.

We'd thus also gladly move to a new approach according to MR #2088. If we can help getting this forward in any way let us know.

[zampettim]

The fix in PR #2088 would work for us as we are running into this issue as well, and we have a tone of Abstract Controllers with a lot of methods. Duplicating all of the @RequestMappings and overriding all of the methods would be hundreds of developer hours to complete, and this seems like a simple solution.