Exclude tests for J2ME/CDC/Foundation platform

• Key: DERBY-398
• Type: Sub-task
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Deepa Remesh
• Reporter: Deepa Remesh
• Component/s: Test
• Fix Version/s: 10.2.1.6

Description

Exclude tests which use DriverManager, Driver or BigDecimal classes which are not in J2ME or JSR169. Ensure that derbyall can be run successfully in J2ME/CDC/Foundation platform using the JDBC Optional Package for CDC/Foundation Profile (JSR169).

Comments

[Deepa Remesh]

This patch excludes tests and suites which are expected to fail with J2ME CDC/Foundation Profile and JSR169. Here is a summary of the changes:

1. For each test to be excluded either one of the following is done:
* If <testname>_app.properties file does not exist, a new file is created with contents from default_app.properties for the test and the exclude condition "runwithfoundation=false".
* If <testname>_app.properties file exists, the exclude condition "runwithfoundation=false" is added to it.

2. For a suite to be excluded, either one of the following is done:
* If <testsuite>.properties file does not exist, a new file is created with the exclude condition "runwithfoundation=false".
* If <testsuite>.properties file exists, the exclude condition "runwithfoundation=false" is added to it.

3. The newly created <testname>_app.properties files are added to copyfiles.ant in the respective directories.

4. Readme.htm is modified with information to run tests using J2ME CDC/Foundation profile.

derbyall was run with IBM's WCTME5.7 j9 jvm foundation profile and JSR 169 implementation. Report is attached. The output of 'svn status' is in derby-398.status

I am looking at the excluded tests and working on changes which will enable some of these tests to run in this environment. I will be submitting this as ano ther sub-task.

Please review this patch and commit it.

Thanks,
Deepa

[Daniel John Debrunner]

I think for all the new files you've added (<test>_app.properties) to exclude tests for J2ME Foundation, the correct contents should be as below. Changes are

1) Comment that the tests are being excluded for J2ME/Foundation, not j9. J9 is a VM implementation by IBM,
whereas these tests are being excluded due to generic J2ME/Foundation restricitions.
(And there is a separate runwithj9 flag that does exclude tests specifically for the IBM J9 vm, but that is
not what you need here)

2) Even better would be a comment saying why they are excluded, e.g. test requires BigDecimal

3) The usedefaults flag means the contents of the default_app.properties file is picked up, which is what would happen before adding a new <test>_app.properties. This means those properties are not in multiple places now, so that if the default_app.properties need to be changed, it is not required to change all these other properties files.

Can you re-submit the patch?

-------------------------------------------------------------------------

#Exclude for J2ME/Foundation - test requires ???
runwithfoundation=false

usedefaults=true

[Deepa Remesh]

Hi Dan,

Thanks for looking into this patch. I have made the changes you suggested. I am looking into the reason for failure of some tests. I will be updating my comments and submitting this in another task.

The revised patch files are attached. Please look into this.

Thanks,
Deepa

[Daniel John Debrunner]

Committed revision 209470 (derby_398_2.diff)

With these changes and IBM's WCTME 5.7 in foundation mode I still get two failures running derbyall, but since this is a huge improvement over the previous state it's a very good incremental checkin.

derbyall/derbyall.fail:i18n/JapanCodeConversion.sql
derbyall/storeall/storeall.fail:unit/T_RawStoreFactory.unit

Also in my original J2ME work I had lang/floattypes.sql working, but I think I negelcted some test changes, so I will get that test working again.

[Daniel John Debrunner]

Committed revision 209515 to enable lang/floatypes and jdbcapi/metadata20 for J2ME/Foundation, based upon my earlier J2ME work.

[Deepa Remesh]

Hi Dan,

I ran derbyall with IBM's WCTME 5.7 foundation profile with the latest code from trunk. For me all tests pass. Can you please send me the diffs for the two tests (derbyall/derbyall.fail:i18n/JapanCodeConversion.sql and derbyall/storeall/storeall.fail:unit/T_RawStoreFactory.unit ) which failed for you?

Thanks,
Deepa

[Deepa Remesh]

This patch updates Section 2.1 and 4.9 of testing/README.htm.

1. The following jvms are added to list of supported jvms:
      j9_13 - WCTME jvm (available with IBM Websphere Studio Device Developer, 5.6), version 2.1 - class j9_13
      j9_22 - WCTME jvm (available with IBM Websphere Client Technology Micro Edition, 5.7), version 2.2 - class j9_22
      j9_foundation - WCTME jvm (available with IBM Websphere Client Technology Micro Edition, 5.7), version 2.2, foundation library - class j9_foundation

2. Following information about exclude flags for j9 jvms added to Section 4.9: "For j9 jvms, versioning does not apply currently. For all j9 versions, use runwithj9=false. For j9_foundation, use runwithfoundation=false."

Please review/commit this patch.

[Kathey Marsden]

committed to trunk

New Revision: 279429

URL: http://svn.apache.org/viewcvs?rev=279429&view=rev
Log:
DERBY-398 README.htm update
 This patch updates Section 2.1 and 4.9 of testing/README.htm.

[Deepa Remesh]

Attaching a patch for the test jdbcapi/nullSQLText.java. This test fails in J2ME because it uses a stored procedure with server-side JDBC. As I understand, the purpose of the test is only to test any stored procedure call. So I replaced the stored procedure in this test with a procedure in org.apache.derbyTesting.functionTests.util.ProcedureTest. Also changed the master files.

With this patch, I have run jdbcapi/nullSQLText.java in embedded, client and jcc frameworks. Also run this test in CDC/FP. This patch changes only tests. Please review/commit this patch.

[Kathey Marsden]

commieded nullSQLText.java changes.
Date: Thu Nov 3 20:58:01 2005
New Revision: 330705

URL: http://svn.apache.org/viewcvs?rev=330705&view=rev

[Deepa Remesh]

Attaching a patch 'jdbcapi_lang_patch.diff' for enabling some tests to run with J2ME/CDC/FP. Changes for each test are:
 
* jdbcapi/metadata.java and jdbcapi/odbc_metadata.java - Modified the tests to use ij.startJBMS to get connection. Modified metadata_test.java by adding catch block with 'NoSuchMethodError' around DatabaseMetaData.getURL because this method is not available in JSR169. Also, call to procedure with nested connection is not made when running with JSR169. Updated master files.
 
* jdbcapi/metaDataMultiConn.java - Commented out the line Class.forName("org.apache.derby.jdbc.EmbeddedDriver"); to allow the test to run with JSR169.
 
* jdbcapi/bestrowidentifier.sql - Added comment to _app.properties file to indicate reason for excluding - test uses procedure with nested connection for calling getBestRowIdentifier.
 
* jdbcapi/secureUsers1.sql - Added comment to _app.properties file to indicate reason for excluding - test requires ldap support which is not available with j9_foundation.
 
* lang/authorize.sql - Added comment to _app.properties file indicating excluded for now - test uses server-side JDBC. This test can be split to take out parts which can run with JSR169.
 
* lang/connect.sql - Added comment to _app.properties file indicating excluded for now - test uses ij 'driver' command. This test can be split to take out parts which can run with JSR169.
 
* lang/currentSchema.sql - Removed the protocol part from URLs in connect statement to make it work in J2ME. Also updated master file.
 
* lang/db2Compatibility.sql - Removed the protocol part from URLs in connect statement to make it work in J2ME. Also updated master file.
 
* lang/joindeadlock.sql - Removed the protocol part from URLs in connect statement to make it work in J2ME. Also updated master file.
 
* lang/errorCode.sql - Added comment to _app.properties file indicating excluded for now - test uses ij 'driver' command. This test can be split to take out parts which can run with JSR169.
 
* lang/GetPropertyInfoTest.java - Added comment to _app.properties file to indicate reason for excluding - test uses Driver.getPropertyInfo method.
 
* lang/maxMemPerTab.sql - Added comment to _app.properties file to indicate reason for excluding - test uses server-side JDBC.
 
* lang/nestedcommit.sql - Added comment to _app.properties file to indicate reason for excluding - test uses server-side JDBC.
 
Ran derbyall with Sun J2SE 1.4.2. Ran jdbcapi and derbylang suites with j9_foundation VM in IBM WCTME 5.7. No new failures. This patch modifies tests only. Please review/commit this patch.

[Kathey Marsden]

Commited the jdbcapi_lang_patch.

Date: Thu Nov 10 19:26:11 2005
New Revision: 332436

URL: http://svn.apache.org/viewcvs?rev=332436&view=rev

[Deepa Remesh]

Attaching a patch 'store_patch.diff' for enabling tests (mostly store tests) to run in J2ME. This patch does the following:
 
* i18n\urlLocale.sql, i18n\urlLocale_app.properties, urlLocale.out - Removed protocol name from URLs and added 'ij.protocol' to app_properties file so that test can run in J2ME. Updated master file.
* i18n\DefaultLocale.java - Removed lines to get nested connection from procedure methods since these connections were not used. This was causing failures with JSR169 where nested connections are not supported.
* i18n\iepnegativetests_ES_app.properties, iepnegativetests_ES.out - Added 'ij.protocol' to app_properties file so that test can run in J2ME. Updated master file.
* storetests\st_1_app.properties, storetests\st_schema_app.properties, storetests\st_b5772_app.properties, storetests\derby94_app.properties - Changed the property 'database' to 'ij.database' in st_schema_app.properties.
* tools\ij2_app.properties - Changed the property 'database' to 'ij.database' and added ij.dataSource properties.
* tools\ij4_app.properties - Added comment that this test has to be excluded since it is a test for a case with no default driver.
* tools\iepnegativetests_app.properties, tools\iepnegativetests.sql, iepnegativetests.out - Removed protocol name from URLs and added 'ij.protocol' to app_properties file so that test can run in J2ME. Updated master file.
* tools\ij_app.properties - Added comment that test is specific to ij and tests bad/good urls
* testRoutines.sql - To avoid using nested connection, directly called create procedures instead of calling a wrapper which will create the procedures.
* store\databaseProperties_app.properties, databaseProperties.out - Changed the master file to match change in testRoutines.sql
* TestUtil.java - Changed getDataSource method to handle case for EmbeddedSimpleDataSource. Added getDataSourceConnection method which takes a Properties object and returns a connection using the appropriate data source class. This method can be used to boot/shutdown Derby using DataSource.
* lang\errorStream_app.properties - This test works with changes to TestUtil.getDataSource method to handle case for EmbeddedSimpleDataSource.
* lang\logStream.java, lang\logStream_app.properties, logStream.out - Changed to call TestUtil.getDataSourceConnection instead of DriverManager.getConnection
* lang\functions_app.properties - Added comment that test is excluded for now since it uses server-side JDBC. This test can be converted to Java test to call only functions which do not use server-side JDBC in JSR169 environment.
* lang\releaseCompileLocks_app.properties - Added comment that test uses server-side JDBC
* store\backupRestore.sql, store\backupRestore_app.properties, backupRestore.out - Removed protocol name from URLs. Updated master file.
* store\removeStubs.sql, store\removeStubs_app.properties, removeStubs.out - Removed protocol name from URLs. Updated master file.
* store\rollForwardBackup_app.properties, store\rollForwardBackup.sql, rollForwardBackup.out - Removed protocol name from URLs. Updated master file.
* store\connectDisconnect_app.properties - This test works after changes for DERBY-597. So just re-enabled it.
* store\Beetle6038_app.properties - Added comment that this tests encryption which is not supported in Derby J2ME implementation
* store\TestDurabilityProperty.java, store\TestDurabilityProperty_app.properties - Changed to call TestUtil.getDataSourceConnection instead of DriverManager.getConnection
* store\backupRestore1.java, store\backupRestore1_app.properties - Changed to call TestUtil.getDataSourceConnection instead of DriverManager.getConnection
* store\MaxLogNumber_app.properties, store\MaxLogNumberRecovery_app.properties - Changed the property 'database' to 'ij.database' and added ij.dataSource properties.
* store\rollForwardRecovery.sql, store\rollForwardRecovery_app.properties, rollForwardRecovery.out - Removed protocol name from URLs. Updated master file.
* store\logDevice_app.properties - This test works after changes for DERBY-597. So just re-enabled it.
* lang\closed.java, lang\closed_app.properties - Added catch for NoSuchMethodError for DatabaseMetadata.getURL method. Skips 'shutDownTest' if it is JSR169. I think I can change this to use TestUtil.getDataSourceConnection for shutdown test. I noticed this when writing this down and so will submit this in my next patch.
* j9_foundation\closed.out - Added new master to handle DatabaseMetadata.getURL
* j9_foundation\ij2.out - Added new master because of difference in output of show connections in J2ME.

Ran derbyall with this patch using Sun JDK 1.4.2 and j9_foundation in IBM WCTME 5.7. No new failures. Please review/commit this patch.

[Kathey Marsden]

I could not apply this patch to the latest version but applied it to the checked out version for review. It looks good but it seems like it would be good to have a centralized method for shutting down the database from tests as it seemed those 4 or 5 lines of code are repeated in a lot of places. Please sync up and post a new patch and I will try to commit it quickly before there are conflicts.

[Deepa Remesh]

Thanks Kathey for looking at the patch and pointing out the repeated code for shutdown. I moved it to a method in TestUtil and changed 3 tests to use the new method. With this patch, I re-ran the changed tests and they passed.

[Kathey Marsden]

Committed this to the trunk

New Revision: 348593

URL: http://svn.apache.org/viewcvs?rev=348593&view=rev
Log:
DERBY-398 - Bring store tests into J2ME/CDC Foundation testing

[Deepa Remesh]

Attaching a patch 'jdk14_tests.diff' which adds jdk14 suite and some more tests to run with J2ME/CDC/FP. Changes are:

M java\tools\org\apache\derby\impl\tools\ij\mtTestCase.java

If ij.dataSource property is specified, remove ij.database and ij.protocol property. Similar to what is done by test harness. This is needed for stress.multi.

M java\testing\org\apache\derbyTesting\functionTests\tests\i18n\iepnegativetests_ES_app.properties
M java\testing\org\apache\derbyTesting\functionTests\multi\stress\init.properties
M java\testing\org\apache\derbyTesting\functionTests\multi\stress\run.properties

Change 'database' property to 'ij.database' and add ij.dataSource properties.

M java\testing\org\apache\derbyTesting\functionTests\tests\lang\holdCursorJava.java
M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\autoGeneratedJdbc30.java

Execute procedure tests only if DriverManager class is present.

A java\testing\org\apache\derbyTesting\functionTests\tests\lang\procedureJdbc30_app.properties
A java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\checkDataSource30_app.properties
M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\copyfiles.ant
M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\parameterMetaDataJdbc30_app.properties

These tests are part of jdk14 suite but cannot be run with JSR169.

M java\testing\org\apache\derbyTesting\functionTests\tests\lang\maxMemPerTab_app.properties
M java\testing\org\apache\derbyTesting\functionTests\tests\lang\triggerStream_app.properties
M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\LOBTest_app.properties
M java\testing\org\apache\derbyTesting\functionTests\tests\store\bootLock_app.properties

Removed 'runwithfoundation=false' exclude from these tests

M java\testing\org\apache\derbyTesting\functionTests\tests\lang\copyfiles.ant
D java\testing\org\apache\derbyTesting\functionTests\tests\lang\maxMemPerTab.sql
A java\testing\org\apache\derbyTesting\functionTests\tests\lang\triggerStream.java
A java\testing\org\apache\derbyTesting\functionTests\tests\lang\maxMemPerTab.java
D java\testing\org\apache\derbyTesting\functionTests\tests\lang\triggerStream.sql
M java\testing\org\apache\derbyTesting\functionTests\suites\derbylang.runall
M java\testing\org\apache\derbyTesting\functionTests\master\maxMemPerTab.out
M java\testing\org\apache\derbyTesting\functionTests\master\triggerStream.out
M java\testing\org\apache\derbyTesting\functionTests\util\StreamUtil.java
M java\testing\org\apache\derbyTesting\functionTests\util\ProcedureTest.java

maxMemPerTab and triggerStream tests are converted from sql to java to avoid using procedures with nested connections.

M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\dbMetaDataJdbc30.java
M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\resultsetJdbc30.java

NoSuchMethodError for methods not present in JSR169.

M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\users_app.properties

User and password are specified in databaseName itself so that they don't get re-used for other connections in the test

M java\testing\org\apache\derbyTesting\functionTests\tests\store\bootLock1.java
M java\testing\org\apache\derbyTesting\functionTests\tests\store\bootLock.java

Use Datasource instead of DriverManager

M java\testing\org\apache\derbyTesting\functionTests\harness\RunList.java
M java\testing\org\apache\derbyTesting\functionTests\suites\jdk14.properties

Change 'jdk14test' property to 'jdbc30test' property. Add check for jdb30test so that it can run with foundation vm.

M java\testing\org\apache\derbyTesting\functionTests\master\resultsetJdbc30.out

Small correction in the test and master.

A java\testing\org\apache\derbyTesting\functionTests\master\j9_foundation\iepnegativetests_ES.out

Added new master because of difference in output of show connections.

A java\testing\org\apache\derbyTesting\functionTests\master\j9_foundation\dbMetaDataJdbc30.out
A java\testing\org\apache\derbyTesting\functionTests\master\j9_foundation\LOBTest.out
A java\testing\org\apache\derbyTesting\functionTests\master\j9_foundation\autoGeneratedJdbc30.out
A java\testing\org\apache\derbyTesting\functionTests\master\j9_foundation\resultsetJdbc30.out
A java\testing\org\apache\derbyTesting\functionTests\master\j9_foundation\holdCursorJava.out
A java\testing\org\apache\derbyTesting\functionTests\master\j9_foundation\users.out

New masters for difference in behaviour in J2ME

M java\testing\org\apache\derbyTesting\functionTests\suites\jdk14.runall

Remove store/bootlock.java which is also part of store suite.

With this patch, I ran derbyall with Sun J2SE 1.4.2. No failures. Also ran derbyall with foundation VM in IBM WCTME 5.7. Some known failures:

derbyall/derbyall.fail:jdbcapi/metadata.java
derbyall/derbyall.fail:jdbcapi/odbc_metadata.java
derbyall/derbyall.fail:junitTests/lang/LangSuite.java
derbyall/derbyall.fail:i18n/JapanCodeConversion.sql
derbyall/storeall/storeall.fail:unit/T_RawStoreFactory.unit

I have couple of questions. I'd appreciate if anyone can answer these:

1. It is documented that triggers are not supported on this platform. But all trigger tests we have pass. The only test excluded now is lang/triggerGeneral.sql. This also passes with some changes to avoid using BigDecimal and nested connections. I have not included changes for this test in this patch. Is there any known case where triggers fail with CDC and jsr169? If not, I think this limitation can be removed.

2. I think it will be clearer to rename 'jdk14' suite to 'jdbc30' since these tests are for jdbc 3.0. If this is okay, I can make this change in my next patch.

Please review/commit this patch. Thanks.

[Deepa Remesh]

Attaching a patch 'wisconsin_patch.diff' for lang/wisconsin.sql test. Changes are:

* lang/wisconsin.sql test currenly does not work in J2ME environment because the test setup uses stored procedures with nested connection. To make this test run in this environment, I moved the setup (sql for table creation and inserts) to a Java class (wisconsin). From the Java class, the remaining sql is run using ij.
* Modified master files
* Modified the test name from wisconsin.sql to wisconsin.java in the runall and exclude files

Ran lang/wisconsin.java successfully using Sun JDK1.4.2 in all 3 frameworks and also with j9_foundation in IBM WCTME5.7. Please take a look at this patch. Thanks.

[Kathey Marsden]

Regarding jdk14_tests.diff, I could not apply to the latest trunk because RunList.java seems to have a recent update.

I applied the patch to the older version and it look ok but have a couple questions :

ij.database and ij.protocol being removed from the System.Properties. Where are they being set?
It seems it would be better to never set them than add and then removed later.

For the test harness there were changes made to RunList to change jdk14test to jdbc30 test.
We have another property runwith<jdk>=false that is used for some tests to disable running with jdk 1..3.1.
I wonder, would be better to just get rid of the jdk14test property all together and use runwithjdk13=false and
runwithibm13=false?

This is not a show stopper, just a thought. jdk14test always seemed like an odd property since it only works at the list level. I think it predates the runwith<jvm> property.

Please resubmit the patch after merging. I will try to pay quick attention to it so there are not merge conflicts.

[Kathey Marsden]

I checked in the wisconsin patch but think that wisconsin.sql should be renamed to something else to avoid confusion. It is fine that we now run wisconsin.java which calls a sql file , but I think it would be less confusing if wisconsin.sql went away so folks would not try to run it is a standalone test.

Could you submit another patch for this?

Thanks

Kathey

[Deepa Remesh]

Thanks Kathey for looking at the patches. I have attached 'jdk14_tests_2.diff' since the first patch had conflicts. With this patch, I successfully ran jdk14 suite in j2se and j2me. Answers to Kathey's questions:

1. "ij.database and ij.protocol being removed from the System.Properties. Where are they being set? It seems it would be better to never set them than add and then removed later."

These properties are needed to run the test when ij.dataSource is not set. startJBMS method uses these properties to get a connection. If these properties are not set and ij.dataSource property is set, it uses the ij.dataSource.* properties for the connection.

2. "For the test harness there were changes made to RunList to change jdk14test to jdbc30 test. We have another property runwith<jdk>=false that is used for some tests to disable running with jdk 1..3.1. I wonder, would be better to just get rid of the jdk14test property all together and use runwithjdk13=false and runwithibm13=false?"

I did not understand this question fully. I have renamed 'jdk14test' property to 'jdbc30test' since these tests are actually testing jdbc30 apis. With this patch, 'jdk14test' property is removed from harness. Maybe, the suite names are misleading. I can rename 'jdk14' suite to 'jdbc30'?

Please take a look at the new patch.

[Deepa Remesh]

Attaching 'jdk14_tests_3.diff' for Kathey's comments. I talked to Kathey who suggested to remove 'jdk14test' property from test harness. This patch makes that change. It also renames wisconsin.sql to wisc_setup.sql to avoid confusion.

Kathey, can you please take a look at the updated patch? Thanks.

[Kathey Marsden]

I committed this patch except the wisconsin changes. wisc_setup.sql was present in the status file but missing from the patch. I went ahead and checked the rest in so it would not get out of date. I ran lang/wisconsin.java and the jdk14 suite.

On the j9_foundation masters. I think that we can avoid having a j9_foundation master for some of the tests by doing some checking in the test for the correct behaviour. I think this would be especially good for the getURL calls in the metadata tests . Multiple masters can be a pain to maintain especially for the metadata tests.

Date: Tue Jan 17 21:43:13 2006
New Revision: 370059

URL: http://svn.apache.org/viewcvs?rev=370059&view=rev

[Deepa Remesh]

Attaching 'wisc_rename_patch.diff'. Test lang/wisconsin.java was failing in all frameworks because of missing info in previous diff file. With this new patch, I successfully ran lang/wisconsin.java in all 3 frameworks. Please commit this patch. Thanks.

[Kathey Marsden]

Checked in the patch to rename the wisconsin.sql file.
ran lang/wisconsin.java for all frameworks.

Date: Wed Jan 18 17:35:27 2006
New Revision: 370342

URL: http://svn.apache.org/viewcvs?rev=370342&view=rev
 

[Deepa Remesh]

Attaching a patch 'parameterMapping.diff' which changes the tests jdbcapi/parameterMapping.java and lang/updatableResultSet.java to run in J2ME/CDC/FP. Changes are:

* In parameterMapping.java, SQL types DECIMAL and NUMERIC are mapped to the String class in B3_GET_OBJECT for J2ME.
* When changing the tests, I have covered testing of SQL DECIMAL type. This is tested using wrapper methods in BigDecimalHandler which use get/setString methods for J2ME. I have not used the wrapper in cases where DECIMAL type is already being tested with get/set/updateXXX methods of other JDBC types.
* The tests work the same way as before in non-J2ME environments.
* In JSR169, get/setUnicodeStream methods are not present. NoSuchMethodError exception is used to handle these cases.
* New masters are needed for the tests. These are to account for absence of BigDecimal class in J2ME and methods which are not present in JSR169.

Ran both the changed tests using Sun JDK1.4.2 (all frameworks) and IBM WCTME 5.7 j9_foundation. Please look at this patch.

[Kathey Marsden]

Thanks Deepa for bringing these tests into J2ME

I think that maybe for ProcedureTest, instead of having a reduced copy ProcedureTest169, we should perhaps have a SimpleProcedureTest and then have ProcedureTest extend that to eliminate the duplicate code.

[Deepa Remesh]

Thanks Kathey. I have attached an updated patch 'parameterMapping_2.diff'. With the new patch, I ran the tests parameterMapping.java and updatableResultSet.java in all frameworks and J2ME.

[Kathey Marsden]

I checked in this parameterMapping_2.diff

Date: Thu Jan 26 19:06:10 2006
New Revision: 372708

URL: http://svn.apache.org/viewcvs?rev=372708&view=rev

Thanks for getting these tests running with J2ME.

I think in that in the future we can probably do more with parameterMapping to eliminate some of the J2ME specific branches. One thought is instead of having a totally separate initialization for B3_GET_OBJECT, you could have just a separate class.
if (HAVE_BIG_DECIMAL) {
    decimalClass = java.math.BigDecimal.class;
else
   decimalClass = java.lang.String.class;

Then just have a single initialization of B3_GET_OBJECT

[Deepa Remesh]

Thanks Kathey. I am uploading a cleanup patch 'remove_j9foun_masters.diff' which does the following:
* Removes four j9_foundation masters. Instead of printing the url returned by call to DatabaseMetaData.getURL, the tests now compare the output and print pass/fail to the master.
* Added a method compareURL to TestUtil which compares with expected URL based on framework.
* Modified master file for LOBTest
* Modified properties files for network server suites to add runwithfoundation=false. Unlike test properties, they only had runwithj9=false.

With this patch, I ran derbyall with Sun JDK1.4.2 on Windows XP. No failures. I also ran the changed tests on J2ME. Please look at this patch.

[Deepa Remesh]

Details of the current status of tests can be found at http://wiki.apache.org/db-derby/CdcTesting