jamesfredley commented on code in PR #15557:
URL: https://github.com/apache/grails-core/pull/15557#discussion_r3343251395
##########
grails-test-examples/hibernate5/grails-hibernate/grails-app/init/functional/tests/BootStrap.groovy:
##########
@@ -26,7 +26,8 @@ class BootStrap {
HibernateDatastore hibernateDatastore
def init = {
- assert
hibernateDatastore.connectionSources.defaultConnectionSource.settings.hibernate.getConfigClass()
== CustomHibernateMappingContextConfiguration
+ // TODO: Re-enable when hibernate.configClass setting works with
Groovy 5 configuration binding
Review Comment:
This is a genuine Groovy 5 config-binding gap, not a silent skip. The assert
verifies that `hibernate.configClass:
functional.tests.CustomHibernateMappingContextConfiguration` (from
`application.yml`) is bound through to `settings.hibernate.getConfigClass()`.
Under Groovy 5 that nested value isn't being propagated into the Hibernate
settings - it's the same `ConfigObject` / `NavigableMap` behaviour change
documented in upgrade-guide section 24.2 (a missing/late-bound nested key
reading back empty), surfacing in the String -> Class settings binding. The
application still boots and the BootStrap body (transaction + save) runs; only
the assertion on the bound `configClass` is disabled, with a TODO rather than
deleting it. I'd rather fix the settings binder properly than assert around it,
so I'll take that as a focused follow-up. If you'd prefer it fixed before this
merges I can prioritise the binder investigation - flagging it honestly here so
it isn't lost.
##########
grails-test-examples/hibernate5/grails-hibernate/grails-app/init/functional/tests/BootStrap.groovy:
##########
@@ -26,7 +26,8 @@ class BootStrap {
HibernateDatastore hibernateDatastore
def init = {
- assert
hibernateDatastore.connectionSources.defaultConnectionSource.settings.hibernate.getConfigClass()
== CustomHibernateMappingContextConfiguration
+ // TODO: Re-enable when hibernate.configClass setting works with
Groovy 5 configuration binding
Review Comment:
Fixed at the root rather than worked around.
Root cause: `hibernate.configClass` (a fully-qualified class-name String in
`application.yml`) is bound to the `Class configClass` property by GORM's
`ConfigurationBuilder`. That binding relied on a `Converter<String, Class>`
registered on the property resolver's `ConversionService`, and that converter
resolves the class with the framework class loader (`DatastoreUtils` /
`HibernateGrailsPlugin` use `getClass().getClassLoader()`). The framework class
loader cannot see an application-defined class such as
`functional.tests.CustomHibernateMappingContextConfiguration`, so the value
bound to `null`.
Fix: `ConfigurationBuilder` now resolves `Class`-typed settings natively via
`ClassUtils.forName(name, Thread.currentThread().contextClassLoader)` - using
the application class loader and independent of any registered converter. The
BootStrap assert is re-enabled.
Verification: two new specs in `HibernateConnectionSourceSettingsSpec`,
including one that builds the settings from a plain `StandardEnvironment` with
no `String->Class` converter registered. That spec reproduces the failure and
now passes (`:grails-data-hibernate5-core:test --tests
HibernateConnectionSourceSettingsSpec` - 3/3 green).
--
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]
