codeconsole opened a new pull request, #15994: URL: https://github.com/apache/grails-core/pull/15994
### Summary Continues the migration of in-tree framework plugins off the deprecated `doWithSpring()` bean DSL onto the Spring `BeanRegistrar` API (deprecated by #15934), following the SiteMesh 3 (#15964) and scaffolding (#15966) conversions. Descriptors are now statically compiled where the remaining lifecycle hooks allow it. **17 descriptors converted:** | Conversion style | Plugins | |---|---| | Straight registrar (config reads move to the Spring `Environment`; constructor/property refs become supplier-context lookups) | async, cache, converters, datasource, dbmigration (hibernate5 + 7), domain-class, events, gorm-graphql, fields, layout, markup views, json views, rest-transforms, url-mappings | | Definitions post-processor (features `BeanRegistry` can't express) | controllers, interceptors, services, redis | ### Why some registrations need a post-processor Per-artefact controller/interceptor/service beans autowire **by name** and use **arbitrary scopes**; the redis pool beans need a **`destroy` method** and **dynamic property values**. None of these can be expressed through the `BeanRegistry.Spec` API, so their definitions move to dedicated `BeanDefinitionRegistryPostProcessor`s registered through `beanRegistrar()`. They run at `PriorityOrdered` highest precedence so their definitions are visible to Spring Boot auto-configuration conditions — the same visibility the `doWithSpring()` drain gave them — and an existing definition for a bean name always wins, so applications (or other plugins) can still override the beans. ### Behavioural parity notes - The interceptor handler adapter becomes the named bean `grailsInterceptorHandlerInterceptorAdapter` (previously an inner bean of the mapped interceptor) so its `@Autowired` members — most importantly the `Interceptor[]` — are still injected. - The converters error-marshaller registerers reference the existing named marshaller beans instead of duplicating them as inner beans, preserving the `ApplicationContextAware` callback. - `RedisConfigurationUtil` gains a `BeanDefinitionRegistry`-based `configureService` variant; the bean-builder closure form remains for existing consumers. - `GrailsUnitTest.defineBeans(plugin)` now also applies a plugin's `beanRegistrar()`, so test setup that passes converted plugin instances (converters, JSON views) keeps working. - The `chainedTransactionManagerPostProcessor` registration drops the unrefreshed-context `transactionManager` guard; the post-processor itself only acts when a `transactionManager` definition and multiple chainable managers exist. The `plugin` and `web-plugin` profile skeletons and the plugin-developer guide now show `beanRegistrar()` instead of the deprecated hook. ### Still on `doWithSpring()` (deferred to follow-up PRs) - `CoreGrailsPlugin` and `GroovyPagesGrailsPlugin` — abstract parent bean templates (`abstractGrailsResourceLocator`, `abstractViewResolver`) and an XML-namespace component-scan; the resolver-pipeline linchpin. - The hibernate5/7, mongodb and neo4j plugins — their datastore `SpringInitializer`s return bean-DSL closures, so conversion means reworking the initializers. - The spring-security suite — config-driven DSL throughout. ### Testing - New `*GrailsPluginSpec` / `*PostProcessorSpec` for every converted descriptor, exercising the registrar through `BeanRegistryAdapter`. - Every touched module's test suite passes, plus `grails-test-suite-web`, `-uber` and `-persistence` (the full-lifecycle consumers of these plugins). - `./gradlew codeStyle` and `./gradlew clean aggregateViolations` are clean across all four analysers (Checkstyle, CodeNarc, PMD, SpotBugs). -- 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]
