borinquenkid opened a new pull request, #16269: URL: https://github.com/apache/grails-core/pull/16269
## Summary - Fixes #16029: `@Configuration` classes registered in an application's `resources.groovy` (and `resources.xml`, and the application's own `doWithSpring`/`beanRegistrar()`) were no longer processed by a `ConfigurationClassPostProcessor` in 8.0.0-M3. - Root cause: `GrailsApplicationPostProcessor` (which drains those late-arriving beans) is discovered as an ordinary registry bean, so Spring always invokes it *after* its own `ConfigurationClassPostProcessor` has already completed its one and only pass over the registry. `CoreGrailsPlugin` used to unconditionally register a second processor that happened to catch this late content, but a later change made it stand down whenever Spring's own processor is already present — correct for the early plugin-registration phase, but wrong for this late phase, since Spring's processor has always already run there. - Fix registers a second `ConfigurationClassPostProcessor` at the end of `GrailsApplicationPostProcessor.postProcessBeanDefinitionRegistry`, after all late-phase beans are drained. Spring marks every bean definition a processor has already parsed, so this second pass only expands what's genuinely new; it's skipped under AOT, matching `CoreGrailsPlugin`'s existing guard. ## Test plan - [x] Added `LateConfigurationClassPostProcessorSpec`, which reproduces the exact bug shape and was confirmed to fail without the fix and pass with it. - [x] Full `grails-core` test suite green (1102 suites, 0 failures/errors). - [x] `./gradlew :grails-core:codeStyle` clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
