The SecuredAuthorizationManager can now find @Secured annotations on …

[abimael-turing]

…subclasses when a method in the superclass is called.

closes the issue #15002

[abimael-turing]

@artem103 and @spring-projects-issues, I completed the pull request, but the build is failing on GitHub due to deprecated Gradle features, which are incompatible with Gradle 8.0.

[abimael-turing]

@artem103 and @spring-projects-issues, I completed the pull request, but the build is failing on GitHub due to deprecated Gradle features, which are incompatible with Gradle 8.0.

[rishiraj88]

@artem103 and @spring-projects-issues, I completed the pull request, but the build is failing on GitHub due to deprecated Gradle features, which are incompatible with Gradle 8.0.

@abimael-turing , how did you start this build- with 'gradlew' or 'gradle' executable directly? gradlew is well known to handle cross-version compatibility issues.

[abimael-turing]

@artem103 and @spring-projects-issues, I completed the pull request, but the build is failing on GitHub due to deprecated Gradle features, which are incompatible with Gradle 8.0.

@abimael-turing , how did you start this build- with 'gradlew' or 'gradle' executable directly? gradlew is well known to handle cross-version compatibility issues.

Hello @rishiraj88, just to clarify, I didn't initiate the build process myself. Instead, I opened a pull request on GitHub and requested a merge, which then triggered the build process. The error that occurred seems to be happening within Gradle on GitHub's end, rather than on my local computer. From what I can tell, it appears that GitHub is attempting to compile the code using outdated Gradle configurations, while simultaneously running a newer version of Gradle, which is causing compatibility issues to arise.

[jzheaux]

@abimael-turing, I'm not yet certain if we will be able to backport this to a maintenance version, however I've updated the branch so that it builds.

To more fully backport this behavior, will you please consider changing the PR to cherry-pick b0da37d instead? In this way, all the annotations will get the same benefit.

In the meantime, I'd like to see how the feature is received in 6.3 before merging.