db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Korneliussen <Andreas.Kornelius...@Sun.COM>
Subject Re: junit tests; get*DataSource* methods in BaseJDBCTestCase causing trouble...
Date Fri, 26 May 2006 11:07:18 GMT
Knut Anders Hatlen wrote:
> Myrna van Lunteren <m.v.lunteren@gmail.com> writes:
> 
>> Hi,
>> With revision 389780 some methods were added into BaseJDBCTestCase.java:
>> "DERBY-1157: Helper methods in BaseJDBCTestCase for creating data sources
>>
>> Adding getDataSource(), getConnectionPoolDataSource() and
>> getXADataSource() to BaseJDBCTestCase. The new methods call various
>> methods in TestUtil for creating the data sources. A minor adjustment
>> had to be made to TestUtil.getDataSource() in order to make it return
>> JDBC 4.0 DataSources."
>>
>> However, this causes trouble with the j9 jvms. So, I need to move
>> these methods back out of BaseJDBCTestCase.
> 
> Out of curiosity, what kind of trouble is it causing? If the method
> signatures cause trouble when the class is loaded, why isn't that the
> case for TestUtil?
> 

Maybe because the methods are not called, and no instance of TestUtil is 
  created (we do create instances of subclasses of BaseJDBCTestCase).

NoClassDefFoundError:
Thrown if the Java Virtual Machine or a ClassLoader instance tries to 
load in the definition of a class (as part of a normal method call or as 
part of creating a new instance using the new expression) and no 
definition of the class could be found.

> The methods don't add significant value, so I think it's OK to remove
> them from BaseJDBCTestCase and let the JUnit tests use the
> corresponding methods in TestUtil instead. If it is possible, we
> should try to keep getDefaultDataSourceProperties().
> 
I think getDefaultDataSourceProperties() could go into TestConfiguration.

What if you want to use them from a TestSetup ? Then you need to call 
BaseJDBCTestCase.getDefaultDataSourceProperties() instead of 
TestConfiguration.getDefaultDataSourceProperties().  I think the second 
alternative is better.

Andreas

Mime
View raw message