db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "TomohitoNakayama" <tomon...@basil.ocn.ne.jp>
Subject Re: All of derby_all fails when environment corresponding derbyLocale_**.jar exists in CLASSPATH
Date Sun, 29 May 2005 22:20:53 GMT
Hello.

I retried derbynetclientmats with next environment variable.
_JAVA_OPTIONS: -Duser.language=en -Duser.locale=us

Generating Japanese message in result was surpressed.
However ,message for _JAVA_OPTIONS was generated in all test, and all test 
was failed.

Next is sample of diff.

********* Diff file 
derbynetclientmats/DerbyNetClient/derbynetclientmats/netxaPositive.diff
*** Start: netxaPositive jdk1.4.2_05 DerbyNetClient 
derbynetclientmats:derbynetclientmats 2005-05-30 01:45:04 ***
114 del
< ij>
114 add
> ij> Picked up _JAVA_OPTIONS: -Duser.language=en -Duser.locale=us
Test Failed.
*** End:   netxaPositive jdk1.4.2_05 DerbyNetClient


...Well , excluding derbyLocale_jp.jarseems to be moderate solution 
now......

I will post this issue to JIRA.


Best regards.


/*

         Tomohito Nakayama
         tomonaka@basil.ocn.ne.jp
         tomohito@rose.zero.ad.jp

         Naka
         http://www5.ocn.ne.jp/~tomohito/TopPage.html

*/
  ----- Original Message ----- 
  From: TomohitoNakayama
  To: Derby Development
  Sent: Monday, May 30, 2005 12:07 AM
  Subject: Re: All of derby_all fails when environment corresponding 
derbyLocale_**.jar exists in CLASSPATH


  Hello.

  I executed derbynetclientmats with next option.
   java -Drunwithjdk14=true -DexcludeJCC=at-or-before:2.3 
"-Djvmflags=-Duser.language=en -Duser.country=US" 
org.apache.derbyTesting.functionTests.harness.RunSuite derbynetclientmats

  The result was that locale problem was not solved with this commandline 
option....

  It may reasonable answer to exculde derbyLocale_Ja.jar for a while.

  Best regards.

  /*

           Tomohito Nakayama
           tomonaka@basil.ocn.ne.jp
           tomohito@rose.zero.ad.jp

           Naka
           http://www5.ocn.ne.jp/~tomohito/TopPage.html

  */
    ----- Original Message ----- 
    From: TomohitoNakayama
    To: Derby Development
    Sent: Sunday, May 29, 2005 6:52 AM
    Subject: Re: All of derby_all fails when environment corresponding 
derbyLocale_**.jar exists in CLASSPATH


    Hello.

    Now, derbyall have done.
    Result was that many error caused by locale problem was found as before 
...

    derbyall_prop.txt told that sytem property was configured as ...
    ------------
     user.country=US
     user.language=en


    I wonder that it is  needed to configure system property 
using -Djvmflags= option when executing derbyall....
    I will try it again this night .....

    Best regards.

    /*

             Tomohito Nakayama
             tomonaka@basil.ocn.ne.jp
             tomohito@rose.zero.ad.jp

             Naka
             http://www5.ocn.ne.jp/~tomohito/TopPage.html

    */
      ----- Original Message ----- 
      From: TomohitoNakayama
      To: Derby Development
      Sent: Saturday, May 28, 2005 5:23 PM
      Subject: Re: All of derby_all fails when environment corresponding 
derbyLocale_**.jar exists in CLASSPATH


      Hello.

      >The others I don't know for sure but they're all network server 
tests. Can you please post a diff for one of these so I get an idea?

      I uploaded one.
      Please see  http://www5.ocn.ne.jp/~tomohito/20050528/maxthreads.diff
      Seeing result , just message was in Japanese.


      >Would it be totally unacceptable to document we expect the test 
harness to be run in en_US locale? Naka,

      Well ...
      Phenomena found this time was not so serious.
      So I think it is acceptable now, if notion of system property to 
escape the problem was explained.

      But on the other hand, I wonder more deep issue about i18n may appear 
in some day.
      So there exists some anxiety for limiting test environment only to 
en_US .

      //locale problem can be very serious problem in Asia including 
Japan....


      >If you run the tests with those properties you mention, does that 
work?
      >We'd probably need to pass them into the test harness 
using -Djvmflags=... Or maybe even just force it from insite 
RunSuite/RunTest.

      At my site, I successed executing derbynetclientsmats suite 
configuring "-Duser.language=en -Duser.country=US" directly to VM.
      The executing command was like next.
      ----
       java -Drunwithjdk14=true -DexcludeJCC=at-or-before:2.3 -Duser.language=en 
 -Duser.country=US org.apache.derbyTesting.functionTests.harness.RunSuite 
derbynetclientmats


      I will try also derbyall this night.



      Best regards.


      /*

               Tomohito Nakayama
               tomonaka@basil.ocn.ne.jp
               tomohito@rose.zero.ad.jp

               Naka
               http://www5.ocn.ne.jp/~tomohito/TopPage.html

      */
        ----- Original Message ----- 
        From: Myrna van Lunteren
        To: Derby Development
        Sent: Saturday, May 28, 2005 3:33 PM
        Subject: Re: All of derby_all fails when environment corresponding 
derbyLocale_**.jar exists in CLASSPATH


        Hi,

        Without a specific locale, Derby is supposed to default to 
English...(the english locale messages are in derby.jar and thus always 
available).

        The test derbynet/sysinfo displays current locale, which I've also 
seen fail for certain jvms, and it also fails on cygwin/jdk15 for the Norway 
group (it displays No_no).
        I've been wanting to look into somehow not printing out the current 
locale...Would that be an acceptable change?

        those 3 i18n tests are indeed troublesome - I've opened bug 
DERBY-244 for them, but I haven't come up with a good solution.
        These .sql tests use ij. ij sents its output to the console, thus, 
the info gets parsed through console.encoding and console's language 
setting. Then, it gets saved to a file and thus gets parsed through 
file.encoding . I've been meaning to test with a forced console.encoding 
depending on platform - i.e. if os.name substring matches 'windows', force 
Cp1252, otherwise, force UTF-8. Would that work?

        Or is the whole point of testing ij to ensure the text comes out 
correct in different locales/encodings? And how can we consistently check 
that?

        The others I don't know for sure but they're all network server 
tests. Can you please post a diff for one of these so I get an idea?

        Would it be totally unacceptable to document we expect the test 
harness to be run in en_US locale? Naka, would that be impossible for you? 
If you run the tests with those properties you mention, does that work? We'd 
probably need to pass them into the test harness using -Djvmflags=... Or 
maybe even just force it from insite RunSuite/RunTest.
        How do the folks in Norway run these?

        All this also shows how terribly week the Japanese, and other locale 
tests are.

        Myrna

        On 5/27/05, TomohitoNakayama <tomonaka@basil.ocn.ne.jp> wrote:
          Hello.


          I tried to execute derby_all again without derbyLocale_ja.jar and 
found next
          tests are failed.


          derbyall/derbyall.fail:jdbcapi/parameterMapping.java
          derbyall/derbyall.fail:i18n/urlLocale.sql
          derbyall/derbyall.fail:i18n/messageLocale.sql
          derbyall/derbyall.fail:i18n/iepnegativetests_ES.sql
          derbyall/derbynetclientmats/derbynetmats.fail:derbynet/NSinSameJVM.java
          derbyall/derbynetclientmats/derbynetmats.fail:derbynet/maxthreads.java
          derbyall/derbynetclientmats/derbynetmats.fail:derbynet/runtimeinfo.java
          derbyall/derbynetclientmats/derbynetmats.fail:derbynet/sysinfo.java
          derbyall/derbynetclientmats/derbynetmats.fail:derbynet/testProperties.java
          derbyall/derbynetclientmats/derbynetmats.fail:derbynet/testconnection.java
          derbyall/derbynetclientmats/derbynetmats.fail:derbynet/timeslice.java
          derbyall/derbynetmats/derbynetmats.fail:derbynet/NSinSameJVM.java
          derbyall/derbynetmats/derbynetmats.fail:derbynet/maxthreads.java
          derbyall/derbynetmats/derbynetmats.fail:derbynet/runtimeinfo.java
          derbyall/derbynetmats/derbynetmats.fail:derbynet/sysinfo.java
          derbyall/derbynetmats/derbynetmats.fail:derbynet/testProperties.java
          derbyall/derbynetmats/derbynetmats.fail:derbynet/testconnection.java
          derbyall/derbynetmats/derbynetmats.fail:derbynet/timeslice.java


          Seeing their **.diff, next contains difference caused by locale 
problem.

          derbyall/derbyall.fail:i18n/messageLocale.sql
          derbyall/derbyall.fail:i18n/iepnegativetests_ES.sql
          derbyall/derbynetclientmats/derbynetmats.fail:derbynet/NSinSameJVM.java
          derbyall/derbynetclientmats/derbynetmats.fail:derbynet/maxthreads.java
          derbyall/derbynetclientmats/derbynetmats.fail:derbynet/runtimeinfo.java
          derbyall/derbynetclientmats/derbynetmats.fail:derbynet/sysinfo.java
          derbyall/derbynetclientmats/derbynetmats.fail:derbynet/testProperties.java
          derbyall/derbynetclientmats/derbynetmats.fail:derbynet/testconnection.java
          derbyall/derbynetclientmats/derbynetmats.fail:derbynet/timeslice.java


          Taking aside testing barrier, almost all of these locale problem 
seems not
          so harmful.
          Generated messages was reasonable as Japanese message.

          But derbyall/derbyall.fail:i18n/iepnegativetests_ES.sql, some 
characters are
          corrupted.

          For example...
          47a47
          > ERROR XIE0J: Un delimitador no es v?lido o se ha utilizado m?s 
de una vez.
          51 del
          < ERROR XIE0J: Un delimitador no es v EnC:>225< lido o se ha 
utilizado m
          EnC:>225< s de una vez.


          I think we can avoid this testing problem in SunVM configuring 
sytem
          property of user.language/user.country/user.variant.

          http://java.sun.com/j2se/corejava/intl/reference/faqs/index.html :
          Can I set the default locale from outside an application?
          This depends on the implementation of the Java platform you're 
using. The
          initial default locale is normally determined from the host 
operating
          system's locale. Versions 1.4 and higher of Sun's JREs let you 
override this
          by setting the user.language, user.country, and user.variant 
system
          properties from the command line. For example, to select 
Locale("th", "TH",
          "TH") as the initial default locale, you would use:
          java -Duser.language=th -Duser.country=TH -Duser.variant=TH 
MainClass
          Since not all runtime environments provide this feature, it should 
only be
          used for testing.

          But there remains unclearness around other vm .....

          Best regards.

          /*

                  Tomohito Nakayama

                  tomonaka@basil.ocn.ne.jp
                   tomohito@rose.zero.ad.jp

                  Naka
                  http://www5.ocn.ne.jp/~tomohito/TopPage.html

          */
          ----- Original Message ----- 
          From: "TomohitoNakayama" <tomonaka@basil.ocn.ne.jp>
          To: "Derby Development" <derby-dev@db.apache.org >
          Sent: Saturday, May 28, 2005 5:03 AM
          Subject: All of derby_all fails when environment corresponding
          derbyLocale_**.jar exists in CLASSPATH


          > Hello.
          >
          > I executed derby_all with new configuration and found this 
phenomena.
          >
          > Adding derbyLocale_ja_JP.jar to classpath and ,
          > all of derby_all was failed because all result message was 
generated in
          > Japanese ....
          >
          > I didn't realized this , because I had not included 
derbyLocale_ja_JP.jar
          > to classpath before ....
          >
          > //Further more,from this time , environment variable "LANG" was 
set to
          > "en" as next ....
          > //LANG="en"
          > //This configuration was done to avoid lang problem of "svn 
diff" around
          > upgraded subversion, 1.2.0.
          > //But it does not work for derby.
          > //I wonder how programs judges locale information ...
          > //System property in JDK ....?
          >
          > I think this is bug around test itself ......
          >
          > Best regards.
          >
          > /*
          >
          >         Tomohito Nakayama
          >         tomonaka@basil.ocn.ne.jp
          >         tomohito@rose.zero.ad.jp
          >
          >         Naka
          >         http://www5.ocn.ne.jp/~tomohito/TopPage.html
          >
          > */
          >
          >
          > -- 
          > No virus found in this outgoing message.
          > Checked by AVG Anti-Virus.
          > Version: 7.0.322 / Virus Database: 267.0.0 - Release Date: 
2005/05/27
          >
          >
          >
          >
          > --
          > No virus found in this incoming message.
          > Checked by AVG Anti-Virus.
          > Version: 7.0.322 / Virus Database: 267.0.0 - Release Date: 
2005/05/27
          >
          >



          --
          No virus found in this outgoing message.
          Checked by AVG Anti-Virus.
          Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 
2005/05/27






------------------------------------------------------------------------


        No virus found in this incoming message.
        Checked by AVG Anti-Virus.
        Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 
2005/05/27



--------------------------------------------------------------------------


      No virus found in this incoming message.
      Checked by AVG Anti-Virus.
      Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27



----------------------------------------------------------------------------


    No virus found in this incoming message.
    Checked by AVG Anti-Virus.
    Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27



------------------------------------------------------------------------------


  No virus found in this incoming message.
  Checked by AVG Anti-Virus.
  Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message