The GitHub Actions job "Code Style" on grails-core.git/7.0.x-remove-EnableWebMvc has failed. Run started by GitHub user codeconsole (triggered by codeconsole).
Head commit for run: 966e83f2f84365f3356b0bf5655a969f37ff725d / Scott Murphy Heiberg <[email protected]> Retire grails-spring-security's own FormContentFilter; warn when parsing is disabled Now that Grails guarantees a servlet-level FormContentFilter for every servlet web application (Boot's OrderedFormContentFilter by default, the Grails fallback under @EnableWebMvc), it runs at order -9500 — ahead of the whole Spring Security chain (-100) — and wraps the request before the chain starts. So the plugin's own in-chain FormContentFilter (inserted at EXCEPTION_TRANSLATION_FILTER.order - 10) is redundant: the security filters already see the parsed parameters. It was only needed historically, when Grails 7 auto-injected @EnableWebMvc and no servlet-level form filter existed. - SpringSecurityCoreGrailsPlugin: drop the formContentFilter bean registration and its import (also removes a bean that Boot could otherwise auto-register on /*). - SpringSecurityUtils: drop the chain insertion. - SpringSecurityUtilsIntegrationSpec: update the chain assertions accordingly. The one config where nothing would then parse non-POST form bodies is an explicit spring.mvc.formcontent.filter.enabled=false. Rather than have the plugin silently re-add a filter there (ignoring the opt-out), GrailsFormContentFilterAutoConfiguration now logs a startup warning when the filter is disabled and none is present, so the consequence (PUT/PATCH/DELETE form bodies not parsed) is visible. Report URL: https://github.com/apache/grails-core/actions/runs/29029885743 With regards, GitHub Actions via GitBox
