Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <25409817.1175725892642.JavaMail.jira@brutus>
Date: Wed, 4 Apr 2007 15:31:32 -0700 (PDT)
From: "Daniel John Debrunner (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2488) When loaded by jvm1.6 - Derby JDBC
 3.0 driver returns 4 for JDBC driver major
In-Reply-To: <625502.1174934192128.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486796 ] 

Daniel John Debrunner commented on DERBY-2488:
----------------------------------------------

Your approach is what I was describing though I think there is a somewhat cleaner way that doesn't require reflection.

InternalDriver is the class that is the factory for all JDBC object, e.g. Connections, ResultSets etc. It has methods that return the correct level of JDBC object for a given JVM environment. This is because the specific version of InternalDriver is active in the JVM, e.g. Driver30 for JDBC 3.0 and Driver40 for JDBC 4.0.

So the first thought would be to add a getNewPooledConnection(...) and getNewXAConnection(...) to InternalDriver, and then have the various implementations return the correct type for their JDBC level, thus no reflection.

However, InternalDriver needs to work on JSR169 as it's the factory for objects there as well, and JSR169 does not support PooledConnection or XAConnection,
so the methods cannot be added there.

What could be done is to add the newPooledConnection(...) and newXAConnection(...)  methods to Driver30 and then have the data source use those methods to get the objects, e.g.


   ((Driver30) findDriver()).getNewPooledConnection(...);

That code would then work on JDBC 3.0 and JDBC 4.0 with no need for the 40 versions of the DataSource to have specific methods to get new objects, instead that code would be in Driver40.

   
> When loaded by jvm1.6 - Derby JDBC 3.0 driver returns 4 for JDBC driver major 
> ------------------------------------------------------------------------------
>
>                 Key: DERBY-2488
>                 URL: https://issues.apache.org/jira/browse/DERBY-2488
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.2.2.0
>         Environment: Run test using JVM 1.6
>            Reporter: Stan Bradbury
>         Attachments: d2488_notTested_v1.patch, d2488_v2.patch, showJDBCdsMetaDataLis.class, showJDBCdsMetaDataLis.class, showJDBCdsMetaDataLis.java, showJDBCdsMetaDataLis.java
>
>
> When loaded using JVM 1.6 the JDBC 3.0 data source (org.apache.derby.jdbc.EmbeddedConnectionPoolDataSource) is reporting a JDBC spec compliance level of 4.  The DatabaseMetaData.getJDBCMajorVersion method should return the
> correct spec compliance level (3) for the JDBC 3.0 data source.  The application server that relies on the reported spec compliance level to determine if a statement event listener should be registered will encounter a failure when  attemptting to register  an event listener with the JDBC 3.0 driver.
> Note that the JDBC 4.0 metadata call ..getMetaData().supportsStoredFunctionsUsingCallSyntax() is executed by the JDBC 3.0 driver.  This doesn't bother me but seems curious that this is supported by a JDBC 3.0 driver.
> Attached is a test case based on the test code from DERBY-8862 (JDBC 4 driver reports incorrect spec complieance level).
> Running the test:
> set JAVA_HOME to a 1.6 JVM
> Compile program
> run command:   ${JAVA_HOME}/java showJDBCdsMetaDataLis <path-to-database> 3.0 
> Using JAVA 6.0
> > "%JAVA_HOME%\bin\java" showJDBCdsMetaDataLis "c:\tstdb102" 3.0
>  . . JDBC 3 or less: Using jdbc.EmbeddedConnectionPoolDataSource
> Database product: Apache Derby
> Database version: 10.2.2.0 - (485682)
> Driver name:      Apache Derby Embedded JDBC Driver
> Driver version:   10.2.2.0 - (485682)
> JDBC driver major version: 4
> JDBC driver minor version: 0
> JDBC 4.0 metaData - SFusingCall: true
>  >> exception thrown:
> A non SQL error occured.
> java.lang.AbstractMethodError: org.apache.derby.jdbc.EmbedPooledConnection.addStatementEventListener(Ljavax/sql/Statemen
> tEventListener;)V
>         at showJDBCdsMetaDataLis.main(showJDBCdsMetaDataLis.java:103)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.