[
https://issues.apache.org/jira/browse/DERBY-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492154
]
A B commented on DERBY-2582:
----------------------------
I can't say that I fully understand the issue, but from what I gather the
application in question is receiving some DataSource from somewhere and it (the
application) needs to figure out whether or not that DataSource object is JDBC
4. I assume the app itself is not the one creating the datasource (if it was
then it should theoretically know whether or not it instantiated the JDBC 4
Derby datasource class, shouldn't it?).
My inclination is to agree with Dan's comment above: "I think the only
compliance indicator in JDBC is on Driver and Derby's driver is JDBC 4.0
compliant, but it doesn't really have a direct relationship to DataSource
objects."
To me it seems odd to change Derby's connection objects to return a driver
version of 3 for DataSources even though the connection and the driver are both
JDBC 4.
One possible application-side workaround to this problem (if it's actually a
problem with Derby, of which I am not sure) is to use reflection on the data
source and then check the declared methods. Since
EmbeddedConnectionPoolDataSource40 is a public class that we expect users/apps
to be referencing directly, it seems like we should be able to suggest that
applications code according to the public javadoc for that class:
http://db.apache.org/derby/javadoc/engine/org/apache/derby/jdbc/EmbeddedConnectionPoolDataSource40.html
Notice that all of the Derby *40 data source classes declare two public
methods, both of which are required for JDBC 4:
public boolean isWrapperFor(Class<?> interfaces)
public <T> T unwrap(java.lang.Class<T> interfaces)
So if an application has some generic DataSource object and it wants to
determine whether or not that data source is JDBC 4, one possible approach is
to iterate through the declared methods and search for either of the above two.
If "ds" is some DataSource object, we could do something like:
boolean isJDBC4DataSource = false;
java.lang.reflect.Method [] mA = ds.getClass().getDeclaredMethods();
for (int i = 0; i < mA.length; i++)
{
String methodName = mA[i].getName();
if (methodName.equals("isWrapperFor") || methodName.equals("unwrap"))
{
isJDBC4DataSource = true;
break;
}
}
Maybe this is too naive of an approach, but when I tried it on a simple repro
it seems to have done the trick (i.e. isJDBC4DataSource remained false for the
JDBC 3 datasource but was set to true for the JDBC 4 datasources). For what
that's worth...
> EmbeddedConnectionPoolDataSource does not implement java.sql.Wrapper but
> reports JDBC 4 compliance when run with JDK 6
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2582
> URL: https://issues.apache.org/jira/browse/DERBY-2582
> Project: Derby
> Issue Type: Sub-task
> Components: JDBC
> Affects Versions: 10.2.2.1
> Environment: JDK 6
> Reporter: Stan Bradbury
>
> Software that checks the value returned by the dataseMetadata method
> getJDBCMajorVersion for JDBC compliance level and, based on the value, takes
> different paths in the code will fail unexpectedly accessing java.sql.Wrapper
> when loading EmbeddedConnectionPoolDataSource in a JDK 6 environment.
> EmbeddedConnectionPoolDataSource reports a compliance level of 4 when loaded
> in a JDK 6 environment. It returns JDBC 4 objects but the Datasource itself
> does NOT satify the JDBC 4.0 interface Wrapper and so, not being fully
> compliant, should not report JDBC 4 compliance.
> JSR 221 does not detail the behavior of the dataseMetadata method
> getJDBCMajorVersion but the description in Section 6.3, JDBC 4.0 API
> Compliance, states: "A driver that is compliant with the JDBC 4.0
> specification must .. Fully implement .. java.sql.Wrapper". As Dan stated in
> his comment on DERBY-2488,
> (http://issues.apache.org/jira/browse/DERBY-2488#action_12485033)
> EmbeddedConnectionPoolDataSource does not implement Wrapper.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
