Details

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

      Description

      ImportExportIJTest fails in Chinese locale, just like below:

      D:\derby\test>java junit.textui.TestRunner org.apache.derbyTesting.functionTests
      .tests.tools.ImportExportIJTest
      .F
      Time: 7.937
      There was 1 failure:
      1) importExportIJ(org.apache.derbyTesting.functionTests.tests.tools.ImportExport
      IJTest)junit.framework.ComparisonFailure: Output at line 22 expected:<ERROR 42Y5
      5: ['DROP TABLE' cannot be performed on 'T1' because it does not exist.]> but wa
      s:<ERROR 42Y55: [?DROP TABLE?????T1????????????]>
      at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon
      (CanonTestCase.java:109)
      at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(Scr
      iptTestCase.java:201)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
      112)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
      at junit.extensions.TestSetup.run(TestSetup.java:27)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57
      )
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
      at junit.extensions.TestSetup.run(TestSetup.java:27)

      FAILURES!!!
      Tests run: 1, Failures: 1, Errors: 0

      1. d5217-resetLocalizedResourceCache.diff
        3 kB
        Knut Anders Hatlen
      2. DERBY-5217-1.patch
        1 kB
        Houx Zhang
      3. setDerbyUILocale.patch
        2 kB
        Bryan Pendleton
      4. DERBY-5217-log-setMessageLocale-eclipse.txt
        8 kB
        Houx Zhang
      5. DERBY-5217-log-setMessageLocale-DOS.txt
        9 kB
        Houx Zhang
      6. DERBY-5217-log-setMessageLocale.patch
        4 kB
        Houx Zhang
      7. output-for-more-prints.txt
        879 kB
        Houx Zhang
      8. morePrints.txt
        5 kB
        Bryan Pendleton
      9. DERBY-5217-StandardException.patch
        2 kB
        Houx Zhang
      10. DERBY-5217-log-LocalizedResource.patch
        6 kB
        Houx Zhang
      11. DERBY-5217-log-locale.patch
        4 kB
        Houx Zhang
      12. DERBY-5217-SystemPropertyTestSetup.patch
        2 kB
        Houx Zhang
      13. DERBY-5217-LocaleTestSetup.patch
        1 kB
        Houx Zhang

        Issue Links

          Activity

          Hide
          Houx Zhang added a comment -

          When I removed the derbyLocale_zh_CN.jar (I'm in Chinese locale), ImportExportIJTest passed. So, the failure should be related to the non-English locale.

          However, ImportExportIJTest still failed when I set a LocaleTestSetup or a SystemPropertyTestSetup, just like in the two patches.

          What should I do, please?

          Show
          Houx Zhang added a comment - When I removed the derbyLocale_zh_CN.jar (I'm in Chinese locale), ImportExportIJTest passed. So, the failure should be related to the non-English locale. However, ImportExportIJTest still failed when I set a LocaleTestSetup or a SystemPropertyTestSetup, just like in the two patches. What should I do, please?
          Hide
          Bryan Pendleton added a comment -

          It looks like ScriptTestCase has its own setUp/tearDown code that is trying to manipulate the Locale.

          Can you make a change to CanonTestCase.compareCanon() so that when it gets a failure, it
          also includes the value of the current Locale as part of the failure exception, so that we can
          tell what Locale is actually being used when you run your test?

          Show
          Bryan Pendleton added a comment - It looks like ScriptTestCase has its own setUp/tearDown code that is trying to manipulate the Locale. Can you make a change to CanonTestCase.compareCanon() so that when it gets a failure, it also includes the value of the current Locale as part of the failure exception, so that we can tell what Locale is actually being used when you run your test?
          Hide
          Houx Zhang added a comment -

          Hi, Bryan, Please see DERBY-5217-log-locale.patch, I have logged the locale. It's strange, the locale is always en_US, no matter in the original test code or setting a new locale.

          D:\derby\test>java junit.textui.TestRunner org.apache.derbyTesting.functionTests
          .tests.tools.ImportExportIJTest
          .scr LOCALE:en_US
          ij LOCALE:en_US
          can LOCALE:en_US
          F
          Time: 5.421
          There was 1 failure:
          1) importExportIJ(org.apache.derbyTesting.functionTests.tests.tools.ImportExport
          IJTest)junit.framework.ComparisonFailure: Output at line 22 expected:<ERROR 42Y5
          5: ['DROP TABLE' cannot be performed on 'T1' because it does not exist.]> but wa
          s:<ERROR 42Y55: [?DROP TABLE?????T1????????????]>
          at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon
          (CanonTestCase.java:110)
          at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(Scr
          iptTestCase.java:201)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
          112)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
          at junit.extensions.TestSetup.run(TestSetup.java:27)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57
          )
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
          at junit.extensions.TestSetup.run(TestSetup.java:27)

          FAILURES!!!
          Tests run: 1, Failures: 1, Errors: 0

          Show
          Houx Zhang added a comment - Hi, Bryan, Please see DERBY-5217 -log-locale.patch, I have logged the locale. It's strange, the locale is always en_US, no matter in the original test code or setting a new locale. D:\derby\test>java junit.textui.TestRunner org.apache.derbyTesting.functionTests .tests.tools.ImportExportIJTest .scr LOCALE:en_US ij LOCALE:en_US can LOCALE:en_US F Time: 5.421 There was 1 failure: 1) importExportIJ(org.apache.derbyTesting.functionTests.tests.tools.ImportExport IJTest)junit.framework.ComparisonFailure: Output at line 22 expected:<ERROR 42Y5 5: ['DROP TABLE' cannot be performed on 'T1' because it does not exist.] > but wa s:<ERROR 42Y55: [?DROP TABLE?????T1????????????] > at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon (CanonTestCase.java:110) at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(Scr iptTestCase.java:201) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java: 112) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:23) at junit.extensions.TestSetup.run(TestSetup.java:27) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57 ) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:23) at junit.extensions.TestSetup.run(TestSetup.java:27) FAILURES!!! Tests run: 1, Failures: 1, Errors: 0
          Hide
          Bryan Pendleton added a comment -

          Hello Houx,

          I'm not terribly familiar with how the ij tool performs its localization, so we will have
          to do some exploring of the code together.

          It looks like org/apache/derby/iapi/tools/i18n/LocalizedResource.java is a very
          important class for the ij localization support.

          I think that the LocalizedResource gets set up in ij at about line 91 of utilMain.java,
          by this code:

          LocalizedResource langUtil = LocalizedResource.getInstance();

          Also, I see this interesting comment in LocalizedResource.java:

          // Resets the 'local' field to null. This is not needed for normal
          // operations, however, when executing sql files in our junit tests, we use
          // the same jvm and thus the locale will get loaded only once, resulting
          // in trouble when testing the localization for ij.
          public static void resetLocalizedResourceCache()

          { local=null; }

          Perhaps ImportExportIJTest is not calling resetLocalizedResourceCache
          when it should?

          It looks like LocalizedResource has a useful toString() method that
          will print out lots of information about the localization configuration.

          Can you add some code to utilMain.java to do something like:

          System.out.println("ij localization = " + langUtil.toString());

          so we can see what localization the ij tool is using during the test?

          thanks,

          bryan

          Show
          Bryan Pendleton added a comment - Hello Houx, I'm not terribly familiar with how the ij tool performs its localization, so we will have to do some exploring of the code together. It looks like org/apache/derby/iapi/tools/i18n/LocalizedResource.java is a very important class for the ij localization support. I think that the LocalizedResource gets set up in ij at about line 91 of utilMain.java, by this code: LocalizedResource langUtil = LocalizedResource.getInstance(); Also, I see this interesting comment in LocalizedResource.java: // Resets the 'local' field to null. This is not needed for normal // operations, however, when executing sql files in our junit tests, we use // the same jvm and thus the locale will get loaded only once, resulting // in trouble when testing the localization for ij. public static void resetLocalizedResourceCache() { local=null; } Perhaps ImportExportIJTest is not calling resetLocalizedResourceCache when it should? It looks like LocalizedResource has a useful toString() method that will print out lots of information about the localization configuration. Can you add some code to utilMain.java to do something like: System.out.println("ij localization = " + langUtil.toString()); so we can see what localization the ij tool is using during the test? thanks, bryan
          Hide
          Houx Zhang added a comment -

          Hi, Bryan. Thanks for your advice, I have logged on LocalizedResource, and got the log below.

          ImportExportIJTest.setUp() locale=zh_CN
          ScriptTestCase.runTest() locale=toString()

          { locale=en encode=null messageFile=org.apache.derby.loc.toolsmessages resourceKey=derby.ui.locale enableLocalized=false dateSize=28 timeSize=18 timestampSize=23 }
          ij.runScript()---0-- locale=toString(){ locale=en encode=null messageFile=org.apache.derby.loc.toolsmessages resourceKey=derby.ui.locale enableLocalized=false dateSize=28 timeSize=18 timestampSize=23 }

          ij.runScript()---1-- locale=toString()

          { locale=en encode=null messageFile=org.apache.derby.loc.toolsmessages resourceKey=derby.ui.locale enableLocalized=false dateSize=28 timeSize=18 timestampSize=23 }
          ij.runScript()---2-- locale=toString(){ locale=en encode=null messageFile=org.apache.derby.loc.toolsmessages resourceKey=derby.ui.locale enableLocalized=false dateSize=28 timeSize=18 timestampSize=23 }

          ij.runScript()---3-- locale=toString()

          { locale=en encode=null messageFile=org.apache.derby.loc.toolsmessages resourceKey=derby.ui.locale enableLocalized=false dateSize=28 timeSize=18 timestampSize=23 }
          utilMain.goScript() locale=toString(){ locale=en encode=null messageFile=org.apache.derby.loc.toolsmessages resourceKey=derby.ui.locale enableLocalized=false dateSize=28 timeSize=18 timestampSize=23 }

          utilMain.runScriptGuts() locale=toString()

          { locale=en encode=null messageFile=org.apache.derby.loc.toolsmessages resourceKey=derby.ui.locale enableLocalized=false dateSize=28 timeSize=18 timestampSize=23 }

          ImportExportIJTest.tearDown() locale=en

          We can see, the original locale is zh_CN, but in the ScriptTestCase.runTest(), the locale has changed into en,

          and all the work in ij was in en Locale.

          Besise, from the setUp() and tearDown() in ScriptTestCase, the en Locale has been set, that's why all work in

          ScriptTestCase.runTest() is English locale.

          /**

          • Set up the new locale for the test
            */
            protected void setUp() {
            oldLocale = Locale.getDefault();

          AccessController.doPrivileged(new java.security.PrivilegedAction() {
          public Object run()

          { Locale.setDefault(Locale.ENGLISH); return null; }

          });
          }

          /**

          • Revert the locale back to the old one
            */
            protected void tearDown() throws Exception {
            super.tearDown();

          AccessController.doPrivileged(new java.security.PrivilegedAction() {
          public Object run()

          { Locale.setDefault(oldLocale); return null; }

          });
          }

          Considering my first comment on this issue, I think there is some thing wrong in the derbyLocale_zh_CN.jar.

          Besides, another interesting is when run ij based on the distribution of db-derby-10.7.1.1-bin, I got the

          error message on "drop table T1" is "错误 42Y55:“DROP TABLE”无法在“T1”上执行,因为它不存在。", which is

          the exact Chinese error meesage according to "'DROP TABLE' cannot be performed on 'T1' because it does not

          exist."

          ij> drop table T1;
          错误 42Y55:“DROP TABLE”无法在“T1”上执行,因为它不存在。

          Show
          Houx Zhang added a comment - Hi, Bryan. Thanks for your advice, I have logged on LocalizedResource, and got the log below. ImportExportIJTest.setUp() locale=zh_CN ScriptTestCase.runTest() locale=toString() { locale=en encode=null messageFile=org.apache.derby.loc.toolsmessages resourceKey=derby.ui.locale enableLocalized=false dateSize=28 timeSize=18 timestampSize=23 } ij.runScript()--- 0 -- locale=toString(){ locale=en encode=null messageFile=org.apache.derby.loc.toolsmessages resourceKey=derby.ui.locale enableLocalized=false dateSize=28 timeSize=18 timestampSize=23 } ij.runScript()--- 1 -- locale=toString() { locale=en encode=null messageFile=org.apache.derby.loc.toolsmessages resourceKey=derby.ui.locale enableLocalized=false dateSize=28 timeSize=18 timestampSize=23 } ij.runScript()--- 2 -- locale=toString(){ locale=en encode=null messageFile=org.apache.derby.loc.toolsmessages resourceKey=derby.ui.locale enableLocalized=false dateSize=28 timeSize=18 timestampSize=23 } ij.runScript()--- 3 -- locale=toString() { locale=en encode=null messageFile=org.apache.derby.loc.toolsmessages resourceKey=derby.ui.locale enableLocalized=false dateSize=28 timeSize=18 timestampSize=23 } utilMain.goScript() locale=toString(){ locale=en encode=null messageFile=org.apache.derby.loc.toolsmessages resourceKey=derby.ui.locale enableLocalized=false dateSize=28 timeSize=18 timestampSize=23 } utilMain.runScriptGuts() locale=toString() { locale=en encode=null messageFile=org.apache.derby.loc.toolsmessages resourceKey=derby.ui.locale enableLocalized=false dateSize=28 timeSize=18 timestampSize=23 } ImportExportIJTest.tearDown() locale=en We can see, the original locale is zh_CN, but in the ScriptTestCase.runTest(), the locale has changed into en, and all the work in ij was in en Locale. Besise, from the setUp() and tearDown() in ScriptTestCase, the en Locale has been set, that's why all work in ScriptTestCase.runTest() is English locale. /** Set up the new locale for the test */ protected void setUp() { oldLocale = Locale.getDefault(); AccessController.doPrivileged(new java.security.PrivilegedAction() { public Object run() { Locale.setDefault(Locale.ENGLISH); return null; } }); } /** Revert the locale back to the old one */ protected void tearDown() throws Exception { super.tearDown(); AccessController.doPrivileged(new java.security.PrivilegedAction() { public Object run() { Locale.setDefault(oldLocale); return null; } }); } Considering my first comment on this issue, I think there is some thing wrong in the derbyLocale_zh_CN.jar. Besides, another interesting is when run ij based on the distribution of db-derby-10.7.1.1-bin, I got the error message on "drop table T1" is "错误 42Y55:“DROP TABLE”无法在“T1”上执行,因为它不存在。", which is the exact Chinese error meesage according to "'DROP TABLE' cannot be performed on 'T1' because it does not exist." ij> drop table T1; 错误 42Y55:“DROP TABLE”无法在“T1”上执行,因为它不存在。
          Hide
          Bryan Pendleton added a comment -

          Hello Houx,

          I believe that the ij code to format and display the exception is around line 600 of utilMain.java:

          String st1 = JDBCDisplayUtil.mapNull(e.getSQLState(),langUtil.getTextMessage("IJ_NoSqls"));
          String st2 = JDBCDisplayUtil.mapNull(e.getMessage(),langUtil.getTextMessage("IJ_NoMess"));
          out.println(langUtil.getTextMessage("IJ_Erro012", st1, st2, errorCode));

          And I think that since your test results say ERROR 42Y55: [?DROP TABLE?????T1????????????],
          this means that the IJ exceptions are being formatted in the English locale, since that's where the
          word "ERROR" at the start of that output is coming from (UT_Error012=ERROR

          {0}

          :

          {1} {2}

          )

          I see that this ij code calls "e.getMessage()".

          Perhaps we should turn our attention to the code which is constructing and throwing the exception,
          it may be building the exception with the wrong data in the first place.

          I think this happens in DDLStatementNode.java, with the code:

          private TableDescriptor justGetDescriptor(TableName tableName)
          throws StandardException
          {
          String schemaName = tableName.getSchemaName();
          SchemaDescriptor sd = getSchemaDescriptor(schemaName);

          TableDescriptor td = getTableDescriptor(tableName.getTableName(), sd);

          if (td == null)

          { throw StandardException.newException(SQLState.LANG_OBJECT_DOES_NOT_EXIST, statementToString(), tableName); }

          return td;
          }

          Perhaps you might instrument this code path and see if you can see how StandardException.java
          is deciding which locale to use when it constructs the original exception?

          Show
          Bryan Pendleton added a comment - Hello Houx, I believe that the ij code to format and display the exception is around line 600 of utilMain.java: String st1 = JDBCDisplayUtil.mapNull(e.getSQLState(),langUtil.getTextMessage("IJ_NoSqls")); String st2 = JDBCDisplayUtil.mapNull(e.getMessage(),langUtil.getTextMessage("IJ_NoMess")); out.println(langUtil.getTextMessage("IJ_Erro012", st1, st2, errorCode)); And I think that since your test results say ERROR 42Y55: [?DROP TABLE?????T1????????????] , this means that the IJ exceptions are being formatted in the English locale, since that's where the word "ERROR" at the start of that output is coming from (UT_Error012=ERROR {0} : {1} {2} ) I see that this ij code calls "e.getMessage()". Perhaps we should turn our attention to the code which is constructing and throwing the exception, it may be building the exception with the wrong data in the first place. I think this happens in DDLStatementNode.java, with the code: private TableDescriptor justGetDescriptor(TableName tableName) throws StandardException { String schemaName = tableName.getSchemaName(); SchemaDescriptor sd = getSchemaDescriptor(schemaName); TableDescriptor td = getTableDescriptor(tableName.getTableName(), sd); if (td == null) { throw StandardException.newException(SQLState.LANG_OBJECT_DOES_NOT_EXIST, statementToString(), tableName); } return td; } Perhaps you might instrument this code path and see if you can see how StandardException.java is deciding which locale to use when it constructs the original exception?
          Hide
          Houx Zhang added a comment -

          Hi, Bryan. I agree with StandardException.java is the key to this question. I have added DERBY-5217-StandardException.patch. In this patch, Locale is logged in StandardException, however, the locale is also Locale.en_US, but the printStackTrace() has given "ERROR 42Y55: “

          {0}

          ”无法在“

          {1}

          ”上执行,因为它不存在。", So, I think maybe Chinese resource for Exceptions has been loaded, then Maybe the next step is to find out when and how the resource for Exceptions has been loaded.

          Show
          Houx Zhang added a comment - Hi, Bryan. I agree with StandardException.java is the key to this question. I have added DERBY-5217 -StandardException.patch. In this patch, Locale is logged in StandardException, however, the locale is also Locale.en_US, but the printStackTrace() has given "ERROR 42Y55: “ {0} ”无法在“ {1} ”上执行,因为它不存在。", So, I think maybe Chinese resource for Exceptions has been loaded, then Maybe the next step is to find out when and how the resource for Exceptions has been loaded.
          Hide
          Bryan Pendleton added a comment -

          Are you running your tests using JDK 1.6? Can you try running them with JDK 1.4 or JDK 1.5?

          Also, you noted earlier that you can control this behavior by including/excluding the
          derbyLocale_zh_CN.jar in your CLASSPATH. Perhaps there is some way to build
          a custom version of the classes in that jar, such that they dump a stack trace when
          they are accessed? That way, we could see what code is accessing those methods
          and figure out who is calling it.

          Show
          Bryan Pendleton added a comment - Are you running your tests using JDK 1.6? Can you try running them with JDK 1.4 or JDK 1.5? Also, you noted earlier that you can control this behavior by including/excluding the derbyLocale_zh_CN.jar in your CLASSPATH. Perhaps there is some way to build a custom version of the classes in that jar, such that they dump a stack trace when they are accessed? That way, we could see what code is accessing those methods and figure out who is calling it.
          Hide
          Houx Zhang added a comment -

          I have running it just in JDK1.6, but got the same result with the compiler levels of 1.5 and 1.4.

          Where to locate int18l resource, please? I have search the printed message '因为它不存在' in the derby project, but have found nothing.

          Show
          Houx Zhang added a comment - I have running it just in JDK1.6, but got the same result with the compiler levels of 1.5 and 1.4. Where to locate int18l resource, please? I have search the printed message '因为它不存在' in the derby project, but have found nothing.
          Hide
          Bryan Pendleton added a comment -

          From: dag.wanvik@oracle.com (Dag H. Wanvik), via derby-dev:

          Should be in java/engine/org/apache/derby/loc/messages_zh_CN.properties
          I guess, but in there the strings are quoted in ASCII, i.e.

          42Y55=\u201C

          {0}

          \u201D\u65E0\u6CD5\u5728\u201C

          {1}

          \u201D\u4E0A\u6267\u884C\uFF0C\u56E0\u4E3A\u5B83\u4E0D\u5B58\u5728\u3002

          e.g. 无 is encoded as \u65E0 above.

          http://unicode.org/cgi-bin/GetUnihanData.pl?codepoint=65E0

          Thanks,
          Dag

          Show
          Bryan Pendleton added a comment - From: dag.wanvik@oracle.com (Dag H. Wanvik), via derby-dev: Should be in java/engine/org/apache/derby/loc/messages_zh_CN.properties I guess, but in there the strings are quoted in ASCII, i.e. 42Y55=\u201C {0} \u201D\u65E0\u6CD5\u5728\u201C {1} \u201D\u4E0A\u6267\u884C\uFF0C\u56E0\u4E3A\u5B83\u4E0D\u5B58\u5728\u3002 e.g. 无 is encoded as \u65E0 above. http://unicode.org/cgi-bin/GetUnihanData.pl?codepoint=65E0 Thanks, Dag
          Hide
          Bryan Pendleton added a comment -

          Hello Houx, have you had a chance to study this problem some more?

          Show
          Bryan Pendleton added a comment - Hello Houx, have you had a chance to study this problem some more?
          Hide
          Houx Zhang added a comment -

          Yes, Bryan. I have studied on this issue, but make little progress.

          I guess this issue has exposed a hidden bug in i18l, but I can not catch it smartly. I need more help on it, and hope to push it forwards.

          Where is the entry function to load the i18l, and what's function to change the resource, please?

          Thanks very much!

          Show
          Houx Zhang added a comment - Yes, Bryan. I have studied on this issue, but make little progress. I guess this issue has exposed a hidden bug in i18l, but I can not catch it smartly. I need more help on it, and hope to push it forwards. Where is the entry function to load the i18l, and what's function to change the resource, please? Thanks very much!
          Hide
          Bryan Pendleton added a comment -

          Houx, can you please try downloading and applying the attached 'morePrints.txt' patch, and then running

          java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.tools.ImportExportIJTest >/tmp/t 2>&1

          in your environment, and then post the output that gets written to the '/tmp/t' file?

          I tried adding some additional print statements to MessageService.java, and to BaseMonitor.getBundle(), to see if we could better understand how the locale is being chosen. Thanks!

          Show
          Bryan Pendleton added a comment - Houx, can you please try downloading and applying the attached 'morePrints.txt' patch, and then running java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.tools.ImportExportIJTest >/tmp/t 2>&1 in your environment, and then post the output that gets written to the '/tmp/t' file? I tried adding some additional print statements to MessageService.java, and to BaseMonitor.getBundle(), to see if we could better understand how the locale is being chosen. Thanks!
          Hide
          Houx Zhang added a comment -

          Thanks for your supports, Bryan.

          I have applied morePrints.txt, and run the command in DOS, and got the output file in out-for-more-prints.txt. It's a big file , and hope it's helpful.

          Show
          Houx Zhang added a comment - Thanks for your supports, Bryan. I have applied morePrints.txt, and run the command in DOS, and got the output file in out-for-more-prints.txt. It's a big file , and hope it's helpful.
          Hide
          Bryan Pendleton added a comment -

          Yes, the traces are very interesting! The most important part appears to be around line 1975 in the trace output, where we see:

          .-----000-----loc of StandardException:en_US
          ------------loc of StandardException:en_US
          ------------StandardException.getMessage() locale is:en_US
          ------------StandardException.getMessage() calling MessageService
          MessageService.getCompleteMessage(42Y55, arguments)
          BaseMonitor.getBundle(messageId=42Y55, messageLocale=zh_CN
          MessageService.formatMessage(java.util.PropertyResourceBundle@229ed4,42Y55, arguments, true)
          : bundle locale is zh_CN
          ------------StandardException.getMessage() returning: ¡°

          {0}¡±ÎÞ·¨ÔÚ¡°{1}¡±ÉÏÖ´ÐУ¬ÒòΪËü²»´æÔÚ¡£
          ERROR null: ¡°{0}

          ¡±ÎÞ·¨ÔÚ¡°

          {1}

          ¡±ÉÏÖ´ÐУ¬ÒòΪËü²»´æÔÚ¡£
          at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:308)
          at org.apache.derby.impl.sql.compile.DDLStatementNode.justGetDescriptor(DDLStatementNode.java:367)
          at org.apache.derby.impl.sql.compile.DDLStatementNode.getTableDescriptor(DDLStatementNode.java:337)
          at org.apache.derby.impl.sql.compile.DDLStatementNode.getTableDescriptor(DDLStatementNode.java:289)
          at org.apache.derby.impl.sql.compile.DropTableNode.bindStatement(DropTableNode.java:97)
          at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:327)
          at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:93)
          at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:1103)
          at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:610)
          at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:559)
          at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:367)
          at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:521)
          at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:363)
          at org.apache.derby.impl.tools.ij.utilMain.goScript(utilMain.java:279)
          at org.apache.derby.tools.ij.runScript(ij.java:124)
          at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptTestCase.java:188)
          at junit.framework.TestCase.runBare(TestCase.java:134)

          It looks like BaseMonitor.getBundle() is returning the Chinese bundle, even though the system locale has been set to en_us.

          This appears to happen because the ContextManager class has remembered the message locale
          in its 'messageLocale' variable, which was set very early in the test to the default initial locale (Chinese)
          when the auto-loaded driver needed to lookup messages during initial bootup.

          I see that the ContextManager class has a method "setMessageLocale()" that appears to be
          designed to allow higher levels of the system to reset the message locale.

          But I searched the code tree and I can't find any code that calls this method.

          I am wondering if we need to change LocaleTestSetup.setUp() so that it calls ContextManager.setMessageLocale(),
          and whether that would help the test.

          Can you try going to about line 49 of LocaleTestSetup.java, right after the line

          Locale.setDefault(newLocale);

          and add something like:

          ContextService.getFactory().getCurrentContextManager().setMessageLocale(newLocale.toString());

          Hopefully that code will force the ContextManager class to start using the English locale for message
          lookup for subsequent messages.

          Show
          Bryan Pendleton added a comment - Yes, the traces are very interesting! The most important part appears to be around line 1975 in the trace output, where we see: .----- 000 -----loc of StandardException:en_US ------------loc of StandardException:en_US ------------StandardException.getMessage() locale is:en_US ------------StandardException.getMessage() calling MessageService MessageService.getCompleteMessage(42Y55, arguments) BaseMonitor.getBundle(messageId=42Y55, messageLocale=zh_CN MessageService.formatMessage(java.util.PropertyResourceBundle@229ed4,42Y55, arguments, true) : bundle locale is zh_CN ------------StandardException.getMessage() returning: ¡° {0}¡±ÎÞ·¨ÔÚ¡°{1}¡±ÉÏÖ´ÐУ¬ÒòΪËü²»´æÔÚ¡£ ERROR null: ¡°{0} ¡±ÎÞ·¨ÔÚ¡° {1} ¡±ÉÏÖ´ÐУ¬ÒòΪËü²»´æÔÚ¡£ at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:308) at org.apache.derby.impl.sql.compile.DDLStatementNode.justGetDescriptor(DDLStatementNode.java:367) at org.apache.derby.impl.sql.compile.DDLStatementNode.getTableDescriptor(DDLStatementNode.java:337) at org.apache.derby.impl.sql.compile.DDLStatementNode.getTableDescriptor(DDLStatementNode.java:289) at org.apache.derby.impl.sql.compile.DropTableNode.bindStatement(DropTableNode.java:97) at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:327) at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:93) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:1103) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:610) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:559) at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:367) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:521) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:363) at org.apache.derby.impl.tools.ij.utilMain.goScript(utilMain.java:279) at org.apache.derby.tools.ij.runScript(ij.java:124) at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptTestCase.java:188) at junit.framework.TestCase.runBare(TestCase.java:134) It looks like BaseMonitor.getBundle() is returning the Chinese bundle, even though the system locale has been set to en_us. This appears to happen because the ContextManager class has remembered the message locale in its 'messageLocale' variable, which was set very early in the test to the default initial locale (Chinese) when the auto-loaded driver needed to lookup messages during initial bootup. I see that the ContextManager class has a method "setMessageLocale()" that appears to be designed to allow higher levels of the system to reset the message locale. But I searched the code tree and I can't find any code that calls this method. I am wondering if we need to change LocaleTestSetup.setUp() so that it calls ContextManager.setMessageLocale(), and whether that would help the test. Can you try going to about line 49 of LocaleTestSetup.java, right after the line Locale.setDefault(newLocale); and add something like: ContextService.getFactory().getCurrentContextManager().setMessageLocale(newLocale.toString()); Hopefully that code will force the ContextManager class to start using the English locale for message lookup for subsequent messages.
          Hide
          Houx Zhang added a comment -

          Hi, Bryan. I have added the code line :
          ContextService.getFactory().getCurrentContextManager().setMessageLocale(newLocale.toString());
          in ScriptTestCase in DERBY-5217-log-setMessageLocale.patch, which is subclass of ImportExportIJTest.java.

          And It's very strange. The test passed in my Eclipse in Windows, but still failed in DOS, and giving the identical output (in DERBY-5217-log-setMessageLocale.txt) in the two environment.

          ps: I have restarted my computer to run test in DOS to avoid affection of the same jvm, and get the identical result.

          Show
          Houx Zhang added a comment - Hi, Bryan. I have added the code line : ContextService.getFactory().getCurrentContextManager().setMessageLocale(newLocale.toString()); in ScriptTestCase in DERBY-5217 -log-setMessageLocale.patch, which is subclass of ImportExportIJTest.java. And It's very strange. The test passed in my Eclipse in Windows, but still failed in DOS, and giving the identical output (in DERBY-5217 -log-setMessageLocale.txt) in the two environment. ps: I have restarted my computer to run test in DOS to avoid affection of the same jvm, and get the identical result.
          Hide
          Bryan Pendleton added a comment -

          Perhaps we could change LocaleTestSetup as follows:

          Index: java/testing/org/apache/derbyTesting/junit/LocaleTestSetup.java
          ===================================================================
          — java/testing/org/apache/derbyTesting/junit/LocaleTestSetup.java (revision 1131297)
          +++ java/testing/org/apache/derbyTesting/junit/LocaleTestSetup.java (working copy)
          @@ -47,6 +47,9 @@
          (new java.security.PrivilegedAction() {
          public Object run()

          { Locale.setDefault(newLocale); + System.getProperties().setProperty( + "derby.ui.locale", + newLocale.getLanguage()); return null; }

          }

          The idea is that, whenever LocaleTestSetup sets the JDK Locale in a certain way,
          it should also set the derby.ui.locale to the same setting.

          Perhaps the differing results that you are seeing in different configurations has
          to do with whether derby.ui.locale is set in the test or not? I think that the software
          checks both the system locale and the derby.ui.locale variable, so if we set
          one, we should set both.

          Show
          Bryan Pendleton added a comment - Perhaps we could change LocaleTestSetup as follows: Index: java/testing/org/apache/derbyTesting/junit/LocaleTestSetup.java =================================================================== — java/testing/org/apache/derbyTesting/junit/LocaleTestSetup.java (revision 1131297) +++ java/testing/org/apache/derbyTesting/junit/LocaleTestSetup.java (working copy) @@ -47,6 +47,9 @@ (new java.security.PrivilegedAction() { public Object run() { Locale.setDefault(newLocale); + System.getProperties().setProperty( + "derby.ui.locale", + newLocale.getLanguage()); return null; } } The idea is that, whenever LocaleTestSetup sets the JDK Locale in a certain way, it should also set the derby.ui.locale to the same setting. Perhaps the differing results that you are seeing in different configurations has to do with whether derby.ui.locale is set in the test or not? I think that the software checks both the system locale and the derby.ui.locale variable, so if we set one, we should set both.
          Hide
          Bryan Pendleton added a comment -

          Here's a revised version of the original patch, with the proposed change to LocaleTestSetup included.

          Show
          Bryan Pendleton added a comment - Here's a revised version of the original patch, with the proposed change to LocaleTestSetup included.
          Hide
          Houx Zhang added a comment -

          Hi, Bryan. I have applied the patch, but it doesn't help. We still got the same wrong message.

          This issue is too troublesome.

          Show
          Houx Zhang added a comment - Hi, Bryan. I have applied the patch, but it doesn't help. We still got the same wrong message. This issue is too troublesome.
          Hide
          Bryan Pendleton added a comment -

          What is the exact syntax of the command that I can run to see the failure on my machine?

          Show
          Bryan Pendleton added a comment - What is the exact syntax of the command that I can run to see the failure on my machine?
          Hide
          Houx Zhang added a comment -

          Hi Bryan, I just ran 'java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.tools.ImportExportIJTest' in my environment, which is Chinese.

          I think you can ran 'java -Dderby.ui.locale=zh_CN junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.tools.ImportExportIJTest' to get a Chinese Locale.

          Show
          Houx Zhang added a comment - Hi Bryan, I just ran 'java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.tools.ImportExportIJTest' in my environment, which is Chinese. I think you can ran 'java -Dderby.ui.locale=zh_CN junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.tools.ImportExportIJTest' to get a Chinese Locale.
          Hide
          Houx Zhang added a comment -

          A new hint, even I ran 'java -Dderby.ui.locale=en_US junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.tools.ImportExportIJTest' in my environment, I still get the same error:

          D:\derby\test>java -Dderby.ui.locale=en_US junit.textui.TestRunner org.apache.de
          rbyTesting.functionTests.tests.tools.ImportExportIJTest
          .F
          Time: 10.062
          There was 1 failure:
          1) importExportIJ(org.apache.derbyTesting.functionTests.tests.tools.ImportExport
          IJTest)junit.framework.ComparisonFailure: Output at line 22 expected:<ERROR 42Y5
          5: ['DROP TABLE' cannot be performed on 'T1' because it does not exist.]> but wa
          s:<ERROR 42Y55: [?DROP TABLE?????T1????????????]>
          at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon
          (CanonTestCase.java:109)
          at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(Scr
          iptTestCase.java:201)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
          112)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
          at junit.extensions.TestSetup.run(TestSetup.java:27)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57
          )
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
          at junit.extensions.TestSetup.run(TestSetup.java:27)

          FAILURES!!!
          Tests run: 1, Failures: 1, Errors: 0

          Show
          Houx Zhang added a comment - A new hint, even I ran 'java -Dderby.ui.locale=en_US junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.tools.ImportExportIJTest' in my environment, I still get the same error: D:\derby\test>java -Dderby.ui.locale=en_US junit.textui.TestRunner org.apache.de rbyTesting.functionTests.tests.tools.ImportExportIJTest .F Time: 10.062 There was 1 failure: 1) importExportIJ(org.apache.derbyTesting.functionTests.tests.tools.ImportExport IJTest)junit.framework.ComparisonFailure: Output at line 22 expected:<ERROR 42Y5 5: ['DROP TABLE' cannot be performed on 'T1' because it does not exist.] > but wa s:<ERROR 42Y55: [?DROP TABLE?????T1????????????] > at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon (CanonTestCase.java:109) at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(Scr iptTestCase.java:201) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java: 112) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:23) at junit.extensions.TestSetup.run(TestSetup.java:27) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57 ) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:23) at junit.extensions.TestSetup.run(TestSetup.java:27) FAILURES!!! Tests run: 1, Failures: 1, Errors: 0
          Hide
          Rick Hillegas added a comment -

          Sorry to join the conversation so late. I'm confused about what the goal here is. The importExportIJ test was converted to JUnit via the trick of just wrapping the old canon-based test in some extra framework. At the end of the day, it is still a canon-based test rather than an assertion-based test. It's just running under JUnit now. To make a canon-based test run in a non-English locale, you have to supply a non-English canon alongside the English canon. Have we even built machinery to support multiple, language-specific canons for our tests? Do we really want to supply 13 canons for this test, one for each of the localizations Derby provides?

          It seems to me that a better way to "make ImportExportIJTest pass in non-English locale" is to rewrite the test so that it is assertion-based, not canon-based, and to check for SQLStates rather than message strings, as we do in our genuine assertion-based JUnit tests.

          Sorry if I am off-base, but I am very confused about what is being attempted here. Thanks.

          Show
          Rick Hillegas added a comment - Sorry to join the conversation so late. I'm confused about what the goal here is. The importExportIJ test was converted to JUnit via the trick of just wrapping the old canon-based test in some extra framework. At the end of the day, it is still a canon-based test rather than an assertion-based test. It's just running under JUnit now. To make a canon-based test run in a non-English locale, you have to supply a non-English canon alongside the English canon. Have we even built machinery to support multiple, language-specific canons for our tests? Do we really want to supply 13 canons for this test, one for each of the localizations Derby provides? It seems to me that a better way to "make ImportExportIJTest pass in non-English locale" is to rewrite the test so that it is assertion-based, not canon-based, and to check for SQLStates rather than message strings, as we do in our genuine assertion-based JUnit tests. Sorry if I am off-base, but I am very confused about what is being attempted here. Thanks.
          Hide
          Bryan Pendleton added a comment -

          Hi Rick, thanks for the ideas.

          I believe what we were attempting was to go the other direction, to "force" the test to run
          in a mode where ij emits output in English, so that it matches the canon, even if the
          tester's external environment (and other tests being run in the same suite(s)) is configured
          to run in a non-English locale.

          I agree with you that performing a full conversion to a assertion-based style would be
          wonderful; we thought we were doing something simpler, but it has proved hard to
          understand how to control ij's notion of the current locale in order to force it to run in
          English, rather than Chinese, locale.

          Show
          Bryan Pendleton added a comment - Hi Rick, thanks for the ideas. I believe what we were attempting was to go the other direction, to "force" the test to run in a mode where ij emits output in English, so that it matches the canon, even if the tester's external environment (and other tests being run in the same suite(s)) is configured to run in a non-English locale. I agree with you that performing a full conversion to a assertion-based style would be wonderful; we thought we were doing something simpler, but it has proved hard to understand how to control ij's notion of the current locale in order to force it to run in English, rather than Chinese, locale.
          Hide
          Bryan Pendleton added a comment -

          Can you change the test so that, if the locale is not English, we skip the test?

          That would not be ideal, but at least it would allow us to confirm that all of the
          other tests in the overall test suite now pass correctly when run in your environment.

          Perhaps the cleanest way to do this would be to change org.apache.derbyTesting.functionTests.tools._Suite
          so that it skips the suite.addTest() call if the locale is not English.

          Show
          Bryan Pendleton added a comment - Can you change the test so that, if the locale is not English, we skip the test? That would not be ideal, but at least it would allow us to confirm that all of the other tests in the overall test suite now pass correctly when run in your environment. Perhaps the cleanest way to do this would be to change org.apache.derbyTesting.functionTests.tools._Suite so that it skips the suite.addTest() call if the locale is not English.
          Hide
          Houx Zhang added a comment -

          Hi, Bryan. I have adding locale checking in tools.__Suite.java in DERBY-5217-1.patch, please check it.

          Show
          Houx Zhang added a comment - Hi, Bryan. I have adding locale checking in tools.__Suite.java in DERBY-5217 -1.patch, please check it.
          Hide
          Bryan Pendleton added a comment -

          I think we have to say indexOf("en") >= 0 instead of contains("en") in order to build on JDK 1.4 environments.

          With the patch applied, does the tools suite now pass for you in the Chinese environment?

          Show
          Bryan Pendleton added a comment - I think we have to say indexOf("en") >= 0 instead of contains("en") in order to build on JDK 1.4 environments. With the patch applied, does the tools suite now pass for you in the Chinese environment?
          Hide
          Bryan Pendleton added a comment -

          In my environment, both with and without the patch applied, all 106 tests in the tests.tools._Suite suite pass.

          I expect that in the Chinese environment, there should be 105 tests that pass, and no failures. Houx, can
          you confirm that result? If so, I think this may be the best resolution for this problem for now.

          Lastly, I think that we should expand on the comment in the test indicating why we are excluding this
          test, something like:

          // ImportExportIJTest invokves the IJ tool in a manner that makes it hard to control the
          // locale used by the engine for formatting error messages, and the error text comes out
          // in non-English language which causes test failures in non-English locales - see DERBY-5217

          Show
          Bryan Pendleton added a comment - In my environment, both with and without the patch applied, all 106 tests in the tests.tools._Suite suite pass. I expect that in the Chinese environment, there should be 105 tests that pass, and no failures. Houx, can you confirm that result? If so, I think this may be the best resolution for this problem for now. Lastly, I think that we should expand on the comment in the test indicating why we are excluding this test, something like: // ImportExportIJTest invokves the IJ tool in a manner that makes it hard to control the // locale used by the engine for formatting error messages, and the error text comes out // in non-English language which causes test failures in non-English locales - see DERBY-5217
          Hide
          Knut Anders Hatlen added a comment -

          I see that Bryan suggested using LocalizedResource.resetLocalizedResourceCache() to get IJ to pick up the changes in the locale. I'm not sure if you've tried that already, but it looks like it's doing the right thing.

          I made an attempt with calling that method in ScriptTestCase's setUp() and tearDown() methods. This seemed to take care of changing the language of IJ's messages. The error messages from the Derby engine still used the wrong language, since the language of those messages seems to be determined when the database is created, which could happen before ImportExportIJTest runs. To address that, I wrapped ImportExportIJTest in a LocaleTestSetup and made the test create a fresh database instead of using the default test database. With these changes (see the attached patch d5217-resetLocalizedResourceCache.diff), the full tools suite ran without failures in my environment with the locale set to zh_CN.UTF-8.

          Show
          Knut Anders Hatlen added a comment - I see that Bryan suggested using LocalizedResource.resetLocalizedResourceCache() to get IJ to pick up the changes in the locale. I'm not sure if you've tried that already, but it looks like it's doing the right thing. I made an attempt with calling that method in ScriptTestCase's setUp() and tearDown() methods. This seemed to take care of changing the language of IJ's messages. The error messages from the Derby engine still used the wrong language, since the language of those messages seems to be determined when the database is created, which could happen before ImportExportIJTest runs. To address that, I wrapped ImportExportIJTest in a LocaleTestSetup and made the test create a fresh database instead of using the default test database. With these changes (see the attached patch d5217-resetLocalizedResourceCache.diff), the full tools suite ran without failures in my environment with the locale set to zh_CN.UTF-8.
          Hide
          Bryan Pendleton added a comment -

          > since the language of those messages seems to be determined when the database is created,
          > which could happen before ImportExportIJTest runs

          Of course! That was the insight we were missing.

          It also explains some of the behaviors such as https://issues.apache.org/jira/browse/DERBY-5217?focusedCommentId=13042225&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13042225

          Thanks much!

          Show
          Bryan Pendleton added a comment - > since the language of those messages seems to be determined when the database is created, > which could happen before ImportExportIJTest runs Of course! That was the insight we were missing. It also explains some of the behaviors such as https://issues.apache.org/jira/browse/DERBY-5217?focusedCommentId=13042225&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13042225 Thanks much!
          Hide
          Knut Anders Hatlen added a comment -

          Committed revision 1137213.

          LocalizedAttributeScriptTest and LocalizedDisplayScriptTest call LocalizedResource.resetLocalizedResourceCache() in setUp() and tearDown(). Since they are subclasses of ScriptTestCase, and ScriptTestCase also calls that method now, we can probably remove the calls from those tests.

          Show
          Knut Anders Hatlen added a comment - Committed revision 1137213. LocalizedAttributeScriptTest and LocalizedDisplayScriptTest call LocalizedResource.resetLocalizedResourceCache() in setUp() and tearDown(). Since they are subclasses of ScriptTestCase, and ScriptTestCase also calls that method now, we can probably remove the calls from those tests.
          Hide
          Houx Zhang added a comment -

          Wonderful work! The new revision works well in my Chinese environment. Thanks for your help, Bryan and Knut.

          Show
          Houx Zhang added a comment - Wonderful work! The new revision works well in my Chinese environment. Thanks for your help, Bryan and Knut.
          Hide
          Kathey Marsden added a comment -

          reopen to add fix version

          Show
          Kathey Marsden added a comment - reopen to add fix version
          Hide
          Myrna van Lunteren added a comment -

          reopen to backport to 10.8 branch

          Show
          Myrna van Lunteren added a comment - reopen to backport to 10.8 branch
          Hide
          Myrna van Lunteren added a comment -

          backported revision 1137213 together with revision 11405057 for DERBY-5314 to 10.8 with revision 1160433.

          Show
          Myrna van Lunteren added a comment - backported revision 1137213 together with revision 11405057 for DERBY-5314 to 10.8 with revision 1160433.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development