jdaugherty commented on code in PR #16094:
URL: https://github.com/apache/grails-core/pull/16094#discussion_r3776026408
##########
grails-core/src/main/groovy/org/grails/plugins/CoreGrailsPlugin.groovy:
##########
@@ -189,7 +237,12 @@ class CoreGrailsPlugin extends Plugin {
}
}
- registry.registerBean('proxyHandler', DefaultProxyHandler)
+ // The GORM implementations register a proxy handler that knows
how to unwrap their own
+ // proxies; this is the one for an application that has none.
Registering it over theirs
+ // left a Hibernate application unwrapping Hibernate proxies with
the general case.
+ if (!hasBeanDefinition(application, 'proxyHandler')) {
Review Comment:
This is a real bug fix (GORM's `proxyHandler` was being clobbered), but it
is unrelated to AOT and it changes runtime behaviour for every
Hibernate/Mongo/Neo4j application, not just AOT ones. It deserves its own PR
and its own regression test asserting that a Hibernate context ends up with the
Hibernate proxy handler.
Two further concerns with the mechanism:
- `hasBeanDefinition` consults `application.mainContext`, not the
`BeanRegistry` being written to. The javadoc on
`hasConfigurationClassPostProcessor` even describes the case where those differ
("a test slice registering this plugin's beans on a bare registry") — in that
case the check answers about the wrong object. If `BeanRegistry` genuinely
can't be queried, that limitation should be stated explicitly here rather than
in the sibling method.
- If `mainContext` is null or not a `ConfigurableApplicationContext` the
method returns `false` and registers anyway, so the fix silently degrades to
the old behaviour. Is `mainContext` guaranteed to be set by the time registrars
run?
--
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]
