Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.2.1.6
    • Component/s: Test
    • Labels:
      None

      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).

      1. derby-398_2.diff
        74 kB
        Deepa Remesh
      2. derby-398_2.status
        10 kB
        Deepa Remesh
      3. derbyall_report_2.txt
        2 kB
        Deepa Remesh
      4. jdbcapi_lang_patch.diff
        83 kB
        Deepa Remesh
      5. jdbcapi_lang_patch.status
        3 kB
        Deepa Remesh
      6. jdk14_tests_3.diff
        393 kB
        Deepa Remesh
      7. jdk14_tests_3.status
        4 kB
        Deepa Remesh
      8. nullSQLText_patch.diff
        3 kB
        Deepa Remesh
      9. nullSQLText_patch.status
        0.4 kB
        Deepa Remesh
      10. parameterMapping_2.diff
        401 kB
        Deepa Remesh
      11. parameterMapping_2.status
        0.8 kB
        Deepa Remesh
      12. readme_patch.diff
        3 kB
        Deepa Remesh
      13. remove_j9foun_masters.diff
        105 kB
        Deepa Remesh
      14. remove_j9foun_masters.status
        2 kB
        Deepa Remesh
      15. store_patch.diff
        121 kB
        Deepa Remesh
      16. store_patch.status
        5 kB
        Deepa Remesh
      17. wisc_rename_patch.diff
        160 kB
        Deepa Remesh
      18. wisc_rename_patch.status
        0.3 kB
        Deepa Remesh
      19. wisconsin_patch.diff
        27 kB
        Deepa Remesh
      20. wisconsin_patch.status
        0.9 kB
        Deepa Remesh

        Activity

        Deepa Remesh created issue -
        Deepa Remesh made changes -
        Field Original Value New Value
        Assignee Deepa Remesh [ deepa ]
        Hide
        Deepa Remesh added a comment -

        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

        Show
        Deepa Remesh added a comment - 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
        Deepa Remesh made changes -
        Attachment derby-398.status [ 12311008 ]
        Attachment derby-398.diff [ 12311007 ]
        Attachment derbyall_report.txt [ 12311009 ]
        Hide
        Daniel John Debrunner added a comment -

        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

        Show
        Daniel John Debrunner added a comment - 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
        Hide
        Deepa Remesh added a comment -

        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

        Show
        Deepa Remesh added a comment - 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
        Deepa Remesh made changes -
        Attachment derby-398_2.diff [ 12311062 ]
        Attachment derby-398_2.status [ 12311063 ]
        Attachment derbyall_report_2.txt [ 12311064 ]
        Hide
        Daniel John Debrunner added a comment -

        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.

        Show
        Daniel John Debrunner added a comment - 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.
        Hide
        Daniel John Debrunner added a comment -

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

        Show
        Daniel John Debrunner added a comment - Committed revision 209515 to enable lang/floatypes and jdbcapi/metadata20 for J2ME/Foundation, based upon my earlier J2ME work.
        Hide
        Deepa Remesh added a comment -

        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

        Show
        Deepa Remesh added a comment - 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
        Hide
        Deepa Remesh added a comment -

        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.

        Show
        Deepa Remesh added a comment - 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.
        Deepa Remesh made changes -
        Attachment readme_patch.diff [ 12311981 ]
        Hide
        Kathey Marsden added a comment -

        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.

        Show
        Kathey Marsden added a comment - 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.
        Hide
        Deepa Remesh added a comment -

        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.

        Show
        Deepa Remesh added a comment - 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.
        Deepa Remesh made changes -
        Attachment nullSQLText_patch.diff [ 12320452 ]
        Attachment nullSQLText_patch.status [ 12320453 ]
        Hide
        Kathey Marsden added a comment -

        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

        Show
        Kathey Marsden added a comment - 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
        Hide
        Deepa Remesh added a comment -

        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.

        Show
        Deepa Remesh added a comment - 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.
        Deepa Remesh made changes -
        Attachment jdbcapi_lang_patch.diff [ 12320588 ]
        Attachment jdbcapi_lang_patch.status [ 12320589 ]
        Hide
        Kathey Marsden added a comment -

        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

        Show
        Kathey Marsden added a comment - 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
        Hide
        Deepa Remesh added a comment -

        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.

        Show
        Deepa Remesh added a comment - 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.
        Deepa Remesh made changes -
        Attachment store_patch.diff [ 12320913 ]
        Attachment store_patch.status [ 12320914 ]
        Hide
        Kathey Marsden added a comment -

        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.

        Show
        Kathey Marsden added a comment - 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 made changes -
        Attachment store_patch.diff [ 12320913 ]
        Deepa Remesh made changes -
        Attachment store_patch.status [ 12320914 ]
        Hide
        Deepa Remesh added a comment -

        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.

        Show
        Deepa Remesh added a comment - 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.
        Deepa Remesh made changes -
        Attachment store_patch.diff [ 12320918 ]
        Attachment store_patch.status [ 12320919 ]
        Hide
        Kathey Marsden added a comment -

        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

        Show
        Kathey Marsden added a comment - 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
        Hide
        Deepa Remesh added a comment -

        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.

        Show
        Deepa Remesh added a comment - 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 made changes -
        Attachment jdk14_tests.diff [ 12321540 ]
        Attachment jdk14_tests.status [ 12321541 ]
        Hide
        Deepa Remesh added a comment -

        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.

        Show
        Deepa Remesh added a comment - 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.
        Deepa Remesh made changes -
        Attachment wisconsin_patch.status [ 12321618 ]
        Attachment wisconsin_patch.diff [ 12321617 ]
        Hide
        Kathey Marsden added a comment -

        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.

        Show
        Kathey Marsden added a comment - 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.
        Hide
        Kathey Marsden added a comment -

        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

        Show
        Kathey Marsden added a comment - 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 made changes -
        Attachment jdk14_tests.diff [ 12321540 ]
        Hide
        Deepa Remesh added a comment -

        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.

        Show
        Deepa Remesh added a comment - 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 made changes -
        Attachment jdk14_tests_2.diff [ 12321827 ]
        Deepa Remesh made changes -
        Attachment jdk14_tests_2.diff [ 12321827 ]
        Deepa Remesh made changes -
        Attachment jdk14_tests.status [ 12321541 ]
        Hide
        Deepa Remesh added a comment -

        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.

        Show
        Deepa Remesh added a comment - 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.
        Deepa Remesh made changes -
        Attachment jdk14_tests_3.status [ 12322046 ]
        Attachment jdk14_tests_3.diff [ 12322045 ]
        Hide
        Kathey Marsden added a comment -

        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

        Show
        Kathey Marsden added a comment - 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
        Hide
        Deepa Remesh added a comment -

        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.

        Show
        Deepa Remesh added a comment - 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.
        Deepa Remesh made changes -
        Attachment wisc_rename_patch.status [ 12322098 ]
        Attachment wisc_rename_patch.diff [ 12322097 ]
        Hide
        Kathey Marsden added a comment -

        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

        Show
        Kathey Marsden added a comment - 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
        Hide
        Deepa Remesh added a comment -

        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.

        Show
        Deepa Remesh added a comment - 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.
        Deepa Remesh made changes -
        Attachment parameterMapping.status [ 12322286 ]
        Attachment parameterMapping.diff [ 12322285 ]
        Hide
        Kathey Marsden added a comment -

        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.

        Show
        Kathey Marsden added a comment - 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 made changes -
        Attachment parameterMapping.diff [ 12322285 ]
        Deepa Remesh made changes -
        Attachment parameterMapping.status [ 12322286 ]
        Hide
        Deepa Remesh added a comment -

        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.

        Show
        Deepa Remesh added a comment - 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.
        Deepa Remesh made changes -
        Attachment parameterMapping_2.status [ 12322325 ]
        Attachment parameterMapping_2.diff [ 12322324 ]
        Hide
        Kathey Marsden added a comment -

        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

        Show
        Kathey Marsden added a comment - 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
        Hide
        Deepa Remesh added a comment -

        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.

        Show
        Deepa Remesh added a comment - 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 made changes -
        Attachment remove_j9foun_masters.status [ 12322431 ]
        Attachment remove_j9foun_masters.diff [ 12322430 ]
        Hide
        Deepa Remesh added a comment -

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

        Show
        Deepa Remesh added a comment - Details of the current status of tests can be found at http://wiki.apache.org/db-derby/CdcTesting
        Deepa Remesh made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Fix Version/s 10.2.0.0 [ 11187 ]
        Deepa Remesh made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Hide
        Knut Anders Hatlen added a comment -

        This issue made the Wisconsin test stop using WiscVTI to populate the test tables, so WiscVTI.java and WiscMetaData.java are not in use anymore. I removed those two files in revision 1297395.

        Show
        Knut Anders Hatlen added a comment - This issue made the Wisconsin test stop using WiscVTI to populate the test tables, so WiscVTI.java and WiscMetaData.java are not in use anymore. I removed those two files in revision 1297395.
        Gavin made changes -
        Workflow jira [ 12321740 ] Default workflow, editable Closed status [ 12800563 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        345d 23h 57m 1 Deepa Remesh 10/Jun/06 03:20
        Resolved Resolved Closed Closed
        23s 1 Deepa Remesh 10/Jun/06 03:21

          People

          • Assignee:
            Deepa Remesh
            Reporter:
            Deepa Remesh
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development