[jboss-jira] [JBoss JIRA] (WFLY-13617) Hibernate DataSourceBasedMultiTenantConnectionProviderImpl does not work for Multitenancy

[Rafael Sampaio (Jira)]

Rafael Sampaio created WFLY-13617:
-------------------------------------

             Summary: Hibernate DataSourceBasedMultiTenantConnectionProviderImpl does not work for Multitenancy
                 Key: WFLY-13617
                 URL: https://issues.redhat.com/browse/WFLY-13617
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
    Affects Versions: 20.0.0.Final, 19.1.0.Final
            Reporter: Rafael Sampaio
            Assignee: Scott Marlow


Hello All,

I was using o the DataSourceBasedMultiTenantConnectionProviderImpl contained in Hibernate lib to perform DATABASE MultitenancyType up to Wildfly 18.

Upgrading to version 19 (tested on 20 too), upon initialization of my application I get the error:

 
{noformat}
14:07:52,655 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.persistenceunit."web-5.0.0#appPU": org.jboss.msc.service.StartException in service jboss.persistenceunit."web-5.0.0#appPU": org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment]14:07:52,655 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.persistenceunit."web-5.0.0#appPU": org.jboss.msc.service.StartException in service jboss.persistenceunit."web-5.0.0#appPU": org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment] at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:198) at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:128) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:658) at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:212) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) at java.lang.Thread.run(Thread.java:748) at org.jboss.threads.JBossThread.run(JBossThread.java:485)Caused by: org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment] at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:275) at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:237) at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:214) at org.hibernate.id.factory.internal.DefaultIdentifierGeneratorFactory.injectServices(DefaultIdentifierGeneratorFactory.java:152) at org.hibernate.service.internal.AbstractServiceRegistryImpl.injectDependencies(AbstractServiceRegistryImpl.java:286) at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:243) at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:214) at org.hibernate.boot.internal.InFlightMetadataCollectorImpl.<init>(InFlightMetadataCollectorImpl.java:179) at org.hibernate.boot.model.process.spi.MetadataBuildingProcess.complete(MetadataBuildingProcess.java:119) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.metadata(EntityManagerFactoryBuilderImpl.java:1215) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:1246) at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:170) ... 9 more
Caused by: org.hibernate.HibernateException: Improper set up of DataSourceBasedMultiTenantConnectionProviderImpl at org.hibernate.engine.jdbc.connections.spi.DataSourceBasedMultiTenantConnectionProviderImpl.injectServices(DataSourceBasedMultiTenantConnectionProviderImpl.java:80) at org.hibernate.service.internal.AbstractServiceRegistryImpl.injectDependencies(AbstractServiceRegistryImpl.java:286) at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:243) at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:214) at org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator.buildJdbcConnectionAccess(JdbcEnvironmentInitiator.java:149) at org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator.initiateService(JdbcEnvironmentInitiator.java:66) at org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator.initiateService(JdbcEnvironmentInitiator.java:35) at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.initiateService(StandardServiceRegistryImpl.java:94) at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:263) ... 21 more{noformat}
The error happens inside this implementation:

 

 
{noformat}
public void injectServices(ServiceRegistryImplementor serviceRegistry) {
 final Object dataSourceConfigValue = serviceRegistry.getService( ConfigurationService.class )
   .getSettings()
   .get( AvailableSettings.DATASOURCE );
 if ( dataSourceConfigValue == null || ! String.class.isInstance( dataSourceConfigValue ) ) {
  throw new HibernateException( "Improper set up of DataSourceBasedMultiTenantConnectionProviderImpl" );
 }
...{noformat}
The changed behavior is that the the parameter is no longer a String, but a WildFlyDataSource.

 

I'm opening this case just to check if this is the expected behavior, and I should really override the necessary part of the code in order to circumvent the error or was this some sort of regression?

Kindly,

Rafael Sampaio

 



--
This message was sent by Atlassian Jira
(v7.13.8#713008)