db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2582) EmbeddedConnectionPoolDataSource does not implement java.sql.Wrapper but reports JDBC 4 compliance when run with JDK 6
Date Thu, 26 Apr 2007 23:47:15 GMT

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


Mime
View raw message