{{AbstractMultiTenantConnectionProvider}} has a minor bug in the unwrapping code.
{code:title=AbstractMultiTenantConnectionProvider.java}
@Override
public boolean isUnwrappableAs(Class unwrapType) {
return ConnectionProvider.class.equals( unwrapType ) ||
MultiTenantConnectionProvider.class.equals( unwrapType ) ||
AbstractMultiTenantConnectionProvider.class.isAssignableFrom( unwrapType );
}
@Override
@SuppressWarnings( {"unchecked"})
public <T> T unwrap(Class<T> unwrapType) {
if ( isUnwrappableAs( unwrapType ) ) {
return (T) this;
}
else {
throw new UnknownUnwrapTypeException( unwrapType );
}
}
{code}
The unwrap method fails when trying to unwrap to {{ConnectionProvider}}.
I would suggest removing {{ConnectionProvider.class.equals( unwrapType )}} from {{isUnwrappableAs}}, because it is ambiguous which connection provider should be unwrapped (anyConnectionProvider or connectionProvider for tenant (which tenant?)?).
The unwrap code in ` {{ DatasourceConnectionProviderImpl ` }} seems to be buggy, too:
For example the unwrap code checks, whether the unwrapType is assignable to a ` {{ DataSource ` }} . The condition ` {{ DataSource.class.isAssignableFrom( unwrapType ) ` }} is true for e. g. a ` {{ BasicDataSource ` }} (DBCP class). But the stored ` {{ DataSource ` }} could be a completely different implementation leading the ` {{ return (T) getDataSource() ` }} code to fail.
The same seems to be true for all ` {{ isAssignableFrom ` }} checks, because the subclass could be from another class hierarchy.
If my conclusion is correct, ` {{ AbstractDataSourceBasedMultiTenantConnectionProviderImpl ` }} , ` {{ DatasourceConnectionProviderImpl ` }} , ` {{ DriverManagerConnectionProviderImpl ` }} and ` {{ UserSuppliedConnectionProviderImpl ` }} are defective, too. |
|
