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] Updated: (DERBY-2488) When loaded by jvm1.6 - EmbeddedConnectionPoolDataSource is not returning a JDBC 4 compliant PooledConnection object
Date Mon, 09 Apr 2007 22:03:33 GMT

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

A B updated DERBY-2488:

    Attachment: d2488_v3.stat

Attaching d2488_v3.patch, which is an attempt to implement Dan's suggested approach.  This
new approach is far cleaner than the original--so thank you to Dan for the great feedback.

While working on this I discovered that the ClientXADataSource class suffers from the same
problem as the Embedded classes, so I made similar changes there.  Note that the ClientConnectionPoolDataSource
file was already doing something very similar to what Dan had suggested for Embedded, except
that instead of using "Driver30" it uses "ClientDriver.getFactory()". So that particular data
source was working correctly even before my changes.  Given that, I have now updated the ClientXADataSource
class to match the behavior of ClientConnectionPoolDataSource.

This patch also includes a new test, jdbc4/JDBC4FromJDBC3DataSourceTest, which verifies that
JDBC 4 connections will be returned from JDBC 3 data sources if the JDK in use is JDK 1.6.
 I had to make some minor modifications to several classes in the junit/ directory, but hopefully
none of these is a problem.  In a clean trunk the new test shows 3 failures (the ClientConnectionPoolDataSource
test passes, as mentioned above); after applying d2488_v3.patch, the test runs cleanly.

I ran derbyall and suites.All on a SUSE Linux 10.0 machine and there were the following failures,
which also appear in the Tinderbox:

  - derbyall:   lang/grantRevokeDDL.sql
  - suites.All: GroupByExpressionTest.testMiscExpressions
  - suites.All: SecurityPolicyReloadingTest
  - suites.All: UpdateCursorTest.testVirtualMemoryHeap

There was also a failure in derbynet/testconnection.java, which does not show up in the tinderbox:

  < Unable to find host: ihave-inmyname.com.
  Test Failed.

When I ran this on my Windows 2000 laptop the diff was slightly different:

  9 del
  < Unable to find host: ihave-inmyname.com.
  > Could not connect to Derby Network Server on host ihave-inmyname.com, port 1527.

I did an "ant clobber" and rebuilt just to make sure, but the test still fails.  I then tried
running it on a clean, fully-synced client and it still failed (with the same diff).  So I
don't think this is related to my changes...

Review comments and any other feedback would be much appreciated, especially since (as I mentioned
earlier) this area of code is very new to me...

> When loaded by jvm1.6 - EmbeddedConnectionPoolDataSource is not returning a JDBC 4 compliant
PooledConnection object
> --------------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-2488
>                 URL: https://issues.apache.org/jira/browse/DERBY-2488
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions:
>         Environment: Run test using JVM 1.6
>            Reporter: Stan Bradbury
>         Assigned To: A B
>         Attachments: d2488_notTested_v1.patch, d2488_v2.patch, d2488_v3.patch, d2488_v3.stat,
showJDBCdsMetaDataLis.class, showJDBCdsMetaDataLis.class, showJDBCdsMetaDataLis.java, showJDBCdsMetaDataLis.java
> Updated the problem description to reflect the actual issue [Stan 4/5/07]:  EmbeddedConnectionPoolDataSource
is not returning a JDBC 4 compliant PooledConnection object
> 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: - (485682)
> Driver name:      Apache Derby Embedded JDBC Driver
> Driver version: - (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.

View raw message