db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Features of the JUnit test execution harness
Date Fri, 03 Feb 2006 16:56:02 GMT
Deepa Remesh wrote:
>>So I guess what you are saying is that if the test framework provides a
>>common mechanism to give a Connection to a derby database, it should go
>>through a DataSource, instead of using DriverManager ?
> I think we will need both mechanisms to get connection - using
> DataSource and DriverManager.
> J2ME/CDC/Foundation Profile is based on JSR169 for JDBC, which does
> not have java.sql.DriverManager class. So, here we need a mechanism to
> get a connection using javax.sql.DataSource.
> Using DataSource to get connection will not work in case of j9 vms
> (not foundation profile). In this case, database_enabler.jar is used
> for JDBC support and this does not have javax.sql.DataSource class.
> I'd appreciate if someone else familiar in this area can confirm this.

Correct, the other j9 profile is implementing the standard JDBC 2.1 api
and does not supply the optional JDBC 2.0 extensions which include
DataSource etc. Derby currently does support this environment and so the
test harness needs to as well.

In addition we will need to test getting connections from DriverManager,
so it needs to be supported in some way. Ideally the majority of tests
should be written to be indepedent of how a connection is obtained,
which is how it is today. Then all of the tests could be run with a
conneciton from a DataSource, the DriverManager, a Driver, a
PooledConnection or a XAConnection.


View raw message