Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.9.1.0
    • Component/s: Test
    • Labels:
    1. 5368-1.patch
      11 kB
      Houx Zhang
    2. 5368-1.stat
      0.6 kB
      Houx Zhang
    3. DERBY-5368-2.stat
      0.5 kB
      Myrna van Lunteren
    4. DERBY-5368-2.diff
      5 kB
      Myrna van Lunteren
    5. DERBY-5368-3.diff
      5 kB
      Myrna van Lunteren
    6. DERBY-5368-4.diff
      24 kB
      Myrna van Lunteren
    7. ij2b.out
      3 kB
      Bryan Pendleton

      Activity

      Hide
      Houx Zhang added a comment -

      In 5368-1.patch, ij2.sql and ij2.out has been changed as below:

      1. Add some empty line to adjust ScrtipTestCase.
      2. the ij2Test is decorated by TestConfiguration.singleUseDatabaseDecorator() to advoid non-English problem, just like in ImportExportIJTest. Besides, a "wombat1" is introduced to avoid a database name in form of "singleUse/oneuseXX" created by TestConfiguration.singleUseDatabaseDecorator() by auto.

      Now the patch runs well, for both ij2Test and tools._Suite. Please check it, thanks!

      Show
      Houx Zhang added a comment - In 5368-1.patch, ij2.sql and ij2.out has been changed as below: 1. Add some empty line to adjust ScrtipTestCase. 2. the ij2Test is decorated by TestConfiguration.singleUseDatabaseDecorator() to advoid non-English problem, just like in ImportExportIJTest. Besides, a "wombat1" is introduced to avoid a database name in form of "singleUse/oneuseXX" created by TestConfiguration.singleUseDatabaseDecorator() by auto. Now the patch runs well, for both ij2Test and tools._Suite. Please check it, thanks!
      Hide
      Bryan Pendleton added a comment -

      The patch runs well for me, too.

      I think we should figure out DERBY-5373 and DERBY-5374 before we move ahead with this patch, though,
      as perhaps the same issue will arise with this test.

      Do the changes made by DERBY-5346 need to be made to ij2Test.java?

      Lastly, Houx, can you please post the 'svn stat' that you are using, so I can double check my 'svn add' and 'svn del' commands? Thanks!

      Show
      Bryan Pendleton added a comment - The patch runs well for me, too. I think we should figure out DERBY-5373 and DERBY-5374 before we move ahead with this patch, though, as perhaps the same issue will arise with this test. Do the changes made by DERBY-5346 need to be made to ij2Test.java? Lastly, Houx, can you please post the 'svn stat' that you are using, so I can double check my 'svn add' and 'svn del' commands? Thanks!
      Hide
      Houx Zhang added a comment -

      Yes, Bryan, sorry to have forgotten to provide the .stat file. I will post it soon.

      And, in fact, the changes made by DERBY-5346 has been made to ij2Test.java in the first patch.

      As to DERBY-5373 and DERBY-5374, I don't have any phoneme or weme, so I hope someone familiar with the two platforms can give some suggestion.

      Show
      Houx Zhang added a comment - Yes, Bryan, sorry to have forgotten to provide the .stat file. I will post it soon. And, in fact, the changes made by DERBY-5346 has been made to ij2Test.java in the first patch. As to DERBY-5373 and DERBY-5374 , I don't have any phoneme or weme, so I hope someone familiar with the two platforms can give some suggestion.
      Hide
      Bryan Pendleton added a comment -

      Thank you for the stat file. I see the DERBY-5346-related lines in ij2Test.java, as you noted.

      I intend to move ahead with this patch; we can continue to work on the DERBY-5373 and
      DERBY-5374 problems independently of this.

      Show
      Bryan Pendleton added a comment - Thank you for the stat file. I see the DERBY-5346 -related lines in ij2Test.java, as you noted. I intend to move ahead with this patch; we can continue to work on the DERBY-5373 and DERBY-5374 problems independently of this.
      Hide
      Bryan Pendleton added a comment -

      Committed to the trunk as revision 1154813.

      Thank you for the contribution!

      Show
      Bryan Pendleton added a comment - Committed to the trunk as revision 1154813. Thank you for the contribution!
      Hide
      Houx Zhang added a comment -

      Thanks for you checking, Bryan.

      Show
      Houx Zhang added a comment - Thanks for you checking, Bryan.
      Hide
      Myrna van Lunteren added a comment -

      One of the premises for using a CanonTestCase (of which ScriptTestCase is a subclass) is that there is only one canon (master) file for a test. In the case of ij2, this was not true, there was ij2.out, but also j9_foundation/ij2.out.

      If I compare the two original canons (e.g. in the 10.8 branch) I get the following diff:
      --------
      168,169c168,169
      < CONNECTION0 - jdbc:derby:wombat
      < WOMBAT* - jdbc:derby:wombat

      > CONNECTION0
      > WOMBAT*
      173,174c173,174
      < CONNECTION0* - jdbc:derby:wombat
      < WOMBAT - jdbc:derby:wombat

      > CONNECTION0*
      > WOMBAT
      179c179
      < CONNECTION0 - jdbc:derby:wombat

      > CONNECTION0
      183c183
      < CONNECTION0* - jdbc:derby:wombat

      > CONNECTION0*
      --------

      In other words, the section that does the testing of the ij.protocol property (the section starting with '-- show multiconnect ability') shows 'jdbc:derby:wombat for non-JSR169 jvms, but no such addition for JSR169/J2ME/Foundation.

      The j9_foundation/ij2.out file has not been removed, but the junit framework does not know what to do about it, and so, the converted test fails now with JSR169, even with the section from DERBY-5346 in it.

      I tried playing a bit with various settings, but really there's no way to make the test behave the same. The ij.protocol (and originally, ij.database setting, which has been lost in the conversion) really do not mean anything in the context of a dataSource.
      I think the best thing to do, is to split off the multiconnect section into a separate .sql script.

      I'm reopening this issue to address this.

      Show
      Myrna van Lunteren added a comment - One of the premises for using a CanonTestCase (of which ScriptTestCase is a subclass) is that there is only one canon (master) file for a test. In the case of ij2, this was not true, there was ij2.out, but also j9_foundation/ij2.out. If I compare the two original canons (e.g. in the 10.8 branch) I get the following diff: -------- 168,169c168,169 < CONNECTION0 - jdbc:derby:wombat < WOMBAT* - jdbc:derby:wombat — > CONNECTION0 > WOMBAT* 173,174c173,174 < CONNECTION0* - jdbc:derby:wombat < WOMBAT - jdbc:derby:wombat — > CONNECTION0* > WOMBAT 179c179 < CONNECTION0 - jdbc:derby:wombat — > CONNECTION0 183c183 < CONNECTION0* - jdbc:derby:wombat — > CONNECTION0* -------- In other words, the section that does the testing of the ij.protocol property (the section starting with '-- show multiconnect ability') shows 'jdbc:derby:wombat for non-JSR169 jvms, but no such addition for JSR169/J2ME/Foundation. The j9_foundation/ij2.out file has not been removed, but the junit framework does not know what to do about it, and so, the converted test fails now with JSR169, even with the section from DERBY-5346 in it. I tried playing a bit with various settings, but really there's no way to make the test behave the same. The ij.protocol (and originally, ij.database setting, which has been lost in the conversion) really do not mean anything in the context of a dataSource. I think the best thing to do, is to split off the multiconnect section into a separate .sql script. I'm reopening this issue to address this.
      Hide
      Myrna van Lunteren added a comment -

      attaching a patch which splits off the multiconnect test case out of ij2.sql into a separate section, ij2b.sql, with matching .out file and a section in ij2Test.java which runs that only with vms that support jdbc 3 (and higher).

      This does also add the ij.database property testing back in, which causes an extra connection at start, which then gives the same result for the main section of the test for JSR169/J2ME and the other jvms. Also causes the multi connect test case to be a little different; i.e. it now has an extra connection (and connects to an existing database). I think this is ok, but will wait for a couple of days for comments before checking this in.

      Show
      Myrna van Lunteren added a comment - attaching a patch which splits off the multiconnect test case out of ij2.sql into a separate section, ij2b.sql, with matching .out file and a section in ij2Test.java which runs that only with vms that support jdbc 3 (and higher). This does also add the ij.database property testing back in, which causes an extra connection at start, which then gives the same result for the main section of the test for JSR169/J2ME and the other jvms. Also causes the multi connect test case to be a little different; i.e. it now has an extra connection (and connects to an existing database). I think this is ok, but will wait for a couple of days for comments before checking this in.
      Hide
      Bryan Pendleton added a comment -

      Hi Myrna, I think the approach seems good to me.

      Should the patch have included an ij2b.out file? Without it, I'm seeing a test failure.
      When I view the patch in my editor, the end of the file says:

      svn: File 'java\testing\org\apache\derbyTesting\functionTests\master\ij2.out' has inconsistent newlines
      svn: Inconsistent line ending style

      Perhaps there was an upload problem when you attached the patch?

      Show
      Bryan Pendleton added a comment - Hi Myrna, I think the approach seems good to me. Should the patch have included an ij2b.out file? Without it, I'm seeing a test failure. When I view the patch in my editor, the end of the file says: svn: File 'java\testing\org\apache\derbyTesting\functionTests\master\ij2.out' has inconsistent newlines svn: Inconsistent line ending style Perhaps there was an upload problem when you attached the patch?
      Hide
      Myrna van Lunteren added a comment -

      I did some manipulating on the ij2b.out, and made a new patch. I hope this works better?

      Show
      Myrna van Lunteren added a comment - I did some manipulating on the ij2b.out, and made a new patch. I hope this works better?
      Hide
      Houx Zhang added a comment - - edited

      Good work. I think it's better now. However, In DERBY-5368-2-1.stat, we see:

      M java\testing\org\apache\derbyTesting\functionTests\tests\tools\ij2.sql
      A java\testing\org\apache\derbyTesting\functionTests\tests\tools\ij2b.sql
      M java\testing\org\apache\derbyTesting\functionTests\tests\tools\ij2Test.java
      M java\testing\org\apache\derbyTesting\functionTests\master\ij2.out
      A java\testing\org\apache\derbyTesting\functionTests\master\ij2b.out
      D java\testing\org\apache\derbyTesting\functionTests\master\j9_foundation\ij2.out

      but, when do 'stat' on the project after patching DERBY-5368-3.diff, we get

      M .
      ? java\testing\org\apache\derbyTesting\functionTests\tests\tools\ij2b.sql
      M java\testing\org\apache\derbyTesting\functionTests\tests\tools\ij2.sql
      M java\testing\org\apache\derbyTesting\functionTests\tests\tools\ij2Test.java

      so, maybe DERBY-5368-3.diff has not committed all the modifications?

      Show
      Houx Zhang added a comment - - edited Good work. I think it's better now. However, In DERBY-5368 -2-1.stat, we see: M java\testing\org\apache\derbyTesting\functionTests\tests\tools\ij2.sql A java\testing\org\apache\derbyTesting\functionTests\tests\tools\ij2b.sql M java\testing\org\apache\derbyTesting\functionTests\tests\tools\ij2Test.java M java\testing\org\apache\derbyTesting\functionTests\master\ij2.out A java\testing\org\apache\derbyTesting\functionTests\master\ij2b.out D java\testing\org\apache\derbyTesting\functionTests\master\j9_foundation\ij2.out but, when do 'stat' on the project after patching DERBY-5368 -3.diff, we get M . ? java\testing\org\apache\derbyTesting\functionTests\tests\tools\ij2b.sql M java\testing\org\apache\derbyTesting\functionTests\tests\tools\ij2.sql M java\testing\org\apache\derbyTesting\functionTests\tests\tools\ij2Test.java so, maybe DERBY-5368 -3.diff has not committed all the modifications?
      Hide
      Bryan Pendleton added a comment -

      As retrieved on my machine, DERBY-5368-2.diff and DERBY-5368-3.diff are identical.

      Show
      Bryan Pendleton added a comment - As retrieved on my machine, DERBY-5368 -2.diff and DERBY-5368 -3.diff are identical.
      Hide
      Myrna van Lunteren added a comment -

      Re the status for applying the patch of DERBY-5368-3.diff, I think maybe you didn't undo the _2.diff patch? It's really strange to see a different result, because, as Bryan said, the patch is essentially the same. In my environment, files that in the patch have been marked for addition (A) do not actually get svn add-ed when I apply the patch, but they do get inserted in the tree. I have to manually svn add on them before they show up just like in the patch's stat file. Perhaps that's what you're seeing too? If I undo a patch, I always need to take care of physically removing the files that were added. At one point, someone sent a little utility to undo a patch, because of issues like this.

      I am puzzled about the line-ending trouble. After splitting off the ij2b.sql, I ran the test on my machine (Windows XP), and the first time it failed, it left the ij2b.out in the fail directory; and that's the file that I copied into the master directory. Then I did svn add, followed by svn propset svn:eol-style native. And the test passes on my box. I'm pretty sure I've done this before.
      After Bryan's report of trouble, I just ran cygwin's dos2unix and then unix2dos utilities on it, but diff didn't see a difference, and when I looked at it with an editor that shows line endings I didn't see a difference either.
      I'll play around with this on a linux machine, see if I get a different effect there.
      What kind of machine were you applying this on, Bryan?

      Show
      Myrna van Lunteren added a comment - Re the status for applying the patch of DERBY-5368 -3.diff, I think maybe you didn't undo the _2.diff patch? It's really strange to see a different result, because, as Bryan said, the patch is essentially the same. In my environment, files that in the patch have been marked for addition (A) do not actually get svn add-ed when I apply the patch, but they do get inserted in the tree. I have to manually svn add on them before they show up just like in the patch's stat file. Perhaps that's what you're seeing too? If I undo a patch, I always need to take care of physically removing the files that were added. At one point, someone sent a little utility to undo a patch, because of issues like this. I am puzzled about the line-ending trouble. After splitting off the ij2b.sql, I ran the test on my machine (Windows XP), and the first time it failed, it left the ij2b.out in the fail directory; and that's the file that I copied into the master directory. Then I did svn add, followed by svn propset svn:eol-style native. And the test passes on my box. I'm pretty sure I've done this before. After Bryan's report of trouble, I just ran cygwin's dos2unix and then unix2dos utilities on it, but diff didn't see a difference, and when I looked at it with an editor that shows line endings I didn't see a difference either. I'll play around with this on a linux machine, see if I get a different effect there. What kind of machine were you applying this on, Bryan?
      Hide
      Myrna van Lunteren added a comment -

      With apologies - I wasn't properly paying attention to what you both said. So here's another attempt at getting a correct patch.
      This one does have the ij2.out in it, no complaints about inconsistent line endings, and does look different from the -2 and -3 patch.

      It still has comments about no new line in the out files, but I believe that's ok.

      Show
      Myrna van Lunteren added a comment - With apologies - I wasn't properly paying attention to what you both said. So here's another attempt at getting a correct patch. This one does have the ij2.out in it, no complaints about inconsistent line endings, and does look different from the -2 and -3 patch. It still has comments about no new line in the out files, but I believe that's ok.
      Hide
      Bryan Pendleton added a comment -

      Patch 4 works better for me, but still does not pass in my environment. When I run the tools Suite (on Ubuntu Linux with JDK 1.6), I get:

      junit.framework.ComparisonFailure: Output at line 45 expected:<...> but was:<...-->

      I've attached the ij2b.out file that I get in my environment.

      Show
      Bryan Pendleton added a comment - Patch 4 works better for me, but still does not pass in my environment. When I run the tools Suite (on Ubuntu Linux with JDK 1.6), I get: junit.framework.ComparisonFailure: Output at line 45 expected:<...> but was:<...--> I've attached the ij2b.out file that I get in my environment.
      Hide
      Myrna van Lunteren added a comment - - edited

      Thanks for trying out the patch, Bryan.

      The ij2b.out that you attached has the contents twice, so I think perhaps you didn't remove the file before applying the last patch?

      Show
      Myrna van Lunteren added a comment - - edited Thanks for trying out the patch, Bryan. The ij2b.out that you attached has the contents twice, so I think perhaps you didn't remove the file before applying the last patch?
      Hide
      Myrna van Lunteren added a comment -

      No, that was off - it's ij2b.sql which must have the contents twice.

      Show
      Myrna van Lunteren added a comment - No, that was off - it's ij2b.sql which must have the contents twice.
      Hide
      Bryan Pendleton added a comment -

      Of course that was it, Myrna, thank you very much!

      The tests pass cleanly for me in my environment with the current patch (patch 4).

      Show
      Bryan Pendleton added a comment - Of course that was it, Myrna, thank you very much! The tests pass cleanly for me in my environment with the current patch (patch 4).
      Hide
      Myrna van Lunteren added a comment -

      Thanks Bryan, I committed that patch with revision 1156856.
      Resolving now, I'll close this again tomorrow after checking the nightly test runs.

      Show
      Myrna van Lunteren added a comment - Thanks Bryan, I committed that patch with revision 1156856. Resolving now, I'll close this again tomorrow after checking the nightly test runs.
      Hide
      Myrna van Lunteren added a comment -

      Closing this issue again; nightly tests showed no related failures & the ij2Test failure with weme6.2 is now gone also.

      Show
      Myrna van Lunteren added a comment - Closing this issue again; nightly tests showed no related failures & the ij2Test failure with weme6.2 is now gone also.

        People

        • Assignee:
          Houx Zhang
          Reporter:
          Houx Zhang
        • Votes:
          0 Vote for this issue
          Watchers:
          0 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved:

            Development