Sanne Grinovero ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *created* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiYjdjMTY2Y2U3... ) / Task ( https://hibernate.atlassian.net/browse/HHH-16224?atlOrigin=eyJpIjoiYjdjMT... ) HHH-16224 ( https://hibernate.atlassian.net/browse/HHH-16224?atlOrigin=eyJpIjoiYjdjMT... ) Refactor discovery of exact JDBC drivers, avoid static state in specialized types ( https://hibernate.atlassian.net/browse/HHH-16224?atlOrigin=eyJpIjoiYjdjMT... ) Issue Type: Task Assignee: Unassigned Components: hibernate-core Created: 23/Feb/2023 06:32 AM Fix Versions: 6.wishlist Priority: Major Reporter: Sanne Grinovero ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) We need to re-think how JDBC drivers are detected to being “present” , as the current approach exposes a number of problems; I’m referring to, for example, https://github.com/hibernate/hibernate-orm/blob/f2deb8f58e990ee87b6e00a73... ( https://github.com/hibernate/hibernate-orm/blob/f2deb8f58e990ee87b6e00a73... ) and OracleArrayJdbcType is also an interesting examples as it shows some more design issues. But we need a general pattern, and these two types I’ve called out here are only examples of the issue I’m seeing; the pattern is rather wide-spread. * Hibernate Reactive (for example) will use the PostgreSQL Dialect, but won’t use PGJDBC; there is an enum PostgreSQLDriverKind but it’s not protecting things effectively - for example some of the custom types are still having their class initialized (by accident?) even when it’s not PGJDBC, triggering warnings. * The Hibernate ORM’s classloader won’t necessarily match the application classloader; most commonly in application servers the application will have access to the JDBC driver, but the ORM will not. It’s also possible that the ORM’s classloader is unique while there are multiple applications using it, each on a different classloader - some of which will have access to the driver and some might not. * The example of the OracleArrayJdbcType exposes another issue: reflection is not defined upfront during class initialization, but a lazy function is being defined. Ideally if we could ensure all such functions were computed during metadata & Dialect initialization that would be great; alternatively such code will need to emit some kind of event to trigger GraalVM metadata registrations. My suggestion would be to avoid storing such “presence flags” information in static, classloader bound state; especialy as the class definitions will be shared by multiple, different persistence units. Also, one needs to be careful in separating the notion of “the class can be loaded” from “we’re actually connecting using that driver”; the two concepts are easily conflated, as they will be in our typical integration tests, but they need to be handled strictly separately. For example it might be possible: * to load types from the driver as it’s accessible, but we’re using a different database * we’re using the matching database (e.g. it matches via DatabaseMetaData # getDriverName ), but the driver is not accessible An aspect of concern is that the mismatch driver access / metadata would require some craft with integration tests. Finally, since the pattern is rather wide-spread among a number of custom types, I wonder if we need some tooling help to spot such issues; e.g. reflective calls could theoretically be flagged by forbidden-apis, so to then specifically allow only the ones that have been vetted. ( https://hibernate.atlassian.net/browse/HHH-16224#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16224#add-comment?atlOrigin=ey... ) Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=Em... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100217- sha1:7bcbf31 )