{{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. |
|
