Derby
  1. Derby
  2. DERBY-1729

Invoking Java stored procedure that contains GRANT or REVOKE statement with CONTAINS SQL should fail.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.2.1.6
    • Fix Version/s: 10.2.1.6, 10.3.1.4
    • Component/s: SQL
    • Labels:
      None
    • Environment:
      Sun JDK 1.4.2
    • Urgency:
      Urgent

      Description

      In Derby SQL authorization mode, invoking Java stored procedure that contains GRANT or REVOKE statement with CONTAINS SQL from a trigger should fail but in the following test, it successfully executed the trigger action.
      Attaching repro patch for trunk.

      i.e.:

      ij> connect 'triggerProcSQLAuth;create=true' user 'APP' as app;
      WARNING 01J14: SQL authorization is being used without first enabling authentication.
      ij> — setup the environment
      — table used in the procedures
      create table t1 (i int primary key, b char(15));
      0 rows inserted/updated/deleted
      ij> insert into t1 values (1, 'XYZ');
      1 row inserted/updated/deleted
      ij> insert into t1 values (2, 'XYZ');
      1 row inserted/updated/deleted
      ij> — table used in this test
      create table t2 (x integer, y integer);
      0 rows inserted/updated/deleted
      ij> create procedure grant_select_proc()
      parameter style java
      dynamic result sets 0 language java
      contains sql
      external name 'org.apache.derbyTesting.functionTests.util.ProcedureTest.grantSelect';
      0 rows inserted/updated/deleted
      ij> create procedure revoke_select_proc()
      parameter style java
      dynamic result sets 0 language java
      contains sql
      external name 'org.apache.derbyTesting.functionTests.util.ProcedureTest.revokeSelect';
      0 rows inserted/updated/deleted
      ij> — tests
      create trigger grant_select_trig AFTER delete on t1
      for each STATEMENT mode db2sql call grant_select_proc();
      0 rows inserted/updated/deleted
      ij> — should fail
      delete from t1 where i = 1;
      1 row inserted/updated/deleted
      ij> — check delete failed
      select * from t1;
      I |B
      ---------------------------
      2 |XYZ
      1 row selected
      ij> — check if there are rows in sys.systableperms, should be 0
      select count from SYS.SYSTABLEPERMS;
      1
      -----------
      1
      1 row selected
      ij> drop trigger grant_select_trig;
      0 rows inserted/updated/deleted
      ij> create trigger revoke_select_trig AFTER delete on t1
      for each STATEMENT mode db2sql call revoke_select_proc();
      0 rows inserted/updated/deleted
      ij> — should fail
      delete from t1 where i = 2;
      1 row inserted/updated/deleted
      ij> — check delete failed
      select * from t1;
      I |B
      ---------------------------
      0 rows selected
      ij> — check if there are rows in sys.systableperms, should be 0
      select count from SYS.SYSTABLEPERMS;
      1
      -----------
      0
      1 row selected
      ij> drop trigger revoke_select_trig;
      0 rows inserted/updated/deleted
      ij>

      ------------------ Java Information ------------------
      Java Version: 1.4.2_12
      Java Vendor: Sun Microsystems Inc.
      Java home: C:\Program Files\Java\j2re1.4.2_12
      Java classpath: derby.jar;derbytools.jar
      OS name: Windows XP
      OS architecture: x86
      OS version: 5.1
      Java user name: Yip
      Java user home: C:\Documents and Settings\Yip
      Java user dir: C:\work3\derby\trunk\jars\sane
      java.specification.name: Java Platform API Specification
      java.specification.version: 1.4
      --------- Derby Information --------
      JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
      [C:\work3\derby\trunk\jars\sane\derby.jar] 10.3.0.0 alpha - (432670M)
      [C:\work3\derby\trunk\jars\sane\derbytools.jar] 10.3.0.0 alpha - (432670M)
      ------------------------------------------------------
      ----------------- Locale Information -----------------
      Current Locale : [English/United States [en_US]]
      Found support for locale: [de_DE]
      version: 10.3.0.0 alpha - (432670M)
      Found support for locale: [es]
      version: 10.3.0.0 alpha - (432670M)
      Found support for locale: [fr]
      version: 10.3.0.0 alpha - (432670M)
      Found support for locale: [it]
      version: 10.3.0.0 alpha - (432670M)
      Found support for locale: [ja_JP]
      version: 10.3.0.0 alpha - (432670M)
      Found support for locale: [ko_KR]
      version: 10.3.0.0 alpha - (432670M)
      Found support for locale: [pt_BR]
      version: 10.3.0.0 alpha - (432670M)
      Found support for locale: [zh_CN]
      version: 10.3.0.0 alpha - (432670M)
      Found support for locale: [zh_TW]
      version: 10.3.0.0 alpha - (432670M)
      ------------------------------------------------------

      1. derby1729-jdk16-master-diff.txt
        10 kB
        Yip Ng
      2. derby1729-trunk-diff03.txt
        21 kB
        Yip Ng
      3. derby1729-trunk-stat03.txt
        0.8 kB
        Yip Ng
      4. derby1729-trunk-diff02.txt
        29 kB
        Yip Ng
      5. derby1729-trunk-stat02.txt
        0.8 kB
        Yip Ng
      6. derby1729-trunk-diff01.txt
        26 kB
        Yip Ng
      7. derby1729-trunk-stat01.txt
        0.8 kB
        Yip Ng
      8. repro-trunk-diff01.txt
        4 kB
        Yip Ng

        Issue Links

          Activity

          Hide
          Satheesh Bandaram added a comment -

          Hmm... I have to think about this some more, but not sure why the trigger should fail.

          Show
          Satheesh Bandaram added a comment - Hmm... I have to think about this some more, but not sure why the trigger should fail.
          Hide
          Yip Ng added a comment -

          Hmm... shouldn't it? GRANT and REVOKE performs modification to the database and the above Java stored procedure grant_select_proc is declared with only CONTAINS SQL.

          Show
          Yip Ng added a comment - Hmm... shouldn't it? GRANT and REVOKE performs modification to the database and the above Java stored procedure grant_select_proc is declared with only CONTAINS SQL.
          Hide
          Satheesh Bandaram added a comment -

          Hmm... Correct. It should fail. Guess just invoking the procedure itself (outside a trigger) should fail. I was thinking about the link to trigger and GRANT statement. The problem is that procedure should always fail. Another missed negative test in the code.

          Show
          Satheesh Bandaram added a comment - Hmm... Correct. It should fail. Guess just invoking the procedure itself (outside a trigger) should fail. I was thinking about the link to trigger and GRANT statement. The problem is that procedure should always fail. Another missed negative test in the code.
          Hide
          Daniel John Debrunner added a comment -

          For the record: SQL standard 2003

          4.33.2.1 lists grant and revoke as SQL-schema statements

          4.33.3 defines SQL-schema statements as those that possibly modify SQL-data

          Thus GRANT/REVOKE within a procedure requires that MODIFIES SQL DATA.

          Show
          Daniel John Debrunner added a comment - For the record: SQL standard 2003 4.33.2.1 lists grant and revoke as SQL-schema statements 4.33.3 defines SQL-schema statements as those that possibly modify SQL-data Thus GRANT/REVOKE within a procedure requires that MODIFIES SQL DATA.
          Hide
          Daniel John Debrunner added a comment -

          I think this is because the GrantNode and RevokeNode should extend DDLStatementNode and not MiscellaneousStatementNode.

          Show
          Daniel John Debrunner added a comment - I think this is because the GrantNode and RevokeNode should extend DDLStatementNode and not MiscellaneousStatementNode.
          Hide
          Yip Ng added a comment -

          Yes, the GrantNode and RevokeNode should have derived from DDLStatementNode instead of MiscellaneousStatementNode. Subclassing DDLStatementNode will generate a call to GenericResultSetFactory's getDDLResultSet() in the activation class and invokes the GenericAuthorizer's
          authorize() method with the proper parameters to enforce the correct semantics.

          public ResultSet getDDLResultSet (Activation activation) throws StandardException

          { getAuthorizer(activation).authorize(activation, Authorizer.SQL_DDL_OP); return getMiscResultSet( activation); }
          Show
          Yip Ng added a comment - Yes, the GrantNode and RevokeNode should have derived from DDLStatementNode instead of MiscellaneousStatementNode. Subclassing DDLStatementNode will generate a call to GenericResultSetFactory's getDDLResultSet() in the activation class and invokes the GenericAuthorizer's authorize() method with the proper parameters to enforce the correct semantics. public ResultSet getDDLResultSet (Activation activation) throws StandardException { getAuthorizer(activation).authorize(activation, Authorizer.SQL_DDL_OP); return getMiscResultSet( activation); }
          Hide
          Yip Ng added a comment -

          Attaching patch derby1729-trunk-diff01.txt for DERBY-1729. This patch applies what I stated on my previous comment + additional sql file for derbylang. The reason I didn't include this in grantRevokeDDL.sql is because of name collision and this testcase is one of the many additonal grant/revoke tests that I wrote and I'll like to append the rest of those testcases to this file(grantRevokeDDL2.sql) when I submit my patch for DERBY-1736. Running derbyall now, please review.

          Show
          Yip Ng added a comment - Attaching patch derby1729-trunk-diff01.txt for DERBY-1729 . This patch applies what I stated on my previous comment + additional sql file for derbylang. The reason I didn't include this in grantRevokeDDL.sql is because of name collision and this testcase is one of the many additonal grant/revoke tests that I wrote and I'll like to append the rest of those testcases to this file(grantRevokeDDL2.sql) when I submit my patch for DERBY-1736 . Running derbyall now, please review.
          Hide
          Yip Ng added a comment -

          derbyall passes.

          Show
          Yip Ng added a comment - derbyall passes.
          Hide
          Mamta A. Satoor added a comment -

          Yip, I am still reviewing the patch. The engine code changes look good. But grantRevokeDDL2.sql has following
          +connect 'grantRevokeDDL2;create=true' user 'user1' as user1;
          +connect 'grantRevokeDDL2;create=true' user 'user1' as user3;
          +connect 'grantRevokeDDL2;create=true' user 'user1' as user3;
          +

          Did you intend to have same user name "as user3" for last 2 connections?

          Show
          Mamta A. Satoor added a comment - Yip, I am still reviewing the patch. The engine code changes look good. But grantRevokeDDL2.sql has following +connect 'grantRevokeDDL2;create=true' user 'user1' as user1; +connect 'grantRevokeDDL2;create=true' user 'user1' as user3; +connect 'grantRevokeDDL2;create=true' user 'user1' as user3; + Did you intend to have same user name "as user3" for last 2 connections?
          Hide
          Mamta A. Satoor added a comment -

          Yip, I just finished reviewing the patch fully.

          Further looking at the test, it seems like you were planning on creating another connection with user name as user2 and have the procedures grant and revoke privileges from that user.

          Some feedback on the test code changes
          1)Have a connection with user2 and test in the code that user2 can look at user1.t1 only after successful execution of grant_select_proc4() through the trigger code. Next, test that user2 can't look at user1.t1 anymore after successful execution of revoke_select_proc4() through the trigger code.

          2)Some comments in the test code will be useful, explaining why 6 out of 8 procedure invocatiions from trigger will fail. It makes sense in the mind frame of this jira entry but it will be beneficial for future new users of this test to know what exactly the test is testing w/o having to go through DERBY-1729.

          3)Comments in the test code explaining why we are checking SYSTABLEPERMS will be useful ie a row in SYSTABLEPERMS after delete means that grant statement inside the procedure worked correctly and user2 now has the SELECT privileges on user1.t1 Also, comment saying that the row in SYSTABLEPERMS should disappear after successful run of procedure with revoke statement in it.

          And finally, I think we should consider changing the description of this jira entry to remove excess information about triggers. Like Satheesh mentioned, procedure failure is not related to invocation from trigger. This would happen with stand alone procedures too.

          Show
          Mamta A. Satoor added a comment - Yip, I just finished reviewing the patch fully. Further looking at the test, it seems like you were planning on creating another connection with user name as user2 and have the procedures grant and revoke privileges from that user. Some feedback on the test code changes 1)Have a connection with user2 and test in the code that user2 can look at user1.t1 only after successful execution of grant_select_proc4() through the trigger code. Next, test that user2 can't look at user1.t1 anymore after successful execution of revoke_select_proc4() through the trigger code. 2)Some comments in the test code will be useful, explaining why 6 out of 8 procedure invocatiions from trigger will fail. It makes sense in the mind frame of this jira entry but it will be beneficial for future new users of this test to know what exactly the test is testing w/o having to go through DERBY-1729 . 3)Comments in the test code explaining why we are checking SYSTABLEPERMS will be useful ie a row in SYSTABLEPERMS after delete means that grant statement inside the procedure worked correctly and user2 now has the SELECT privileges on user1.t1 Also, comment saying that the row in SYSTABLEPERMS should disappear after successful run of procedure with revoke statement in it. And finally, I think we should consider changing the description of this jira entry to remove excess information about triggers. Like Satheesh mentioned, procedure failure is not related to invocation from trigger. This would happen with stand alone procedures too.
          Hide
          Daniel John Debrunner added a comment -

          Mamta wrote:

          "3)Comments in the test code explaining why we are checking SYSTABLEPERMS will be useful ie a row in SYSTABLEPERMS after delete means that grant statement inside the procedure worked correctly and user2 now has the SELECT privileges on user1.t1 Also, comment saying that the row in SYSTABLEPERMS should disappear after successful run of procedure with revoke statement in it. "

          Why use SYSTABLEPERMS as the test mechanism, this is an indirect test of the expected behaviour? Why not perform the actual test of seeing if the user can or cannot access the table etc, along with checking the expected successful or exception thrown by the procedure?

          Show
          Daniel John Debrunner added a comment - Mamta wrote: "3)Comments in the test code explaining why we are checking SYSTABLEPERMS will be useful ie a row in SYSTABLEPERMS after delete means that grant statement inside the procedure worked correctly and user2 now has the SELECT privileges on user1.t1 Also, comment saying that the row in SYSTABLEPERMS should disappear after successful run of procedure with revoke statement in it. " Why use SYSTABLEPERMS as the test mechanism, this is an indirect test of the expected behaviour? Why not perform the actual test of seeing if the user can or cannot access the table etc, along with checking the expected successful or exception thrown by the procedure?
          Hide
          Yip Ng added a comment -

          Thanks Mamta and Dan for your comments, I'll update the testcase and resubmit the patch with your suggestions.

          Show
          Yip Ng added a comment - Thanks Mamta and Dan for your comments, I'll update the testcase and resubmit the patch with your suggestions.
          Hide
          Yip Ng added a comment -

          Attaching derby1729-trunk-diff02.txt to addresses Mamta and Dan's suggestions on the testcase. Please review.

          Show
          Yip Ng added a comment - Attaching derby1729-trunk-diff02.txt to addresses Mamta and Dan's suggestions on the testcase. Please review.
          Hide
          Mamta A. Satoor added a comment -

          Yip, I see that test changes still have the SYSTABLEPERMS checks to see if the test is behaving as expected. I think we should remove it especially now that we check the test validity by connecting as user2 and checking select privilege on user1.t1

          Also, I wondered if you could address "Some comments in the test code will be useful, explaining why 6 out of 8 procedure invocatiions from trigger will fail. It makes sense in the mind frame of this jira entry but it will be beneficial for future new users of this test to know what exactly the test is testing w/o having to go through DERBY-1729. "? I do see an overall comment at the beginning of the test saying grant or revoke require MODIFIES SQL DATA, which is great, but a little more comments within the test explaining the reasons behind why something should fail or pass would be very nice.

          Show
          Mamta A. Satoor added a comment - Yip, I see that test changes still have the SYSTABLEPERMS checks to see if the test is behaving as expected. I think we should remove it especially now that we check the test validity by connecting as user2 and checking select privilege on user1.t1 Also, I wondered if you could address "Some comments in the test code will be useful, explaining why 6 out of 8 procedure invocatiions from trigger will fail. It makes sense in the mind frame of this jira entry but it will be beneficial for future new users of this test to know what exactly the test is testing w/o having to go through DERBY-1729 . "? I do see an overall comment at the beginning of the test saying grant or revoke require MODIFIES SQL DATA, which is great, but a little more comments within the test explaining the reasons behind why something should fail or pass would be very nice.
          Hide
          Yip Ng added a comment -

          Attaching derby1729-trunk-diff03.txt, add additional test comment + removing the sys.systableperms check since now we check the permission directly from another user connection.

          Show
          Yip Ng added a comment - Attaching derby1729-trunk-diff03.txt, add additional test comment + removing the sys.systableperms check since now we check the permission directly from another user connection.
          Hide
          Mamta A. Satoor added a comment -

          Yip, the changes look fine. +1 for commit

          Show
          Mamta A. Satoor added a comment - Yip, the changes look fine. +1 for commit
          Hide
          Mike Matrigali added a comment -

          I am going to run tests and look at committing this patch. If anyone else plans on reviewing the latest patch let me know - for this work I am counting on the review of others, but will verify that patch passes full set of tests before committing.

          Show
          Mike Matrigali added a comment - I am going to run tests and look at committing this patch. If anyone else plans on reviewing the latest patch let me know - for this work I am counting on the review of others, but will verify that patch passes full set of tests before committing.
          Hide
          Mike Matrigali added a comment -

          committed derby1729-trunk-diff03.txt patch to the trunk. Ran full set of tests successfully on XP, sun 1.4.2 jvm.

          m1_142:20>svn commit

          Sending java\engine\org\apache\derby\impl\sql\compile\GrantNode.java
          Sending java\engine\org\apache\derby\impl\sql\compile\RevokeNode.java
          Adding java\testing\org\apache\derbyTesting\functionTests\master\grantRevokeDDL2.out
          Sending java\testing\org\apache\derbyTesting\functionTests\suites\derbylang.runall
          Adding java\testing\org\apache\derbyTesting\functionTests\tests\lang\grantRevokeDDL2.sql
          Adding java\testing\org\apache\derbyTesting\functionTests\tests\lang\grantRevokeDDL2_app.properties
          Adding java\testing\org\apache\derbyTesting\functionTests\tests\lang\grantRevokeDDL2_sed.properties
          Sending java\testing\org\apache\derbyTesting\functionTests\util\ProcedureTest.java
          Transmitting file data ........
          Committed revision 441140.

          Show
          Mike Matrigali added a comment - committed derby1729-trunk-diff03.txt patch to the trunk. Ran full set of tests successfully on XP, sun 1.4.2 jvm. m1_142:20>svn commit Sending java\engine\org\apache\derby\impl\sql\compile\GrantNode.java Sending java\engine\org\apache\derby\impl\sql\compile\RevokeNode.java Adding java\testing\org\apache\derbyTesting\functionTests\master\grantRevokeDDL2.out Sending java\testing\org\apache\derbyTesting\functionTests\suites\derbylang.runall Adding java\testing\org\apache\derbyTesting\functionTests\tests\lang\grantRevokeDDL2.sql Adding java\testing\org\apache\derbyTesting\functionTests\tests\lang\grantRevokeDDL2_app.properties Adding java\testing\org\apache\derbyTesting\functionTests\tests\lang\grantRevokeDDL2_sed.properties Sending java\testing\org\apache\derbyTesting\functionTests\util\ProcedureTest.java Transmitting file data ........ Committed revision 441140.
          Hide
          Mike Matrigali added a comment -

          The nightly tests at:
          http://www.multinet.no/~solberg/public/Apache/DerbyJDK16/testlog/JDK16Jvm1.6SunOS-5.10_i86pc-i386/441155-derbylang_diff.txt
          Failed in the new regression test added here. I have included the diff below. I never saw the diff and it has passed in a number of environments since checked in. It may be 1.6 specific or environment specific . Let me know if it should be treated as a
          separate issue.

          Failure Details:

                          • Diff file derbylang/derbylang/grantRevokeDDL2.diff
              • Start: grantRevokeDDL2 jdk1.6.0-rc derbylang:derbylang 2006-09-07 20:28:40 ***
                98d97
                < ERROR: Failed with SQLSTATE 38000
                118d116
                < ERROR: Failed with SQLSTATE 38000
                138d135
                < ERROR: Failed with SQLSTATE 38000
                179d175
                < ERROR: Failed with SQLSTATE 38000
                202d197
                < ERROR: Failed with SQLSTATE 38000
                225d219
                < ERROR: Failed with SQLSTATE 38000
                Test Failed.
              • End: grantRevokeDDL2 jdk1.6.0-rc derbylang:derbylang 2006-09-07 20:28:46 ***
          Show
          Mike Matrigali added a comment - The nightly tests at: http://www.multinet.no/~solberg/public/Apache/DerbyJDK16/testlog/JDK16Jvm1.6SunOS-5.10_i86pc-i386/441155-derbylang_diff.txt Failed in the new regression test added here. I have included the diff below. I never saw the diff and it has passed in a number of environments since checked in. It may be 1.6 specific or environment specific . Let me know if it should be treated as a separate issue. Failure Details: Diff file derbylang/derbylang/grantRevokeDDL2.diff Start: grantRevokeDDL2 jdk1.6.0-rc derbylang:derbylang 2006-09-07 20:28:40 *** 98d97 < ERROR: Failed with SQLSTATE 38000 118d116 < ERROR: Failed with SQLSTATE 38000 138d135 < ERROR: Failed with SQLSTATE 38000 179d175 < ERROR: Failed with SQLSTATE 38000 202d197 < ERROR: Failed with SQLSTATE 38000 225d219 < ERROR: Failed with SQLSTATE 38000 Test Failed. End: grantRevokeDDL2 jdk1.6.0-rc derbylang:derbylang 2006-09-07 20:28:46 ***
          Hide
          Yip Ng added a comment -

          It looks like this is something specific to jdk16. If I run the same grantRevokeDDL2.sql test
          on jdk142, I don't see any diffs.

              • Start: grantRevokeDDL2 jdk1.6.0-beta2 2006-09-11 11:59:36 ***
                98d97
                < ERROR: Failed with SQLSTATE 38000
                118d116
                < ERROR: Failed with SQLSTATE 38000
                138d135
                < ERROR: Failed with SQLSTATE 38000
                179d175
                < ERROR: Failed with SQLSTATE 38000
                202d197
                < ERROR: Failed with SQLSTATE 38000
                225d219
                < ERROR: Failed with SQLSTATE 38000
                Test Failed.
              • End: grantRevokeDDL2 jdk1.6.0-beta2 2006-09-11 11:59:49 ***
          Show
          Yip Ng added a comment - It looks like this is something specific to jdk16. If I run the same grantRevokeDDL2.sql test on jdk142, I don't see any diffs. Start: grantRevokeDDL2 jdk1.6.0-beta2 2006-09-11 11:59:36 *** 98d97 < ERROR: Failed with SQLSTATE 38000 118d116 < ERROR: Failed with SQLSTATE 38000 138d135 < ERROR: Failed with SQLSTATE 38000 179d175 < ERROR: Failed with SQLSTATE 38000 202d197 < ERROR: Failed with SQLSTATE 38000 225d219 < ERROR: Failed with SQLSTATE 38000 Test Failed. End: grantRevokeDDL2 jdk1.6.0-beta2 2006-09-11 11:59:49 ***
          Hide
          Deepa Remesh added a comment -

          This is an issue with exception handling in jdk16. Reported as DERBY-1629. To temporarily resolve the regression test failure, we can add a new master file for jdk16. This was what was done for procedureInTrigger test.

          Show
          Deepa Remesh added a comment - This is an issue with exception handling in jdk16. Reported as DERBY-1629 . To temporarily resolve the regression test failure, we can add a new master file for jdk16. This was what was done for procedureInTrigger test.
          Hide
          Yip Ng added a comment -

          Thanks Deepa for the info. Attaching jdk16 specifc master file for grantRevokeDDL2.sql to temporarily resolve the diff issue.

          Show
          Yip Ng added a comment - Thanks Deepa for the info. Attaching jdk16 specifc master file for grantRevokeDDL2.sql to temporarily resolve the diff issue.
          Hide
          Mike Matrigali added a comment -

          linking to DERBY-1629, adding jdk16 specific master to work around DERBY-1629. These jdk specific masters add future maintenance workload to getting clean test runs in all environments in the future, so would be good to get rid of the specific master when DERBY-1629 is resolved.

          Show
          Mike Matrigali added a comment - linking to DERBY-1629 , adding jdk16 specific master to work around DERBY-1629 . These jdk specific masters add future maintenance workload to getting clean test runs in all environments in the future, so would be good to get rid of the specific master when DERBY-1629 is resolved.
          Hide
          Mike Matrigali added a comment -

          committed the jdk16 specific master:

          m3_16:81>svn commit

          Adding java\testing\org\apache\derbyTesting\functionTests\master\jdk16\grantRevokeDDL2.out
          Transmitting file data .
          Committed revision 446652.

          Show
          Mike Matrigali added a comment - committed the jdk16 specific master: m3_16:81>svn commit Adding java\testing\org\apache\derbyTesting\functionTests\master\jdk16\grantRevokeDDL2.out Transmitting file data . Committed revision 446652.
          Hide
          Andrew McIntyre added a comment -

          This issue has been resolved for over a year with no further movement. Closing.

          Show
          Andrew McIntyre added a comment - This issue has been resolved for over a year with no further movement. Closing.

            People

            • Assignee:
              Yip Ng
              Reporter:
              Yip Ng
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development