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.

[jzheaux]

After some additional research, @abimael-turing, this feature was reverted in f20ae1a for 6.3.x and onward.

As such, I'm going to close this issue. In general, annotations declared lower in the hierarchy do not affect methods higher in the hierarchy.