Hibernate 6.3 using custom provider_class with a datasource

I’m using a custom provider_class to set security on the jboss datasource. According to the documentation, provided_class should take precedence over datasource but looking at the ConnectionProviderInitiator inside the hibernate-core, it is looking for provider_class only when datasource is null.

It was working well until 6.2.6. My provider_class would extend DatasourceConnectionProverImpl to get the connection and set security. Should I be doing it differently now?

Hello @Sai, the DATASOURCE setting was given priority over CONNECTION_PROVIDER in this change, which was meant as an improvement to Hibernate’s test suite. If the change of behavior is impacting you, this might be considered a bug.

I’m wondering, however, why the DATASOURCE setting is set in your case, especially because that configuration property is now deprecated; if you want to use CONNECTION_PROVIDER, you should only set that one. Any particular reason why you (or the application server) are setting both properties?

Hello, application server (wildfly) is setting the “hibernate.connection.datasource” property since we have multiple datasources configured on the standalone.xml with different jndi-name. These used to get picked up by the DatasourceConnectionProviderImpl and we extended that from a provider_class to set security. We are setting the “hibernate.connection.provider_class” in persistence.xml so that custom connection provider is called for particular jta-data-source.

Now that the provider_class is not being called during deployment, the connection is being established with default machine security. I’m trying to avoid configuring all datasources in the code to bypass this. Thank you for the quick response.

Hello @mbladel, if it’s considered a bug, can we expect a code change to revert it to what it was? Is there anything I can do to expedite this? The Wildfly server update is blocked by this. Thanks!

Could you please open a bug report in our issue tracker? That way we will have an active report that you will be able to monitor for any updates. You can also just link to this conversation.

We should figure out why the change was necessary in the first place, and since this might be causing issues (like in your case) evaluate how to move forward.

Done, [HHH-17734] - Hibernate JIRA

Please share the persistence.xml that you’re using.


<persistence xmlns="https://jakarta.ee/xml/ns/persistence"
			 xsi:schemaLocation="https://jakarta.ee/xml/ns/persistence https://jakarta.ee/xml/ns/persistence/persistence_3_1.xsd"
	<persistence-unit name="TestProjectPU">
			<property name="hibernate.format_sql" value="true" />
            <property name="hibernate.dialect" value="com.testproject.data.jpa.TestProjectOracle11Dialect"/>
			<property name="hibernate.connection.handling_mode" value="DELAYED_ACQUISITION_AND_RELEASE_AFTER_STATEMENT"/>
			<property name="hibernate.connection.provider_disables_autocommit" value="true"/>
            <property name="hibernate.connection.provider_class"
				value="com.testproject.data.security.CustomConnectionProvider" />
      		<property name="hibernate.cache.use_second_level_cache" value="true"/>
      		<property name="hibernate.cache.use_query_cache" value="false"/>
            <property name="jakarta.persistence.validation.group.pre-persist"
            <property name="jakarta.persistence.validation.group.pre-update"
			<property name="hibernate.discriminator.force_in_select"

Thanks for sharing. We’ll look into that as part of HHH-17734