Merge 7.x (with spring security / mail / redis ) into 8.x

[jdaugherty]

The 7.x spring security / mail / redis merge was done against the 7.x grails-core branch. This PR merges 7.2.x to 8.x while also pulling in the changes made by @matrei in the 8.x spring security branch to support Grails 8.

Please note: groovy 5 has been merged into grails-core so as part of this merge, I had to fix the spring security code to be compatible with Groovy 5. I opened https://issues.apache.org/jira/browse/GROOVY-12134 after finding a @Delegate bug involving final methods.

Note There appear to be numerous hibernate/groovy 5 issues exposed by this merge. These plugins were not previously updated for these newer libraries. More work will need to be done on this PR so we can merge (and fix these plugins)

[jdaugherty]

The @Delegate fix did not suffice. It seems the wrapped delegate was still null. I'm not sure how it was set originally - likely in groovy? I added an explicit assignment to work around this for now. We probably should at least understand why that issue exists.

[jdaugherty]

This is all I can work on for now, if anyone has time to look into these issues, it would be appreciated:

1. why the @Delegate change required an assignment addition (is this an intentional groovy 5 change?)
2. why the hibernate domain object is unwrapping accessing .id only.

[jdaugherty]

The subsequent failures may still related to the @Delegate change, so there's likely more to do there.

[jdaugherty]

The params are fixed locally. I'm hopeful only the hibernate issue remains.

[jdaugherty]

I figured out the cause for all of these and will push fixes later today.

[jdaugherty]

The last issue is the proxy issue found by the redis test. I'm researching this more.

[jdaugherty]

It was only by side effect that I caught the proxy issues. I'm going to fix the Redis test by just switching the @Rollback to the grails one, which will have a session. I'll address the proxy issue in a separate PR since it's a behavior change.

[jdaugherty]

#15841 is the PR for the hibernate proxy change that this PR found.

[jdaugherty]

@jamesfredley I removed the opt-in for atCheckWaiting and included it by default on this PR. this should resolve a lot of the flaky test behavior you've seen.

[testlens-app]

🚨 TestLens detected 1 failed test 🚨

Here is what you can do:

1. Inspect the test failures carefully.
2. If you are convinced that some of the tests are flaky, you can mute them below.
3. Finally, trigger a rerun by checking the rerun checkbox.

Test Summary

SiteMesh 2 Compatibility / SiteMesh 2 Functional Tests (Java 21, indy=false) > :grails-test-examples-spring-security-ui-extended:integrationTest

Test	Runs
ExtendedSecurityInfoSpec > testConfig	❌

🏷️ Commit: 16c0472
▶️ Tests: 47704 executed
🟡 Checks: 53/56 completed

Test Failures

ExtendedSecurityInfoSpec > testConfig (:grails-test-examples-spring-security-ui-extended:integrationTest in SiteMesh 2 Compatibility / SiteMesh 2 Functional Tests (Java 21, indy=false))

Condition not satisfied:

contains('Showing 1 to 10 of ')
|
false

	at extended.spec.ExtendedSecurityInfoSpec.testConfig_closure1(ExtendedSecurityInfoSpec.groovy:41)
	at spock.lang.Specification.with(Specification.java:208)
	at extended.spec.ExtendedSecurityInfoSpec.testConfig(ExtendedSecurityInfoSpec.groovy:38)

Muted Tests

Note

Checks are currently running using the configuration below.

Select tests to mute in this pull request:

🔲 ExtendedSecurityInfoSpec > testConfig

Reuse successful test results:

🔲 ♻️ Only rerun the tests that failed or were muted before

Click the checkbox to trigger a rerun:

🔲 Rerun jobs

---

Learn more about TestLens at testlens.app.