[jira] Commented: (DERBY-2217) Convert upgrade tests to Junit
[ https://issues.apache.org/jira/browse/DERBY-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465358 ] Daniel John Debrunner commented on DERBY-2217: -- Current state. The test currently passes with these JVMs (running trunk against all old releases except the incubator 10.0 release) Sun JDK 1.4.2 Sun JDK 1.5 IBM SDK 1.5 With Java SE 6 the test fails, seems to find the classes for the new version when the old version is expected and successfully picked up by other JVMs. Most likely the test configuration is looking for the JDBC 4 data sources which don't exist in the old versions of Derby, thus they resolve to the current version. Probably need to force JDBC 3 data sources as the data source class to use if the old version is older than 10.2.2.0. With these two J2ME/CDC/Foundation JVMs the test hangs. IBM WCTME 5.7 IBM WEME 6.1 > Convert upgrade tests to Junit > -- > > Key: DERBY-2217 > URL: https://issues.apache.org/jira/browse/DERBY-2217 > Project: Derby > Issue Type: Improvement >Reporter: Daniel John Debrunner > Assigned To: Daniel John Debrunner >Priority: Minor > Fix For: 10.3.0.0 > > > Also support running against multiple old versions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-2233) junit test derbynet/PreparedStatementTest fails with wctme5.7 (aka j9 2.2/ foundation/j2ME 1.0) and weme6.1 (aka j9 2.3 / foundation/j2ME 1.1)
[ https://issues.apache.org/jira/browse/DERBY-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Myrna van Lunteren closed DERBY-2233. - > junit test derbynet/PreparedStatementTest fails with wctme5.7 (aka j9 2.2/ > foundation/j2ME 1.0) and weme6.1 (aka j9 2.3 / foundation/j2ME 1.1) > --- > > Key: DERBY-2233 > URL: https://issues.apache.org/jira/browse/DERBY-2233 > Project: Derby > Issue Type: Test > Environment: jvms wctme5.7 (aka j9 2.2/ foundation/j2ME 1.0) and > weme6.1 (aka j9 2.3 / foundation/j2ME 1.1) >Reporter: Myrna van Lunteren > Assigned To: Myrna van Lunteren > Fix For: 10.3.0.0 > > > The test derbynet/preparedStatementTest, recently (Jan 2, revision 491768) > converted to junit, fails with the CDC/Foundation/JSR169/J2ME implementation. > wctme5.7/j9 2.2/j2ME 1.0 shows: > --- > 1) > testParameterTypes(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoClassDefFoundError: > java.math.BigDecimal > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testParameterTypes(PrepareStatementTest.java:182) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:199) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > 2) > testBigDecimalSetObject(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoClassDefFoundError: > java.math.BigDecimal > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testBigDecimalSetObject(PrepareStatementTest.java:430) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:199) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > 3) > testBigDecimalSetObjectWithScale(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoClassDefFoundError: > java.math.BigDecimal > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testBigDecimalSetObjectWithScale(PrepareStatementTest.java:478) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:199) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > 4) > testSmallBigDecimal(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoClassDefFoundError: > java.math.BigDecimal > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testSmallBigDecimal(PrepareStatementTest.java:555) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:199) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > -- > weme6.1/j9 2.3/j2ME 1.1 shows: > -- > 1) > testParameterTypes(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoSuchMethodError: > java/sql/PreparedStatement.setBigDecimal(ILjava/math/BigDecimal;)V > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testParameterTypes(PrepareStatementTest.java:210) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:203) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > 2) > testBigDecimalSetObject(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.sql.SQLException: > An attempt was made to get a data value of type 'DOUBLE' from a data value > of type 'java.math.BigDecimal'. > at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown > Source) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at
[jira] Resolved: (DERBY-2233) junit test derbynet/PreparedStatementTest fails with wctme5.7 (aka j9 2.2/ foundation/j2ME 1.0) and weme6.1 (aka j9 2.3 / foundation/j2ME 1.1)
[ https://issues.apache.org/jira/browse/DERBY-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Myrna van Lunteren resolved DERBY-2233. --- Resolution: Fixed Fix Version/s: 10.3.0.0 committed check for JSR169 with revision http://svn.apache.org/viewvc?view=rev&revision=496911 > junit test derbynet/PreparedStatementTest fails with wctme5.7 (aka j9 2.2/ > foundation/j2ME 1.0) and weme6.1 (aka j9 2.3 / foundation/j2ME 1.1) > --- > > Key: DERBY-2233 > URL: https://issues.apache.org/jira/browse/DERBY-2233 > Project: Derby > Issue Type: Test > Environment: jvms wctme5.7 (aka j9 2.2/ foundation/j2ME 1.0) and > weme6.1 (aka j9 2.3 / foundation/j2ME 1.1) >Reporter: Myrna van Lunteren > Assigned To: Myrna van Lunteren > Fix For: 10.3.0.0 > > > The test derbynet/preparedStatementTest, recently (Jan 2, revision 491768) > converted to junit, fails with the CDC/Foundation/JSR169/J2ME implementation. > wctme5.7/j9 2.2/j2ME 1.0 shows: > --- > 1) > testParameterTypes(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoClassDefFoundError: > java.math.BigDecimal > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testParameterTypes(PrepareStatementTest.java:182) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:199) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > 2) > testBigDecimalSetObject(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoClassDefFoundError: > java.math.BigDecimal > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testBigDecimalSetObject(PrepareStatementTest.java:430) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:199) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > 3) > testBigDecimalSetObjectWithScale(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoClassDefFoundError: > java.math.BigDecimal > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testBigDecimalSetObjectWithScale(PrepareStatementTest.java:478) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:199) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > 4) > testSmallBigDecimal(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoClassDefFoundError: > java.math.BigDecimal > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testSmallBigDecimal(PrepareStatementTest.java:555) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:199) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > -- > weme6.1/j9 2.3/j2ME 1.1 shows: > -- > 1) > testParameterTypes(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoSuchMethodError: > java/sql/PreparedStatement.setBigDecimal(ILjava/math/BigDecimal;)V > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testParameterTypes(PrepareStatementTest.java:210) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:203) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > 2) > testBigDecimalSetObject(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.sql.SQLException: > An attempt was made to get a data value of type 'DOUBLE' from a data value > of type 'java.math.BigDecimal'. > at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown > Source)
[jira] Commented: (DERBY-2233) junit test derbynet/PreparedStatementTest fails with wctme5.7 (aka j9 2.2/ foundation/j2ME 1.0) and weme6.1 (aka j9 2.3 / foundation/j2ME 1.1)
[ https://issues.apache.org/jira/browse/DERBY-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465338 ] Myrna van Lunteren commented on DERBY-2233: --- Similarly to DERBY-2157, this test does not need to run with JSR169, because the client configuration is not supported. With jars, all that's needed is to ensure derbynet.jar and derbyclient.jar are not in the classpath, but this is not possible when running with classes. I worried about possibly missing some valuable testing, but the test has this in the comments: " This test tested prepared statements in client/server context, and many of the test cases is specifically testing corner cases in client/server communication." So, it appears ok to run only an empty suite for this test. > junit test derbynet/PreparedStatementTest fails with wctme5.7 (aka j9 2.2/ > foundation/j2ME 1.0) and weme6.1 (aka j9 2.3 / foundation/j2ME 1.1) > --- > > Key: DERBY-2233 > URL: https://issues.apache.org/jira/browse/DERBY-2233 > Project: Derby > Issue Type: Test > Environment: jvms wctme5.7 (aka j9 2.2/ foundation/j2ME 1.0) and > weme6.1 (aka j9 2.3 / foundation/j2ME 1.1) >Reporter: Myrna van Lunteren > Assigned To: Myrna van Lunteren > > The test derbynet/preparedStatementTest, recently (Jan 2, revision 491768) > converted to junit, fails with the CDC/Foundation/JSR169/J2ME implementation. > wctme5.7/j9 2.2/j2ME 1.0 shows: > --- > 1) > testParameterTypes(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoClassDefFoundError: > java.math.BigDecimal > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testParameterTypes(PrepareStatementTest.java:182) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:199) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > 2) > testBigDecimalSetObject(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoClassDefFoundError: > java.math.BigDecimal > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testBigDecimalSetObject(PrepareStatementTest.java:430) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:199) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > 3) > testBigDecimalSetObjectWithScale(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoClassDefFoundError: > java.math.BigDecimal > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testBigDecimalSetObjectWithScale(PrepareStatementTest.java:478) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:199) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > 4) > testSmallBigDecimal(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoClassDefFoundError: > java.math.BigDecimal > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testSmallBigDecimal(PrepareStatementTest.java:555) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:199) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > -- > weme6.1/j9 2.3/j2ME 1.1 shows: > -- > 1) > testParameterTypes(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoSuchMethodError: > java/sql/PreparedStatement.setBigDecimal(ILjava/math/BigDecimal;)V > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testParameterTypes(PrepareStatementTest.java:210) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:203) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at jun
[jira] Commented: (DERBY-2224) Test harness should support J2ME 1.1
[ https://issues.apache.org/jira/browse/DERBY-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465336 ] Myrna van Lunteren commented on DERBY-2224: --- added a patch that: - modifies org.apache.derby,iapi.tools.i18n.LocalizedResource to check for the ability to call ResultSet.getBigDecimal - updates master-canons with output with weme 6.1 for the following tests: - lang/grantRevokeDDL.sql - lang/floattypes.sql - lang/timestampArith.sql - changes the method org.apache.derby.tools.functionTests.util.BigDecimalHandler to check for ability to call ResultSet.getBigDecimal. If there are no further comments, I'd like to commit this... > Test harness should support J2ME 1.1 > > > Key: DERBY-2224 > URL: https://issues.apache.org/jira/browse/DERBY-2224 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.2.2.0, 10.3.0.0 >Reporter: Myrna van Lunteren > Assigned To: Myrna van Lunteren >Priority: Minor > Attachments: DERBY-2224_tests_20070116.diff, > DERBY-2224_tests_20070116.stat, DERBY_2224_harness.diff, DERBY_2224_tests.diff > > > I would like to enable the 'old' test harness to support the new version of > IBM's j2ME implementation, which is based on j2ME jdk spec version 1.1. This > is available with a product named Websphere Everyplace Micro Edition 6.1. > from IBM. > We already support j9_foundation, which matches to j2ME jdk spec 1.0. I'd > like to add j9_foundation11, which then matches to j2ME jdk spec 1.1. > I'm proposing to switch my automated tests over to the newer version going > forward, and to minimize complexity of the change, I'd like to make the > canons reflect behavior of the new version. The differences are minimal. > However, I want to be able to still run with the old (except where the > results differ, failures would occur with the old version). > One of the reasons for moving to the new version is that there is a bug with > the older version in regards to security manager, preventing a smooth run of > the junit tests, and I'd like to run all short-running tests (suites.All and > derbyall) with at least one of the versions. Another reason is that the j2ME > spec 1.0 is really old. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-2224) Test harness should support J2ME 1.1
[ https://issues.apache.org/jira/browse/DERBY-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Myrna van Lunteren updated DERBY-2224: -- Attachment: DERBY-2224_tests_20070116.diff DERBY-2224_tests_20070116.stat > Test harness should support J2ME 1.1 > > > Key: DERBY-2224 > URL: https://issues.apache.org/jira/browse/DERBY-2224 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.2.2.0, 10.3.0.0 >Reporter: Myrna van Lunteren > Assigned To: Myrna van Lunteren >Priority: Minor > Attachments: DERBY-2224_tests_20070116.diff, > DERBY-2224_tests_20070116.stat, DERBY_2224_harness.diff, DERBY_2224_tests.diff > > > I would like to enable the 'old' test harness to support the new version of > IBM's j2ME implementation, which is based on j2ME jdk spec version 1.1. This > is available with a product named Websphere Everyplace Micro Edition 6.1. > from IBM. > We already support j9_foundation, which matches to j2ME jdk spec 1.0. I'd > like to add j9_foundation11, which then matches to j2ME jdk spec 1.1. > I'm proposing to switch my automated tests over to the newer version going > forward, and to minimize complexity of the change, I'd like to make the > canons reflect behavior of the new version. The differences are minimal. > However, I want to be able to still run with the old (except where the > results differ, failures would occur with the old version). > One of the reasons for moving to the new version is that there is a bug with > the older version in regards to security manager, preventing a smooth run of > the junit tests, and I'd like to run all short-running tests (suites.All and > derbyall) with at least one of the versions. Another reason is that the j2ME > spec 1.0 is really old. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2224) Test harness should support J2ME 1.1
[ https://issues.apache.org/jira/browse/DERBY-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465331 ] Myrna van Lunteren commented on DERBY-2224: --- re I18NImportExport.java: the stack trace with weme6.1 is like so: --- JAVA ERROR: java.lang.NoSuchMethodError: java/sql/ResultSet.getBigDecimal(II)Ljava/math/BigDecimal; java.lang.NoSuchMethodError: java/sql/ResultSet.getBigDecimal(II)Ljava/math/BigDecimal; at org.apache.derby.iapi.tools.i18n.LocalizedResource.getLocalizedString(LocalizedResource.java:335) at org.apache.derby.tools.JDBCDisplayUtil.DisplayRow(JDBCDisplayUtil.java:627) at org.apache.derby.tools.JDBCDisplayUtil.indent_DisplayResults(JDBCDisplayUtil.java:338) at org.apache.derby.tools.JDBCDisplayUtil.indent_DisplayResults(JDBCDisplayUtil.java:239) at org.apache.derby.tools.JDBCDisplayUtil.DisplayResults(JDBCDisplayUtil.java:227) at org.apache.derby.impl.tools.ij.utilMain.displayResult(utilMain.java:457) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:520) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:373) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:268) at org.apache.derby.impl.tools.ij.Main.go(Main.java:204) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:170) at org.apache.derby.impl.tools.ij.Main.main(Main.java:72) at org.apache.derby.tools.ij.main(ij.java:67) -- > Test harness should support J2ME 1.1 > > > Key: DERBY-2224 > URL: https://issues.apache.org/jira/browse/DERBY-2224 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.2.2.0, 10.3.0.0 >Reporter: Myrna van Lunteren > Assigned To: Myrna van Lunteren >Priority: Minor > Attachments: DERBY_2224_harness.diff, DERBY_2224_tests.diff > > > I would like to enable the 'old' test harness to support the new version of > IBM's j2ME implementation, which is based on j2ME jdk spec version 1.1. This > is available with a product named Websphere Everyplace Micro Edition 6.1. > from IBM. > We already support j9_foundation, which matches to j2ME jdk spec 1.0. I'd > like to add j9_foundation11, which then matches to j2ME jdk spec 1.1. > I'm proposing to switch my automated tests over to the newer version going > forward, and to minimize complexity of the change, I'd like to make the > canons reflect behavior of the new version. The differences are minimal. > However, I want to be able to still run with the old (except where the > results differ, failures would occur with the old version). > One of the reasons for moving to the new version is that there is a bug with > the older version in regards to security manager, preventing a smooth run of > the junit tests, and I'd like to run all short-running tests (suites.All and > derbyall) with at least one of the versions. Another reason is that the j2ME > spec 1.0 is really old. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2224) Test harness should support J2ME 1.1
[ https://issues.apache.org/jira/browse/DERBY-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465328 ] Myrna van Lunteren commented on DERBY-2224: --- after the fix for DERBY-2228, parameterMapping no longer needs any changes. Also, floattypes needs only 1 minor change. re grantRevokeDDL - the stack trace showing the call java.math.BigDecimal with wctme5.7(foundation) is documented in DERBY-1847. With weme6.1 we get a little further; the create trigger statement actually succeeds, but the insert fails: insert into t31TriggerTest values(1); ERROR 38000: The exception 'java.lang.NoClassDefFoundError: java.sql.DriverManager' was thrown while evaluating an expression. ERROR XJ001: Java exception: 'java.sql.DriverManager: java.lang.NoClassDefFoundError'. derby.log shows: ERROR 38000: The exception 'java.lang.NoClassDefFoundError: java.sql.DriverManager' was thrown while evaluating an expression. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:309) at org.apache.derby.iapi.error.StandardException.unexpectedUserException(StandardException.java:558) at org.apache.derby.impl.services.reflect.DirectCall.invoke(ReflectGeneratedClass.java:164) at org.apache.derby.impl.sql.execute.RowResultSet.getNextRowCore(RowResultSet.java:151) at org.apache.derby.impl.sql.execute.OnceResultSet.getNextRowCore(OnceResultSet.java:177) at org.apache.derby.exe.ac2edd81ddx0110x2ca3x8055x576376c01d.g0(Unknown Source) at org.apache.derby.exe.ac2edd81ddx0110x2ca3x8055x576376c01d.execute(Unknown Source) at org.apache.derby.impl.sql.GenericActivationHolder.execute(GenericActivationHolder.java:327) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:356) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(GenericTriggerExecutor.java:173) at org.apache.derby.impl.sql.execute.StatementTriggerExecutor.fireTrigger(StatementTriggerExecutor.java:80) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(TriggerEventActivator.java:278) at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1120) at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:494) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:358) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1182) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:585) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:517) at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:321) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:517) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:370) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:268) at org.apache.derby.impl.tools.ij.Main.go(Main.java:204) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:170) at org.apache.derby.impl.tools.ij.Main.main(Main.java:72) at org.apache.derby.tools.ij.main(ij.java:67) = begin nested exception, level (1) === java.lang.NoClassDefFoundError: java.sql.DriverManager at org.apache.derbyTesting.functionTests.util.ProcedureTest.selectFromSpecificSchema(ProcedureTest.java:120) at org.apache.derby.exe.ac2edd81ddx0110x2ca3x8055x576376c01d.g2(Unknown Source) at org.apache.derby.exe.ac2edd81ddx0110x2ca3x8055x576376c01d.e1(Unknown Source) at org.apache.derby.impl.services.reflect.DirectCall.invoke(ReflectGeneratedClass.java:141) at org.apache.derby.impl.sql.execute.RowResultSet.getNextRowCore(RowResultSet.java:151) at org.apache.derby.impl.sql.execute.OnceResultSet.getNextRowCore(OnceResultSet.java:177) at org.apache.derby.exe.ac2edd81ddx0110x2ca3x8055x576376c01d.g0(Unknown Source) at org.apache.derby.exe.ac2edd81ddx0110x2ca3x8055x576376c01d.execute(Unknown Source) at org.apache.derby.impl.sql.GenericActivationHolder.execute(GenericActivationHolder.java:327) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:356) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(GenericTriggerExecutor.java:173) at org.apache.derby.impl.sql.execute.StatementTriggerExecutor.fireTrigger(StatementTriggerExecutor.java:80) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(TriggerEventActivator.java:278) at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1120) at or
Re: Graphic Alt text (for accessibility) does not appear in Firefox (does appear in IE) - Derby-1842
Jean T. Anderson wrote: Laura Stewart wrote: For Derby-1842, I updated the alternate text (aka Alt text). The Alt text appears when you hover your mouse pointer over a graphic image in Internet Explorer but not in Firefox. Does anyone know why? https://issues.apache.org/jira/browse/DERBY-1842 A google search popped up this reference which says firefox uses the alt tag as intended: http://www.w3schools.com/tags/tag_img.asp Look at the section titled "Mozilla Firefox and the alt Attribute." It says "title" enables mouseover comments, so I tried that with one of your files and it worked (mouseover now displays the info); however, it truncates everything past the first . On Safari, mouseover displays nothing when "alt" is used, but shows the complete text when "title" is used. So it sounds like the tags should be used as intended. alt for the alternative text title for a title of the image. In firefox one can see the alternate text by right clicking on the image and selecting properties. Dan.
Re: Graphic Alt text (for accessibility) does not appear in Firefox (does appear in IE) - Derby-1842
Laura Stewart wrote: > For Derby-1842, I updated the alternate text (aka Alt text). The Alt > text appears when you hover your mouse pointer over a graphic image in > Internet Explorer but not in Firefox. > > Does anyone know why? > > https://issues.apache.org/jira/browse/DERBY-1842 > A google search popped up this reference which says firefox uses the alt tag as intended: http://www.w3schools.com/tags/tag_img.asp Look at the section titled "Mozilla Firefox and the alt Attribute." It says "title" enables mouseover comments, so I tried that with one of your files and it worked (mouseover now displays the info); however, it truncates everything past the first . On Safari, mouseover displays nothing when "alt" is used, but shows the complete text when "title" is used. -jean
Re: [jira] Commented: (DERBY-2109) System privileges
Why not use "." rather than "@"? Seems more natural to me... David Rick Hillegas (JIRA) wrote: [ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465306 ] Rick Hillegas commented on DERBY-2109: -- I agree that a DatabasePrincipal should encode both the database name and the authorization id inside that database. It is interesting that the same authorization id can have different credentials depending on the connected database. I don't know what the terms-of-art here are, but for the rest of this discussion, I'm going to use the following nomenclature: systemWideID - This is a user name that is authenticated with databaseName = null. databaseScopedID - This is a user name that is authenticated with a non-null databaseName. It is interesting that we authenticate the user twice when creating a database. First we authenticate with a systemWideID. If that succeeds, we create the database and mark that authorization id as the database owner. Then we re-authenticate the user as a databaseScopedID, using the same credentials. Clearly this assumes that at bootstrap time, the same credentials will work for the systemWideID and the databaseScopedID. The policy file syntax for Principals is a little limited. That is, you're only allowed to declare one argument to your Principal's constructor. This means that we have to glue together the authorization id and database name. Maybe we can model this on the names used for KerberosPrincipal. Those names are of the form [EMAIL PROTECTED] I don't know if the @ is going to be a nuisance. Any separator we choose will have escaping problems and @ may be particularly annoying to customers who want their authorization ids to be email addresses. But here's what it would look like: # this is a systemWideID grant principal org.apache.derby.authentication.DatabasePrincipal "fred" ... # this is a databaseScopedID grant principal org.apache.derby.authentication.DatabasePrincipal "[EMAIL PROTECTED]" ... # this systemWideID is an email address grant principal org.apache.derby.authentication.DatabasePrincipal "fred@@comcast.net" ... # this databaseScopedID is an email address grant principal org.apache.derby.authentication.DatabasePrincipal "fred@@[EMAIL PROTECTED]" ... I think that the create-database privilege should be granted to systemWideIDs for the following reasons: 1) The actual database creation today depends on whether we can authenticate the systemWideID, not the databaseScopedID. 2) This is a generic privilege which is not bound to a particular database name. I think that the engine-shutdown privilege is also a systemWideID. So for this first release, I think we only need systemWideIDs--although the user guides should explain the implications of escaping @. System privileges - Key: DERBY-2109 URL: https://issues.apache.org/jira/browse/DERBY-2109 Project: Derby Issue Type: New Feature Components: Security Affects Versions: 10.3.0.0 Reporter: Rick Hillegas Fix For: 10.3.0.0 Attachments: systemPrivs.html, systemPrivs.html Add mechanisms for controlling system-level privileges in Derby. See the related email discussion at http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151. The 10.2 GRANT/REVOKE work was a big step forward in making Derby more secure in a client/server configuration. I'd like to plug more client/server security holes in 10.3. In particular, I'd like to focus on authorization issues which the ANSI spec doesn't address. Here are the important issues which came out of the email discussion. Missing privileges that are above the level of a single database: - Create Database - Shutdown all databases - Shutdown System Missing privileges specific to a particular database: - Shutdown that Database - Encrypt that database - Upgrade database - Create (in that Database) Java Plugins (currently Functions/Procedures, but someday Aggregates and VTIs) Note that 10.2 gave us GRANT/REVOKE control over the following database-specific issues, via granting execute privilege to system procedures: Jar Handling Backup Routines Admin Routines Import/Export Property Handling Check Table In addition, since 10.0, the privilege of connecting to a database has been controlled by two properties (derby.database.fullAccessUsers and derby.database.defaultConnectionMode) as described in the security section of the Developer's Guide (see http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).
[jira] Commented: (DERBY-1952) Remove the running of JUnit tests from the old derby test harness to allow faster conversion to a pure-Junit world.
[ https://issues.apache.org/jira/browse/DERBY-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465311 ] Daniel John Debrunner commented on DERBY-1952: -- Instead of relying on running ant targets (DERBY-2045) I set up a wiki page that lists all the JUnit test classes that are needed to have full functional and unit test coverage. http://wiki.apache.org/db-derby/DerbyTopLevelJunitTests > Remove the running of JUnit tests from the old derby test harness to allow > faster conversion to a pure-Junit world. > --- > > Key: DERBY-1952 > URL: https://issues.apache.org/jira/browse/DERBY-1952 > Project: Derby > Issue Type: Test > Components: Test >Reporter: Daniel John Debrunner > Assigned To: Daniel John Debrunner > > Assuming we had a top-level JUnit suite that ran all the Junit tests > successfully (with the same configuration coverage as they are run today > in derbyall) switch to a dual testing environment until > all the tests were converted to JUnit. This would include removing all > the JUnit tests from the old harness suite files. > That is if one wanted to run all the tests one would have to run: >derbyall with the old harness >suites.All using JUnit test runners directly. > Discussion thread is: > http://mail-archives.apache.org/mod_mbox/db-derby-dev/200610.mbox/[EMAIL > PROTECTED] > Since no objections have been raised I will make progress on this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2109) System privileges
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465306 ] Rick Hillegas commented on DERBY-2109: -- I agree that a DatabasePrincipal should encode both the database name and the authorization id inside that database. It is interesting that the same authorization id can have different credentials depending on the connected database. I don't know what the terms-of-art here are, but for the rest of this discussion, I'm going to use the following nomenclature: systemWideID - This is a user name that is authenticated with databaseName = null. databaseScopedID - This is a user name that is authenticated with a non-null databaseName. It is interesting that we authenticate the user twice when creating a database. First we authenticate with a systemWideID. If that succeeds, we create the database and mark that authorization id as the database owner. Then we re-authenticate the user as a databaseScopedID, using the same credentials. Clearly this assumes that at bootstrap time, the same credentials will work for the systemWideID and the databaseScopedID. The policy file syntax for Principals is a little limited. That is, you're only allowed to declare one argument to your Principal's constructor. This means that we have to glue together the authorization id and database name. Maybe we can model this on the names used for KerberosPrincipal. Those names are of the form [EMAIL PROTECTED] I don't know if the @ is going to be a nuisance. Any separator we choose will have escaping problems and @ may be particularly annoying to customers who want their authorization ids to be email addresses. But here's what it would look like: # this is a systemWideID grant principal org.apache.derby.authentication.DatabasePrincipal "fred" ... # this is a databaseScopedID grant principal org.apache.derby.authentication.DatabasePrincipal "[EMAIL PROTECTED]" ... # this systemWideID is an email address grant principal org.apache.derby.authentication.DatabasePrincipal "fred@@comcast.net" ... # this databaseScopedID is an email address grant principal org.apache.derby.authentication.DatabasePrincipal "fred@@[EMAIL PROTECTED]" ... I think that the create-database privilege should be granted to systemWideIDs for the following reasons: 1) The actual database creation today depends on whether we can authenticate the systemWideID, not the databaseScopedID. 2) This is a generic privilege which is not bound to a particular database name. I think that the engine-shutdown privilege is also a systemWideID. So for this first release, I think we only need systemWideIDs--although the user guides should explain the implications of escaping @. > System privileges > - > > Key: DERBY-2109 > URL: https://issues.apache.org/jira/browse/DERBY-2109 > Project: Derby > Issue Type: New Feature > Components: Security >Affects Versions: 10.3.0.0 >Reporter: Rick Hillegas > Fix For: 10.3.0.0 > > Attachments: systemPrivs.html, systemPrivs.html > > > Add mechanisms for controlling system-level privileges in Derby. See the > related email discussion at > http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151. > The 10.2 GRANT/REVOKE work was a big step forward in making Derby more > secure in a client/server configuration. I'd like to plug more client/server > security holes in 10.3. In particular, I'd like to focus on authorization > issues which the ANSI spec doesn't address. > Here are the important issues which came out of the email discussion. > Missing privileges that are above the level of a single database: > - Create Database > - Shutdown all databases > - Shutdown System > Missing privileges specific to a particular database: > - Shutdown that Database > - Encrypt that database > - Upgrade database > - Create (in that Database) Java Plugins (currently Functions/Procedures, > but someday Aggregates and VTIs) > Note that 10.2 gave us GRANT/REVOKE control over the following > database-specific issues, via granting execute privilege to system > procedures: > Jar Handling > Backup Routines > Admin Routines > Import/Export > Property Handling > Check Table > In addition, since 10.0, the privilege of connecting to a database has been > controlled by two properties (derby.database.fullAccessUsers and > derby.database.defaultConnectionMode) as described in the security section of > the Developer's Guide (see > http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Graphic Alt text (for accessibility) does not appear in Firefox (does appear in IE) - Derby-1842
For Derby-1842, I updated the alternate text (aka Alt text). The Alt text appears when you hover your mouse pointer over a graphic image in Internet Explorer but not in Firefox. Does anyone know why? https://issues.apache.org/jira/browse/DERBY-1842 -- Laura Stewart
[jira] Commented: (DERBY-2234) ant junitreport gives fatal error during transformation
[ https://issues.apache.org/jira/browse/DERBY-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465285 ] Daniel John Debrunner commented on DERBY-2234: -- The run did have failures, it was with ant 1.6.5. If I see it again I see what else I can get. I did see it at leats twice > ant junitreport gives fatal error during transformation > --- > > Key: DERBY-2234 > URL: https://issues.apache.org/jira/browse/DERBY-2234 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.3.0.0 >Reporter: Daniel John Debrunner > > Seemed to create a report still though. > [junitreport] Transform time: 6499ms > [xslt] Processing C:\_work\svn\trunk\junit_20070111_1541\overview-frame > .html to C:\_work\svn\trunk\junit_20070111_1541\overview-frame2.html > [xslt] Loading stylesheet C:\_work\svn\trunk\tools\ant\xsl\sysinfo_juni > treport.xsl > [xslt] C:/_work/svntrunk/junit_20070111_1541/overview-frame.html:14:11 > : Fatal Error! Attribute name "nowrap" associated with an element type "td" > must > be followed by the ' = ' character. > [xslt] Failed to process C:\_work\svntrunk\junit_20070111_1541\overvie > w-frame.html > BUILD FAILED > C:\_work\svntrunk\build.xml:1756: Fatal error during transformation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2196) Run standalone network server with security manager by default
[
https://issues.apache.org/jira/browse/DERBY-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465284
]
Daniel John Debrunner commented on DERBY-2196:
--
Looks good - some initial comments:
In the "Basic Policy" section the spec switches between stating the permissions
will be granted to "Derby" and granted to specific jar files. I think stating
the specific jar files is much clearer.
No idea what this means:
"permission to establish insulating classloaders per connection"
The section for not having derby.system.home set has a permission that
references derby.system.home.
As an alternative to when derby.system.home is not set, consider having the
network server set derby.system.home to the current directory. This would then
have a single format for the policy file rather than two paths.
I don't think derbynet.jar needs permissions to access the database files, e.g.
${derby.system.home}/-
derby.jar does not need to be granted any SocketPermission
Should the socket permission in "Basic Startup Policy" have similar
functionality to the one in "Basic Shutdown Policy" in that localhost is used
if -h is not used etc? Should the port number be in the policy file?
Spec does not reflect the discussion on the list about other file permissions,
e.g. for backup etc.
I don't see (or understand) any rationale for the "Basic Shutdown Policy". What
security hole is this trying to close?
Maybe the answer to this could also explain why the other policy is called
""Basic Shutdown Policy"", when it's the policy for a running server not just
startup time.
I wonder why if the "Open policy" is not recommended a really easy way to use
it is provided.
> Run standalone network server with security manager by default
> --
>
> Key: DERBY-2196
> URL: https://issues.apache.org/jira/browse/DERBY-2196
> Project: Derby
> Issue Type: Improvement
> Components: Network Server, Security
>Reporter: Daniel John Debrunner
> Attachments: secureServer.html
>
>
> From an e-mail discussion:
> ... Derby should match the security provided by typical client server
> systems such as DB2, Oracle, etc. I
> think in this case system/database owners are trusting the database
> system to ensure that their system cannot be attacked. So maybe if Derby
> is booted as a standalone server with no security manager involved, it
> should install one with a default security policy. Thus allowing Derby
> to use Java security manager to manage system privileges but not
> requiring everyone to become familiar with them.
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200612.mbox/[EMAIL
> PROTECTED]
> I imagine such a policy would allow any access to databases under
> derby.system.home and/or user.home.
> By standalone I mean the network server was started though the main() method
> (command line).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2224) Test harness should support J2ME 1.1
[ https://issues.apache.org/jira/browse/DERBY-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465281 ] Myrna van Lunteren commented on DERBY-2224: --- committed the test harness changes (not the canons/test changes) with http://svn.apache.org/viewvc?view=rev&revision=496847 > Test harness should support J2ME 1.1 > > > Key: DERBY-2224 > URL: https://issues.apache.org/jira/browse/DERBY-2224 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.2.2.0, 10.3.0.0 >Reporter: Myrna van Lunteren > Assigned To: Myrna van Lunteren >Priority: Minor > Attachments: DERBY_2224_harness.diff, DERBY_2224_tests.diff > > > I would like to enable the 'old' test harness to support the new version of > IBM's j2ME implementation, which is based on j2ME jdk spec version 1.1. This > is available with a product named Websphere Everyplace Micro Edition 6.1. > from IBM. > We already support j9_foundation, which matches to j2ME jdk spec 1.0. I'd > like to add j9_foundation11, which then matches to j2ME jdk spec 1.1. > I'm proposing to switch my automated tests over to the newer version going > forward, and to minimize complexity of the change, I'd like to make the > canons reflect behavior of the new version. The differences are minimal. > However, I want to be able to still run with the old (except where the > results differ, failures would occur with the old version). > One of the reasons for moving to the new version is that there is a bug with > the older version in regards to security manager, preventing a smooth run of > the junit tests, and I'd like to run all short-running tests (suites.All and > derbyall) with at least one of the versions. Another reason is that the j2ME > spec 1.0 is really old. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2234) ant junitreport gives fatal error during transformation
[ https://issues.apache.org/jira/browse/DERBY-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465277 ] Andrew McIntyre commented on DERBY-2234: I'm not able to reproduce this issue. Was this seen in a test run with failures? What version of Ant? > ant junitreport gives fatal error during transformation > --- > > Key: DERBY-2234 > URL: https://issues.apache.org/jira/browse/DERBY-2234 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.3.0.0 >Reporter: Daniel John Debrunner > > Seemed to create a report still though. > [junitreport] Transform time: 6499ms > [xslt] Processing C:\_work\svn\trunk\junit_20070111_1541\overview-frame > .html to C:\_work\svn\trunk\junit_20070111_1541\overview-frame2.html > [xslt] Loading stylesheet C:\_work\svn\trunk\tools\ant\xsl\sysinfo_juni > treport.xsl > [xslt] C:/_work/svntrunk/junit_20070111_1541/overview-frame.html:14:11 > : Fatal Error! Attribute name "nowrap" associated with an element type "td" > must > be followed by the ' = ' character. > [xslt] Failed to process C:\_work\svntrunk\junit_20070111_1541\overvie > w-frame.html > BUILD FAILED > C:\_work\svntrunk\build.xml:1756: Fatal error during transformation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-2246) Support a way to specify traceLevel attribute value as symbols/hex values rather than int value inside ij url
Support a way to specify traceLevel attribute value as symbols/hex values rather than int value inside ij url - Key: DERBY-2246 URL: https://issues.apache.org/jira/browse/DERBY-2246 Project: Derby Issue Type: Improvement Components: Tools Reporter: Mamta A. Satoor Priority: Minor http://db.apache.org/derby/docs/10.2/adminguide/cadminappsclienttracing.html has a table that specifies various tracing levels and their corresponding hex values. In ij, there is no way to use these symbolic values or hex values in the jdbc url, instead, the user needs to use the corresponding int values. It will make this property more user-friendly, if the user had a means to use the symbolic values or the hex values inside the ij tool. More info on this can be found at http://www.nabble.com/Specifying-the-traceLevel-property-through-ij-tf3021545.html#a8391955 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Specifying the traceLevel property through ij
Thanks for taking the time to respond, Knut. One of the reasons I asked this question is, currently in my patch for DERBY-1275, a user can't use the symbols or a hex value to specify the traceLevel. Instead, they have to specify the int value just as they need to through ij. Code can be added to let the user specify the symbol or hex values for the jvm properties introduced by DERBY-1275 but keeping in mind the incremental development process, I will go ahead and post my patch which will just accept the int value for the properties and we can go from there. I added a jira entry for ij DERBY-2246 Support a way to specify traceLevel attribute value as symbols/hex values rather than int value inside ij url Mamta On 1/16/07, Knut Anders Hatlen <[EMAIL PROTECTED] > wrote: Mamta Satoor < [EMAIL PROTECTED]> writes: > Hi, > > I am working on DERBY-1275 "Provide a way to enable client tracing without > changing the application" which will provide a way to specify client tracing > without having to change the client application. While working on it, I > tried testing the exisitng functionality of setting the traceLevel through > the jdbc url in ij and found that I couldn't make it work with either of the > 2 documented ways of specifying the traceLevel value > http://db.apache.org/derby/docs/10.2/adminguide/cadminappsclienttracing.html > > Following is what I tried > $ java org.apache.derby.tools.ij > ij version 10.3 > ij> connect 'jdbc:derby://localhost:1527/c:/dellater/db1;traceLevel= > org.apache.derby.jdbc.ClientDataSource.TRACE_CONNECTION_CALLS;create=true'; > ERROR XJ213: The traceLevel connection property does not have a valid format > for a number. > ij> connect > 'jdbc:derby://localhost:1527/c:/dellater/db1;traceLevel=0x;create=true'; > ERROR XJ213: The traceLevel connection property does not have a valid format > for a number. > > I haven't tried this yet through a Java JDBC program but I thought that one > should be able to specify this property through ij as well. I can file a > jira entry if we agree that this is a bug. I don't think this is a bug. The documentation doesn't say that you can use the name of the constant or the value in hex format in the connection URL. The section of the adminguide that you referred to has this example: String url = "jdbc:derby://samplehost.sampledomain.com:1528/mydb" + ";traceFile=/u/user1/trace.out" + ";traceLevel=" + org.apache.derby.jdbc.ClientDataSource.TRACE_PROTOCOL_FLOWS ; The actual SQL text in this example is ...;traceLevel=64 not ...;traceLevel=o.a.d.jdbc.ClientDataSource.TRACE_PROTOCOL_FLOWS That said, it would be more convenient to be able to specify trace levels with symbols, so you shouldn't let this stop you from filing a JIRA. -- Knut Anders
[jira] Commented: (DERBY-2196) Run standalone network server with security manager by default
[ https://issues.apache.org/jira/browse/DERBY-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465272 ] Rick Hillegas commented on DERBY-2196: -- Attached first draft of functional spec based on wiki page. Community feedback appreciated. > Run standalone network server with security manager by default > -- > > Key: DERBY-2196 > URL: https://issues.apache.org/jira/browse/DERBY-2196 > Project: Derby > Issue Type: Improvement > Components: Network Server, Security >Reporter: Daniel John Debrunner > Attachments: secureServer.html > > > From an e-mail discussion: > ... Derby should match the security provided by typical client server > systems such as DB2, Oracle, etc. I > think in this case system/database owners are trusting the database > system to ensure that their system cannot be attacked. So maybe if Derby > is booted as a standalone server with no security manager involved, it > should install one with a default security policy. Thus allowing Derby > to use Java security manager to manage system privileges but not > requiring everyone to become familiar with them. > http://mail-archives.apache.org/mod_mbox/db-derby-dev/200612.mbox/[EMAIL > PROTECTED] > I imagine such a policy would allow any access to databases under > derby.system.home and/or user.home. > By standalone I mean the network server was started though the main() method > (command line). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-2196) Run standalone network server with security manager by default
[ https://issues.apache.org/jira/browse/DERBY-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-2196: - Attachment: secureServer.html > Run standalone network server with security manager by default > -- > > Key: DERBY-2196 > URL: https://issues.apache.org/jira/browse/DERBY-2196 > Project: Derby > Issue Type: Improvement > Components: Network Server, Security >Reporter: Daniel John Debrunner > Attachments: secureServer.html > > > From an e-mail discussion: > ... Derby should match the security provided by typical client server > systems such as DB2, Oracle, etc. I > think in this case system/database owners are trusting the database > system to ensure that their system cannot be attacked. So maybe if Derby > is booted as a standalone server with no security manager involved, it > should install one with a default security policy. Thus allowing Derby > to use Java security manager to manage system privileges but not > requiring everyone to become familiar with them. > http://mail-archives.apache.org/mod_mbox/db-derby-dev/200612.mbox/[EMAIL > PROTECTED] > I imagine such a policy would allow any access to databases under > derby.system.home and/or user.home. > By standalone I mean the network server was started though the main() method > (command line). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2191) Cleanup of FormatableBitSet
[ https://issues.apache.org/jira/browse/DERBY-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465266 ] Knut Anders Hatlen commented on DERBY-2191: --- If we have a check for the position, I think we should test both whether it is too big and whether it is too small. None of those cases should happen, and I don't think bugs causing negative positions are less likely or less severe than bugs causing too big positions. If negative positions always caused other exceptions, it would probably be OK to skip the test, but I'm not sure they always do. At least, it doesn't seem like isSet(), set() and clear() always throw exceptions when the position is negative. I think it must be _sufficiently_ negative compared to the size of the bit set before an exception is thrown. :) In FormatableBitSetTest, set(-1) and clear(-1) fail when the set is empty, but don't fail otherwise. isSet(-1) doesn't fail in any case. > Cleanup of FormatableBitSet > --- > > Key: DERBY-2191 > URL: https://issues.apache.org/jira/browse/DERBY-2191 > Project: Derby > Issue Type: Improvement > Components: Miscellaneous >Affects Versions: 10.2.1.6 >Reporter: Dyre Tjeldvoll > Assigned To: Dyre Tjeldvoll >Priority: Trivial > Fix For: 10.3.0.0 > > Attachments: deadcode.v1.diff, deadcode.v2.diff, fbstst.v1.diff, > fbstst.v1.stat, FormatableBitSetTest.java, valuenotnull.v1.diff, > valuenotnull.v1.stat > > > The implementation of FormatableBitSet could be streamlined. Dead code can be > removed and the implementation of some methods can be simplified. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Questionable use of word in "VALUES expression" of Derby Reference Manual
I think that "statement" should be used only for SQL statements like SELECT, CREATE TABLE, GRANT. VALUES is not a statement in SQL. I believe that "clause" is more accurate. Laura On 1/16/07, TomohitoNakayama <[EMAIL PROTECTED]> wrote: Hello. See It is reason why I feel question that title of the page was "VALUE expression" and there was "VALUE statement". Then I feel question for the different word. Reading comment from others, however , I came to conclude that it is quite right that the words are different according to context which original writer thought . Then I will respect original usage and keep it as "statement" in translated manual. Thank you for your comments :) Best regards. Bernt M. Johnsen wrote: >Julius Stroffek wrote (2007-01-15 17:16:36): > > >>Hi Tomohito, >> >>I would say that the VALUES construct is a statement not an expression. >>The result and usage is similar like SELECT statement. >> >> > >In the SQL standard the construct > VALUES >is called a > > > > >>Cheers >> >>Julo >> >>TomohitoNakayama wrote: >> >> >>>Hello. >>> >>>I found next one sentence in "VALUES expression" of Derby Reference >>>Manual (http://db.apache.org/derby/docs/dev/ref/rrefsqlj11277.html) >>> >>> >>> >>> You use a VALUES statement when you do not have a FROM clause. >>>I think statement should be expression here but not completely sure >>>I hope opinion from others ... >>> >>>Best regards. >>> >>> >>> >>> > > > -- /* Tomohito Nakayama [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */ -- Laura Stewart
Re: DatabaseMetaData JDBC specification question
If the JDBC spec does not indicate that the parameter accepts a pattern for the value, then i would suggest you only support patterns where it is required. It is possible tests could be added to do additional validation of parameters passed into API methods in future TCKs for conformance. Daniel John Debrunner wrote: For the DatabaseMetaData methods that fetch attributes of SQL objects (such as getTables, getColumns) the parameters are described in the javadoc in three ways: 1) Parameter must match the object's name as stored in the database. a table name; must match the table name as it is stored in the database 2) Parameter must match the object's name as stored in the database and two special values are allowed (empty string and null). a schema name; must match the schema name as it is stored in the database; "" retrieves those without a schema; null means that the schema name should not be used to narrow the search 3) A pattern, explicitly called out in the overview of DatabaseMetaData and states the parameter name will end in 'pattern'. a table name pattern; must match the table name as it is stored in the database These imply very different behaviours for the various styles, e.g. for 1) null should not be allowed and the value should not be treated as a pattern or use empty string to indicate those without a schema. for 2) the value should not be treated as a pattern. Derby does not follow this split, it treats every such argument as a pattern (in some cases the client may treat arguments differently). Is the split in DatabaseMetaData intentional, it seems so given the explicit wording for patterns? And the fact that in some cases the method's description indicates information for 'a table' (singular) is returned and the resulting rows have no information that allows one to determine which table a row is for (e.g getBestRowIdentifier & getVersionColumns). Though in both those cases the api also implicitly allows for multiple tables to be returned when the same table name exists in multiple schemas. If so should Derby follow the strict definitions of the javadoc or could Derby just be providing extensions to the standard behaviour? The only area where I could see issues coming up with this extension is when the parameter is in category 1) or 2) and the object name contains '%' or '_'. Then a meta data call could potentially return rows for other tables and in some cases the meta data provides no way to determine which table a row is for (e.g getBestRowIdentifier & getVersionColumns). One other point is that removing the pattern support from a number of meta data queries would most likely improve their performance. Thanks, Dan.
[jira] Assigned: (DERBY-2233) junit test derbynet/PreparedStatementTest fails with wctme5.7 (aka j9 2.2/ foundation/j2ME 1.0) and weme6.1 (aka j9 2.3 / foundation/j2ME 1.1)
[ https://issues.apache.org/jira/browse/DERBY-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Myrna van Lunteren reassigned DERBY-2233: - Assignee: Myrna van Lunteren > junit test derbynet/PreparedStatementTest fails with wctme5.7 (aka j9 2.2/ > foundation/j2ME 1.0) and weme6.1 (aka j9 2.3 / foundation/j2ME 1.1) > --- > > Key: DERBY-2233 > URL: https://issues.apache.org/jira/browse/DERBY-2233 > Project: Derby > Issue Type: Test > Environment: jvms wctme5.7 (aka j9 2.2/ foundation/j2ME 1.0) and > weme6.1 (aka j9 2.3 / foundation/j2ME 1.1) >Reporter: Myrna van Lunteren > Assigned To: Myrna van Lunteren > > The test derbynet/preparedStatementTest, recently (Jan 2, revision 491768) > converted to junit, fails with the CDC/Foundation/JSR169/J2ME implementation. > wctme5.7/j9 2.2/j2ME 1.0 shows: > --- > 1) > testParameterTypes(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoClassDefFoundError: > java.math.BigDecimal > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testParameterTypes(PrepareStatementTest.java:182) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:199) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > 2) > testBigDecimalSetObject(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoClassDefFoundError: > java.math.BigDecimal > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testBigDecimalSetObject(PrepareStatementTest.java:430) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:199) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > 3) > testBigDecimalSetObjectWithScale(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoClassDefFoundError: > java.math.BigDecimal > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testBigDecimalSetObjectWithScale(PrepareStatementTest.java:478) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:199) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > 4) > testSmallBigDecimal(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoClassDefFoundError: > java.math.BigDecimal > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testSmallBigDecimal(PrepareStatementTest.java:555) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:199) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > -- > weme6.1/j9 2.3/j2ME 1.1 shows: > -- > 1) > testParameterTypes(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.lang.NoSuchMethodError: > java/sql/PreparedStatement.setBigDecimal(ILjava/math/BigDecimal;)V > at > org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest.testParameterTypes(PrepareStatementTest.java:210) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:203) > at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > 2) > testBigDecimalSetObject(org.apache.derbyTesting.functionTests.tests.derbynet.PrepareStatementTest)java.sql.SQLException: > An attempt was made to get a data value of type 'DOUBLE' from a data value > of type 'java.math.BigDecimal'. > at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown > Source) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source
[jira] Assigned: (DERBY-2158) test lang.UpdatableResultSetTest.testUpdateXXXWithAllDatatypes fails with wctme5.7 (j9) foundation
[ https://issues.apache.org/jira/browse/DERBY-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Myrna van Lunteren reassigned DERBY-2158: - Assignee: Myrna van Lunteren > test lang.UpdatableResultSetTest.testUpdateXXXWithAllDatatypes fails with > wctme5.7 (j9) foundation > -- > > Key: DERBY-2158 > URL: https://issues.apache.org/jira/browse/DERBY-2158 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.3.0.0 > Environment: IBM wctme5.7 foundation >Reporter: Myrna van Lunteren > Assigned To: Myrna van Lunteren >Priority: Minor > > 3) > testUpdateXXXWithAllDatatypes(org.apache.derbyTesting.functionTests.tests.lang.UpdatableResultSetTest)java.lang.NoSuchMethodError: > java/sql/ResultSet.getBigDecimal(I)Ljava/math/BigDecimal; > at > org.apache.derbyTesting.functionTests.tests.lang.UpdatableResultSetTest.verifyData(UpdatableResultSetTest.java:4491) > at > org.apache.derbyTesting.functionTests.tests.lang.UpdatableResultSetTest.runTestUpdateXXXWithAllDatatypes(UpdatableResultSetTest.java:2742) > at > org.apache.derbyTesting.functionTests.tests.lang.UpdatableResultSetTest.testUpdateXXXWithAllDatatypes(UpdatableResultSetTest.java:2513) > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:199) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1478) Add built in language based ordering and like processing to Derby
[ https://issues.apache.org/jira/browse/DERBY-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465212 ] Daniel John Debrunner commented on DERBY-1478: -- I assume that this collation only applies to CHAR and VARCHAR types, would be good to state that in any functional spec/documentation. Will the system tables use the localized collation for their character types or continue to always use the unicode code point ordering regardless of any database defined collation? Currently the uppercasing of SQL statements and identifiers is fixed as English to avoid unexpected issues with other languages, it may be wise to take the same approach so that the system table behaviour is fixed. However that will introduce some issues as then comparing a system column against a user column or a constant must decide on a collation to use. On the other hand changing the collation for system tables may break builtin assumptions or JDBC contracts (e.g. order of JDBC database meta data). > Add built in language based ordering and like processing to Derby > - > > Key: DERBY-1478 > URL: https://issues.apache.org/jira/browse/DERBY-1478 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.1.2.1 >Reporter: Kathey Marsden > Assigned To: Mamta A. Satoor > > It would be good for Derby to have built in Language based ordering based on > locale specific Collator. > Language based ordering is an important feature for international deployment. > DERBY-533 offers one implementation option for this but according to the > discussion in that issue National Character Types carry a fair amount of > baggage with them especially in the form of concerns about conversion to > and from datetime and number types. Rick mentioned SQL language for > collations as an option for language based ordering. There may be other > options too, but I thought it worthwhile to add an issue for the high level > functional concern, so the best choice can be made for implementation without > assuming that National Character Types is the only solution. > For possible 10.1 workaround and examples see: > http://wiki.apache.org/db-derby/LanguageBasedOrdering -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Regression Test Report - Daily 496404 - Sun DBTG
[Auto-generated mail] *Daily* 496404/2007-01-15 18:00:09 MET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 0513513 099.12% derbyall 065786578 0 174.61% suitesAll sles 0513513 099.89% derbyall 065786578 0 102.41% suitesAll sol 0513513 0 104.68% derbyall 065786578 0 154.63% suitesAll solN+1 0513513 0 127.49% derbyall 065786578 0 171.53% suitesAll sparc 0513513 0 110.69% derbyall 065786578 0 166.03% suitesAll win 0513513 0 117.95% derbyall 065786578 0 100.72% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-496404.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/496404.html *Jvm: 1.5* lin 1507506 299.02% derbyall 023292329 0 182.31% suitesAll sles 0507507 299.60% derbyall 023292329 0 102.75% suitesAll sol 0507507 2 107.59% derbyall 023292329 0 136.94% suitesAll solN+1 0507507 2 132.57% derbyall 023292329 0 138.77% suitesAll sparc 0507507 2 110.96% derbyall 023292329 0 123.41% suitesAll win 0507507 2 123.60% derbyall 023292329 095.21% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-496404.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/496404.html *Jvm: 1.4* lin 0501501 4 100.40% derbyall 023272327 0 180.98% suitesAll sles 3501498 4 100.02% derbyall 023272327 0 104.13% suitesAll sol 0501501 4 105.42% derbyall 023272327 0 134.21% suitesAll solN+1 0501501 4 134.93% derbyall 023272327 0 151.45% suitesAll sparc 0501501 4 112.24% derbyall 023272327 0 148.75% suitesAll win 0501501 471.08% derbyall 023272327 0 102.36% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-496404.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/496404.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/496404.txt ( All results in http://dbtg.thresher.com/derby/test/ )
DatabaseMetaData JDBC specification question
For the DatabaseMetaData methods that fetch attributes of SQL objects (such as getTables, getColumns) the parameters are described in the javadoc in three ways: 1) Parameter must match the object's name as stored in the database. a table name; must match the table name as it is stored in the database 2) Parameter must match the object's name as stored in the database and two special values are allowed (empty string and null). a schema name; must match the schema name as it is stored in the database; "" retrieves those without a schema; null means that the schema name should not be used to narrow the search 3) A pattern, explicitly called out in the overview of DatabaseMetaData and states the parameter name will end in 'pattern'. a table name pattern; must match the table name as it is stored in the database These imply very different behaviours for the various styles, e.g. for 1) null should not be allowed and the value should not be treated as a pattern or use empty string to indicate those without a schema. for 2) the value should not be treated as a pattern. Derby does not follow this split, it treats every such argument as a pattern (in some cases the client may treat arguments differently). Is the split in DatabaseMetaData intentional, it seems so given the explicit wording for patterns? And the fact that in some cases the method's description indicates information for 'a table' (singular) is returned and the resulting rows have no information that allows one to determine which table a row is for (e.g getBestRowIdentifier & getVersionColumns). Though in both those cases the api also implicitly allows for multiple tables to be returned when the same table name exists in multiple schemas. If so should Derby follow the strict definitions of the javadoc or could Derby just be providing extensions to the standard behaviour? The only area where I could see issues coming up with this extension is when the parameter is in category 1) or 2) and the object name contains '%' or '_'. Then a meta data call could potentially return rows for other tables and in some cases the meta data provides no way to determine which table a row is for (e.g getBestRowIdentifier & getVersionColumns). One other point is that removing the pattern support from a number of meta data queries would most likely improve their performance. Thanks, Dan.
[jira] Commented: (DERBY-2191) Cleanup of FormatableBitSet
[ https://issues.apache.org/jira/browse/DERBY-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465197 ] Dyre Tjeldvoll commented on DERBY-2191: --- I'm looking at how boundary checking could be improved in this class, but I'm a bit unsure about what the best approach is. Right now I have a patch in my sandbox that introduces a private checkPosition() method that is used in all accessors (isSet(), set(), clear()), which throws IllegalArgumentException if the position is negative or larger than the largest legal bit position. This gives a clean interface where all illegal positions are handled uniformly and the test looks cleaner. But I'm a bit uncomfortable with all this extra checking for an internal interface that only developers will use. If we accept that using a negative bit doesn't result in the same exception being thrown we could cut down on the testing since a negative bit index always will result in an exception. If we can accept that access to illegal bit positions in the last byte go undetected we could drop the extra check altogether... (there is, of course, the issue of what set(illegalIndex) should do. Nothing?) Another more radical solution is to require bitset sizes to be a multiple of 8. Then one would not need to track the number of bits used. This would only be possible if we remove concatenate() (which is unused). > Cleanup of FormatableBitSet > --- > > Key: DERBY-2191 > URL: https://issues.apache.org/jira/browse/DERBY-2191 > Project: Derby > Issue Type: Improvement > Components: Miscellaneous >Affects Versions: 10.2.1.6 >Reporter: Dyre Tjeldvoll > Assigned To: Dyre Tjeldvoll >Priority: Trivial > Fix For: 10.3.0.0 > > Attachments: deadcode.v1.diff, deadcode.v2.diff, fbstst.v1.diff, > fbstst.v1.stat, FormatableBitSetTest.java, valuenotnull.v1.diff, > valuenotnull.v1.stat > > > The implementation of FormatableBitSet could be streamlined. Dead code can be > removed and the implementation of some methods can be simplified. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-2245) DatabaseMetaData.getSQLKeywords() contains words that are not keywords in Derby.
DatabaseMetaData.getSQLKeywords() contains words that are not keywords in Derby. Key: DERBY-2245 URL: https://issues.apache.org/jira/browse/DERBY-2245 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.2.2.0, 10.2.1.6, 10.1.3.1, 10.1.2.1, 10.1.1.0, 10.0.2.1, 10.0.2.0 Reporter: Daniel John Debrunner Priority: Minor Such as REFRESH and PUBLICATION. Not sure what the exact contents should be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Specifying the traceLevel property through ij
Mamta Satoor <[EMAIL PROTECTED]> writes: > Hi, > > I am working on DERBY-1275 "Provide a way to enable client tracing without > changing the application" which will provide a way to specify client tracing > without having to change the client application. While working on it, I > tried testing the exisitng functionality of setting the traceLevel through > the jdbc url in ij and found that I couldn't make it work with either of the > 2 documented ways of specifying the traceLevel value > http://db.apache.org/derby/docs/10.2/adminguide/cadminappsclienttracing.html > > Following is what I tried > $ java org.apache.derby.tools.ij > ij version 10.3 > ij> connect 'jdbc:derby://localhost:1527/c:/dellater/db1;traceLevel= > org.apache.derby.jdbc.ClientDataSource.TRACE_CONNECTION_CALLS;create=true'; > ERROR XJ213: The traceLevel connection property does not have a valid format > for a number. > ij> connect > 'jdbc:derby://localhost:1527/c:/dellater/db1;traceLevel=0x;create=true'; > ERROR XJ213: The traceLevel connection property does not have a valid format > for a number. > > I haven't tried this yet through a Java JDBC program but I thought that one > should be able to specify this property through ij as well. I can file a > jira entry if we agree that this is a bug. I don't think this is a bug. The documentation doesn't say that you can use the name of the constant or the value in hex format in the connection URL. The section of the adminguide that you referred to has this example: String url = "jdbc:derby://samplehost.sampledomain.com:1528/mydb" + ";traceFile=/u/user1/trace.out" + ";traceLevel=" + org.apache.derby.jdbc.ClientDataSource.TRACE_PROTOCOL_FLOWS; The actual SQL text in this example is ...;traceLevel=64 not ...;traceLevel=o.a.d.jdbc.ClientDataSource.TRACE_PROTOCOL_FLOWS That said, it would be more convenient to be able to specify trace levels with symbols, so you shouldn't let this stop you from filing a JIRA. -- Knut Anders
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription
Filter: Derby: JIRA issues with patch available (20 issues)
Subscriber: derby-dev
Key Summary
DERBY-2166 Implement proper handling of SocketTimeoutException in
DRDAConnThread
https://issues.apache.org/jira/browse/DERBY-2166
DERBY-2224 Test harness should support J2ME 1.1
https://issues.apache.org/jira/browse/DERBY-2224
DERBY-2241 compatibilitytest fails after DERBY-2121 change.
https://issues.apache.org/jira/browse/DERBY-2241
DERBY-2237 Cleanup copyrights in the DITA source and generated docs
https://issues.apache.org/jira/browse/DERBY-2237
DERBY-2236 Three tests from i18nTest fails on SLES with jdk1.4.2 when
derbyrun.jar comes before derby.jar in the classpath
https://issues.apache.org/jira/browse/DERBY-2236
DERBY-2150 Reduce use of synchronized collections in
GenericLanguageConnectionContext
https://issues.apache.org/jira/browse/DERBY-2150
DERBY-2197 Remove unused code for locking rows while holding a latch
https://issues.apache.org/jira/browse/DERBY-2197
DERBY-2218 Null Pointer Exception when an IN list contains an untyped NULL
subquery ("values null").
https://issues.apache.org/jira/browse/DERBY-2218
DERBY-1620 SQL CASE statement returns ERROR 42X89 when including NULL as a
return value
https://issues.apache.org/jira/browse/DERBY-1620
DERBY-1909 ALTER TABLE DROP COLUMN needs to update GRANTed column privileges
https://issues.apache.org/jira/browse/DERBY-1909
DERBY-1662 Document derbyrun.jar
https://issues.apache.org/jira/browse/DERBY-1662
DERBY-2216 Allow demo SimpleApp to work in J2ME environment
https://issues.apache.org/jira/browse/DERBY-2216
DERBY-2214 Fix Getting Started file to reflect classpath change
https://issues.apache.org/jira/browse/DERBY-2214
DERBY-2161 MessageBuilder can write the properties file using the wrong
encoding.
https://issues.apache.org/jira/browse/DERBY-2161
DERBY-2137 CALL (PROCEDURE) statement documentation in reference manual has
incomplete syntax for arguments
https://issues.apache.org/jira/browse/DERBY-2137
DERBY-681 Eliminate the parser's rewriting of the abstract syntax tree for
queries with GROUP BY and/or HAVING clauses
https://issues.apache.org/jira/browse/DERBY-681
DERBY-2031 Convert derbynet/testProtocol.java to JUnit
https://issues.apache.org/jira/browse/DERBY-2031
DERBY-2017 Client driver can insert and commit partial data when a LOB stream
throws IOException or does not match the specified length
https://issues.apache.org/jira/browse/DERBY-2017
DERBY-1842 Accessibility of figures in Derby Docs
https://issues.apache.org/jira/browse/DERBY-1842
DERBY-1938 Add support for setObject(, null)
https://issues.apache.org/jira/browse/DERBY-1938
Specifying the traceLevel property through ij
Hi, I am working on DERBY-1275 "Provide a way to enable client tracing without changing the application" which will provide a way to specify client tracing without having to change the client application. While working on it, I tried testing the exisitng functionality of setting the traceLevel through the jdbc url in ij and found that I couldn't make it work with either of the 2 documented ways of specifying the traceLevel value http://db.apache.org/derby/docs/10.2/adminguide/cadminappsclienttracing.html Following is what I tried $ java org.apache.derby.tools.ij ij version 10.3 ij> connect 'jdbc:derby://localhost:1527/c:/dellater/db1;traceLevel= org.apache.derby.jdbc.ClientDataSource.TRACE_CONNECTION_CALLS;create=true'; ERROR XJ213: The traceLevel connection property does not have a valid format for a number. ij> connect 'jdbc:derby://localhost:1527/c:/dellater/db1;traceLevel=0x;create=true'; ERROR XJ213: The traceLevel connection property does not have a valid format for a number. I haven't tried this yet through a Java JDBC program but I thought that one should be able to specify this property through ij as well. I can file a jira entry if we agree that this is a bug. thanks, Mamta
[jira] Updated: (DERBY-2191) Cleanup of FormatableBitSet
[ https://issues.apache.org/jira/browse/DERBY-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-2191: -- Derby Info: (was: [Patch Available]) Verified that there is no way to set value to null. All tests ran cleanly. Committed revision 496719. > Cleanup of FormatableBitSet > --- > > Key: DERBY-2191 > URL: https://issues.apache.org/jira/browse/DERBY-2191 > Project: Derby > Issue Type: Improvement > Components: Miscellaneous >Affects Versions: 10.2.1.6 >Reporter: Dyre Tjeldvoll > Assigned To: Dyre Tjeldvoll >Priority: Trivial > Fix For: 10.3.0.0 > > Attachments: deadcode.v1.diff, deadcode.v2.diff, fbstst.v1.diff, > fbstst.v1.stat, FormatableBitSetTest.java, valuenotnull.v1.diff, > valuenotnull.v1.stat > > > The implementation of FormatableBitSet could be streamlined. Dead code can be > removed and the implementation of some methods can be simplified. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-2226) Move column bitset computation to IndexToBaseRowNode
[ https://issues.apache.org/jira/browse/DERBY-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll closed DERBY-2226. - > Move column bitset computation to IndexToBaseRowNode > > > Key: DERBY-2226 > URL: https://issues.apache.org/jira/browse/DERBY-2226 > Project: Derby > Issue Type: Improvement >Reporter: Dyre Tjeldvoll > Assigned To: Dyre Tjeldvoll >Priority: Trivial > Fix For: 10.3.0.0 > > Attachments: derby-2226.v1.diff, derby-2226.v1.stat, > derby-2226.v2.diff, derby-2226.v2.stat > > > The constructor for IndexRowToBaseRowResultSet > takes a bitset describing the columns coming from the heap and a > bitset describing the columns coming from the index. But in every > IndexRowToBaseRowResultSet one also has to compute _all_ referenced > columns (union of heap and index bitsets), and frequently also those > columns _only_ coming from the heap (set difference between heap and > index). > But the value of these "set products" seem _only_ to depend on objects > that are fixed at compile time (in IndexToBaseRowNode), so it would be > cleaner (and possibly more efficient) to compute these products there. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Testing implementation of private classes
Looks excellent. ;-) Julo Kristian Waagan wrote: Daniel John Debrunner wrote: Julius.Stroffek wrote: Hi All, I'll try to divide the problem into two parts: 1.) Writing tests. I think that nobody argued that we should use something really different than the parallel source tree. 2.) Executing tests. There are more possibilities on this. a) executing the test against the classpath. b) creating the separate derby jar file for testing private classes. c) creating the separate jar with tests' implementation and creating the nearly same jar files as the derby product jars but which will not be sealed. What's the benefit of running unit tests against jar files? For functional tests I see the benefit, it is testing the user api using artifacts the user is expected to have on the classpath. However for unit tests I can't see what bugs would be found by testing against classes that are in a "fake" jar (assuming the unit tests are run against classes as well). There is a practical benefit of using jars instead of classes when running the tests on remote hosts. Instead of copying thousands of small files, you copy a handful of jars. A little scripting on your own part can solve this easily of course, so I guess this boils down to almost nothing. Another proposal, which *I think* allow us to keep things as they are and generate a separate jar file for unit tests requiring package-private access: Use the non-standard option -Xbootclasspath. By specifying the jars on the boot classpath, the sealing protection will be overridden and the tests can be run. We can keep the existing tests as they are, and only use this option when running the "package-private unit tests". This approach also require two (currently three) steps to run all tests, but we won't have to change the existing jars. The unit tests can then also be run with distribution jars if anyone should wish to do that, and with both sane and insane builds. Does anyone see any showstoppers for this approach? I tested a small sample with Sun VMs. Does it work for VMs from other vendors?
[jira] Commented: (DERBY-2103) After a Lexical Error due to syntax error , even a simple create table does not work on the same connection.
[ https://issues.apache.org/jira/browse/DERBY-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465141 ] Mayuresh Nirhali commented on DERBY-2103: - derbyall testrun just finished with the proposed fix and it did not show any new failures. Mayuresh > After a Lexical Error due to syntax error ,even a simple create table > does not work on the same connection. > > > Key: DERBY-2103 > URL: https://issues.apache.org/jira/browse/DERBY-2103 > Project: Derby > Issue Type: Bug >Affects Versions: 10.3.0.0 >Reporter: Suresh Thalamati > Assigned To: Mayuresh Nirhali >Priority: Minor > > connect 'jdbc:derby:wombat;create=true'; > create table t1(a int ) ; > create table "t2"(a int ) ; > -- this should fail. > create table foo (a int , \"YEAR\" int ) ; > -- but this should not fail. But failing > create table t4 ( b int ) ; > FYI: > $ java org.apache.derby.tools.ij > ij version 10.3 > ij> run 'weird1.sql'; > ij> connect 'jdbc:derby:wombat;create=true'; > ij> create table t1(a int ) ; > 0 rows inserted/updated/deleted > ij> create table "t2"(a int ) ; > 0 rows inserted/updated/deleted > ij> -- this should fail. > create table foo (a int , \"YEAR\" int ) ; > ERROR 42X02: Lexical error at line 2, column 28. Encountered: "\\" (92), > after > : "". > ij> -- but this should not fail. But failing > create table t4 ( b int ) ; > ERROR 42X01: Syntax error: Encountered "" at line 2, column 21. > ij> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2103) After a Lexical Error due to syntax error , even a simple create table does not work on the same connection.
[
https://issues.apache.org/jira/browse/DERBY-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465138
]
Mayuresh Nirhali commented on DERBY-2103:
-
After some investigation, I found that, when the expected error happens,
lookingAhead flag in SQLParser implementation is true and due to the exception
this flag is not cleared. The parser object is cached and later used by the
next parsing activity. Following code demonstrates the scenario.
final private boolean jj_3_12() {
Token xsp;
xsp = jj_scanpos;
lookingAhead = true;
jj_semLA = getToken(3).kind != LARGE; // --- The exception happens in
this call
lookingAhead = false;// --- This is
not called due to the exception.
if (!jj_semLA || jj_3R_60()) return true;
if (jj_3R_61()) return true;
return false;
}
The simple fix could be to wrap the lookingAhead assignment after the call
within finally block.
then, the same method would look like below,
lookingAhead = true;
try { jj_semLA = getToken(3).kind != LARGE; }
finally { lookingAhead = false; }
I tried this and this has fixed the testcase.
Now, my concern is that, there are many such methods in SQLParser
implementation.For the fix to be complete and to be able to avoid future issues
due to same problem, all methods which should change needs to identified.
While, I am trying to do the same, I would really appreciate any inputs in this
regard.
Thanks,
Mayuresh
> After a Lexical Error due to syntax error ,even a simple create table
> does not work on the same connection.
>
>
> Key: DERBY-2103
> URL: https://issues.apache.org/jira/browse/DERBY-2103
> Project: Derby
> Issue Type: Bug
>Affects Versions: 10.3.0.0
>Reporter: Suresh Thalamati
> Assigned To: Mayuresh Nirhali
>Priority: Minor
>
> connect 'jdbc:derby:wombat;create=true';
> create table t1(a int ) ;
> create table "t2"(a int ) ;
> -- this should fail.
> create table foo (a int , \"YEAR\" int ) ;
> -- but this should not fail. But failing
> create table t4 ( b int ) ;
> FYI:
> $ java org.apache.derby.tools.ij
> ij version 10.3
> ij> run 'weird1.sql';
> ij> connect 'jdbc:derby:wombat;create=true';
> ij> create table t1(a int ) ;
> 0 rows inserted/updated/deleted
> ij> create table "t2"(a int ) ;
> 0 rows inserted/updated/deleted
> ij> -- this should fail.
> create table foo (a int , \"YEAR\" int ) ;
> ERROR 42X02: Lexical error at line 2, column 28. Encountered: "\\" (92),
> after
> : "".
> ij> -- but this should not fail. But failing
> create table t4 ( b int ) ;
> ERROR 42X01: Syntax error: Encountered "" at line 2, column 21.
> ij>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Questionable use of word in "VALUES expression" of Derby Reference Manual
Hello. See It is reason why I feel question that title of the page was "VALUE expression" and there was "VALUE statement". Then I feel question for the different word. Reading comment from others, however , I came to conclude that it is quite right that the words are different according to context which original writer thought . Then I will respect original usage and keep it as "statement" in translated manual. Thank you for your comments :) Best regards. Bernt M. Johnsen wrote: >Julius Stroffek wrote (2007-01-15 17:16:36): > > >>Hi Tomohito, >> >>I would say that the VALUES construct is a statement not an expression. >>The result and usage is similar like SELECT statement. >> >> > >In the SQL standard the construct > VALUES >is called a > > > > >>Cheers >> >>Julo >> >>TomohitoNakayama wrote: >> >> >>>Hello. >>> >>>I found next one sentence in "VALUES expression" of Derby Reference >>>Manual (http://db.apache.org/derby/docs/dev/ref/rrefsqlj11277.html) >>> >>> >>> >>> You use a VALUES statement when you do not have a FROM clause. >>>I think statement should be expression here but not completely sure >>>I hope opinion from others ... >>> >>>Best regards. >>> >>> >>> >>> > > > -- /* Tomohito Nakayama [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */
Re: Testing implementation of private classes
Kristian Waagan <[EMAIL PROTECTED]> writes: > Another proposal, which *I think* allow us to keep things as they are > and generate a separate jar file for unit tests requiring > package-private access: >Use the non-standard option -Xbootclasspath. > > By specifying the jars on the boot classpath, the sealing protection > will be overridden and the tests can be run. We can keep the existing > tests as they are, and only use this option when running the > "package-private unit tests". This approach also require two > (currently three) steps to run all tests, but we won't have to change > the existing jars. The unit tests can then also be run with > distribution jars if anyone should wish to do that, and with both sane > and insane builds. > > Does anyone see any showstoppers for this approach? Sounds like a win-win to me... -- dt
Regression Test Report - tinderbox_trunk16 496514 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk16* 496514/2007-01-15 23:02:41 CET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* SunOS-5.10_i86pc-i386 2513511 0 645.80% derbyall 065906590 0 337.52% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-496514.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/496514.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/496514.txt ( All results in http://dbtg.thresher.com/derby/test/ )
Re: Testing implementation of private classes
Daniel John Debrunner wrote: What's the benefit of running unit tests against jar files? For functional tests I see the benefit, it is testing the user api using artifacts the user is expected to have on the classpath. However for unit tests I can't see what bugs would be found by testing against classes that are in a "fake" jar (assuming the unit tests are run against classes as well). Actually, I can not see a really big difference on running unit tests and function tests. The errors discovered by unit test may not appear during a run of functional tests since the functional tests do not cover each and every situation it may happen during an execution. However this errors might show up to a user after some time or in a special case/deploy. So I see b) and c) as being the same really, manufacturing some fake jar (and for b it's more than derby.jar, may want to unit test network code for example) for no benefit. As an alternative I think the unit testing could easily be setup as a optional step in the build process. There could be an additional target in top level build.xml file that ran the unit tests against the classes and those that wanted could include it in their build process (e.g. a target all_with_unit_tests). Yes, this might be a sufficient solution. Julo
[jira] Updated: (DERBY-2191) Cleanup of FormatableBitSet
[ https://issues.apache.org/jira/browse/DERBY-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll updated DERBY-2191: -- Derby Info: [Patch Available] I've attached a patch (valuenotnull.v1) which ensures that the 'value' byte array never is null, and removes the now redundant null-checks. The default constructor initializes 'value' to a shared zero-length array instance taken from ReuseFactory Pleas review. > Cleanup of FormatableBitSet > --- > > Key: DERBY-2191 > URL: https://issues.apache.org/jira/browse/DERBY-2191 > Project: Derby > Issue Type: Improvement > Components: Miscellaneous >Affects Versions: 10.2.1.6 >Reporter: Dyre Tjeldvoll > Assigned To: Dyre Tjeldvoll >Priority: Trivial > Fix For: 10.3.0.0 > > Attachments: deadcode.v1.diff, deadcode.v2.diff, fbstst.v1.diff, > fbstst.v1.stat, FormatableBitSetTest.java, valuenotnull.v1.diff, > valuenotnull.v1.stat > > > The implementation of FormatableBitSet could be streamlined. Dead code can be > removed and the implementation of some methods can be simplified. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-2191) Cleanup of FormatableBitSet
[ https://issues.apache.org/jira/browse/DERBY-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll updated DERBY-2191: -- Attachment: valuenotnull.v1.stat valuenotnull.v1.diff > Cleanup of FormatableBitSet > --- > > Key: DERBY-2191 > URL: https://issues.apache.org/jira/browse/DERBY-2191 > Project: Derby > Issue Type: Improvement > Components: Miscellaneous >Affects Versions: 10.2.1.6 >Reporter: Dyre Tjeldvoll > Assigned To: Dyre Tjeldvoll >Priority: Trivial > Fix For: 10.3.0.0 > > Attachments: deadcode.v1.diff, deadcode.v2.diff, fbstst.v1.diff, > fbstst.v1.stat, FormatableBitSetTest.java, valuenotnull.v1.diff, > valuenotnull.v1.stat > > > The implementation of FormatableBitSet could be streamlined. Dead code can be > removed and the implementation of some methods can be simplified. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2166) Implement proper handling of SocketTimeoutException in DRDAConnThread
[ https://issues.apache.org/jira/browse/DERBY-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465098 ] Bernt M. Johnsen commented on DERBY-2166: - Thanks for the comments. Bryan: setSoTimeout() is done in the client thread on the socket only if timeSlice is set, so we will get SocketTimeoutException only in that case in DDMReader. Bryan & Knut: All your commets are of course right and I will rewrite my patch. > Implement proper handling of SocketTimeoutException in DRDAConnThread > - > > Key: DERBY-2166 > URL: https://issues.apache.org/jira/browse/DERBY-2166 > Project: Derby > Issue Type: Improvement > Components: Network Server >Reporter: Bernt M. Johnsen > Assigned To: Bernt M. Johnsen > Attachments: derby-2166.diff, derby-2166.stat > > > A timeout is set on the session socket (ClientThread) but the > SocketTimeoutException is not taken care of. Connections is therefore closed > down if derby.drda.timeSlice is set and the client idles longer then the > timeslice. See DERBY-1856 for more details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-2226) Move column bitset computation to IndexToBaseRowNode
[ https://issues.apache.org/jira/browse/DERBY-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen resolved DERBY-2226. --- Resolution: Fixed Fix Version/s: 10.3.0.0 Thank you for addressing my comments, Dyre. Patch v2 looks good. Committed revision 496645. > Move column bitset computation to IndexToBaseRowNode > > > Key: DERBY-2226 > URL: https://issues.apache.org/jira/browse/DERBY-2226 > Project: Derby > Issue Type: Improvement >Reporter: Dyre Tjeldvoll > Assigned To: Dyre Tjeldvoll >Priority: Trivial > Fix For: 10.3.0.0 > > Attachments: derby-2226.v1.diff, derby-2226.v1.stat, > derby-2226.v2.diff, derby-2226.v2.stat > > > The constructor for IndexRowToBaseRowResultSet > takes a bitset describing the columns coming from the heap and a > bitset describing the columns coming from the index. But in every > IndexRowToBaseRowResultSet one also has to compute _all_ referenced > columns (union of heap and index bitsets), and frequently also those > columns _only_ coming from the heap (set difference between heap and > index). > But the value of these "set products" seem _only_ to depend on objects > that are fixed at compile time (in IndexToBaseRowNode), so it would be > cleaner (and possibly more efficient) to compute these products there. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-2244) DatabaseMetaData.supportsExpressionsInOrderBy() returns false
[ https://issues.apache.org/jira/browse/DERBY-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saurabh Vyas reassigned DERBY-2244: --- Assignee: Saurabh Vyas > DatabaseMetaData.supportsExpressionsInOrderBy() returns false > - > > Key: DERBY-2244 > URL: https://issues.apache.org/jira/browse/DERBY-2244 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.0.0 >Reporter: Daniel John Debrunner > Assigned To: Saurabh Vyas >Priority: Minor > > Expressions in the ORDER BY clause were added by DERBY-134 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2166) Implement proper handling of SocketTimeoutException in DRDAConnThread
[
https://issues.apache.org/jira/browse/DERBY-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465084
]
Knut Anders Hatlen commented on DERBY-2166:
---
In DDMReader, wouldn't it be better to write
catch (SocketTimeoutException ...) {...}
catch (IOException ...) {...}
instead of
catch (IOException ioe) {
if (ioe instanceof SocketTimeoutException) {
...
} else {
...
}
}
?
> Implement proper handling of SocketTimeoutException in DRDAConnThread
> -
>
> Key: DERBY-2166
> URL: https://issues.apache.org/jira/browse/DERBY-2166
> Project: Derby
> Issue Type: Improvement
> Components: Network Server
>Reporter: Bernt M. Johnsen
> Assigned To: Bernt M. Johnsen
> Attachments: derby-2166.diff, derby-2166.stat
>
>
> A timeout is set on the session socket (ClientThread) but the
> SocketTimeoutException is not taken care of. Connections is therefore closed
> down if derby.drda.timeSlice is set and the client idles longer then the
> timeslice. See DERBY-1856 for more details.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
