You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by TomohitoNakayama <to...@basil.ocn.ne.jp> on 2005/05/27 22:03:14 UTC
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
Re: Discussion about DERBY-318 (Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")) derbyLocale_**.jar exists in CLASSPATH
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
derbyall seems to run correctly.
Thank you for your help !
Best regareds.
/*
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...@basil.ocn.ne.jp>
To: "Derby Development" <de...@db.apache.org>
Sent: Tuesday, May 31, 2005 1:16 AM
Subject: Re: Discussion about DERBY-318 (Re: DERBY-308 just be done and ....
(Re: [jira] Updated: (DERBY-308) Modify dblook to support "GENERATED BY
DEFAULT AS IDENTITY")) derbyLocale_**.jar exists in CLASSPATH
> Hello.
>
> Configuring locale of Windows in Controlpanel seems to solve the test
> problem.
> Derbynetclientmats works. I will try derbyall again.
> Thank you very much !
>
> //On the other hand maany application including subverion , mailer , etc
> comes not to work in that configuration ...
> //How difficult i18n is ....
>
> 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: "Dag H. Wanvik" <Da...@Sun.COM>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Monday, May 30, 2005 11:53 PM
> Subject: Re: Discussion about DERBY-318 (Re: DERBY-308 just be done and
> .... (Re: [jira] Updated: (DERBY-308) Modify dblook to support "GENERATED
> BY DEFAULT AS IDENTITY")) derbyLocale_**.jar exists in CLASSPATH
>
>
>>
>> Hi,
>>>>>>> "T" == TomohitoNakayama <to...@basil.ocn.ne.jp> wrote:
>> T>
>> T> Hello.
>> T> I tried "export LC_CTYPE=en_US" but not successed....
>> T>
>> T> I run it on Windows using cygwin.
>>
>> Actually, on Windows XP/Cygwin I changed language temporarily to US
>> English via the Properties->Region/language dialogue.
>> That made that particular test which failed, run cleanly for me.
>>
>> T> This environment variable may works only on unix ....
>>
>> Seems so. I guess jala picks it up from the registry.
>>
>> Thanks,
>> Dag
>>
>>
>> T>
>> T> Best regards.
>> T>
>> T> /*
>> T>
>> T> Tomohito Nakayama
>> T> tomonaka@basil.ocn.ne.jp
>> T> tomohito@rose.zero.ad.jp
>> T>
>> T> Naka
>> T> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>> T>
>> T> */
>> T> ----- Original Message -----
>> T> From: "Dag H. Wanvik" <Da...@Sun.COM>
>> T> To: "Derby Development" <de...@db.apache.org>; "Myrna van
>> Lunteren"
>> T> <m....@gmail.com>
>> T> Sent: Monday, May 30, 2005 10:24 AM
>> T> Subject: Re: All of derby_all fails when environment corresponding
>> T> derbyLocale_**.jar exists in CLASSPATH
>> T>
>> T>
>> T> >
>> T> > Hi,
>> T> >>>>>> "MvL" == Myrna van Lunteren <m....@gmail.com> wrote:
>> T> >
>> T> > MvL> Would it be totally unacceptable to document we expect the test
>> T> > harness to
>> T> > MvL> be run in en_US locale? Naka, would that be impossible for you?
>> If
>> T> > you run
>> T> > MvL> the tests with those properties you mention, does that work?
>> We'd
>> T> > probably
>> T> > MvL> need to pass them into the test harness using -Djvmflags=... Or
>> maybe
>> T> > even
>> T> > MvL> just force it from insite RunSuite/RunTest.
>> T> > MvL> How do the folks in Norway run these?
>> T> >
>> T> > I used the setting below setting in the shell (bash) when running
>> T> > tests. Worked for me, but then only one test failed due to the no_NO
>> T> > setting originally (I forget which one, I can re-run to find out?).
>> T> > Otherwise, I agree, ideally tests should be agnostic to
>> T> > current language/region, but if that isn't achievable, the harness
>> T> > could check for correct setting.
>> T> >
>> T> > export LC_CTYPE=en_US
>> T> >
>> T> > Dag
>> T> >
>> T> >
>> T> >
>> T> > --
>> T> > No virus found in this incoming message.
>> T> > Checked by AVG Anti-Virus.
>> T> > Version: 7.0.322 / Virus Database: 267.2.0 - Release Date:
>> 2005/05/27
>> T> >
>> T> >
>> T>
>> T>
>> T>
>> T> --
>> T> No virus found in this outgoing message.
>> T> Checked by AVG Anti-Virus.
>> T> Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27
>> T>
>> --
>> Dag H. Wanvik
>> Sun Microsystems, Web Services, Database Technology Group
>> Haakon VII gt. 7b, N-7485 Trondheim, Norway
>> Tel: x43496/+47 73842196, Fax: +47 73842101
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> NOTICE: This email message is for the sole use of the intended
>> recipient(s) and may contain confidential and privileged
>> information. Any unauthorized review, use, disclosure or distribution
>> is prohibited. If you are not the intended recipient, please contact
>> the sender by reply email and destroy all copies of the original
>> message.
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>>
>> --
>> 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 outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 5/27/2005
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 5/27/2005
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.3.0 - Release Date: 5/30/2005
Re: Discussion about DERBY-318 (Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")) derbyLocale_**.jar exists in CLASSPATH
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
Configuring locale of Windows in Controlpanel seems to solve the test
problem.
Derbynetclientmats works. I will try derbyall again.
Thank you very much !
//On the other hand maany application including subverion , mailer , etc
comes not to work in that configuration ...
//How difficult i18n is ....
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: "Dag H. Wanvik" <Da...@Sun.COM>
To: "Derby Development" <de...@db.apache.org>
Sent: Monday, May 30, 2005 11:53 PM
Subject: Re: Discussion about DERBY-318 (Re: DERBY-308 just be done and ....
(Re: [jira] Updated: (DERBY-308) Modify dblook to support "GENERATED BY
DEFAULT AS IDENTITY")) derbyLocale_**.jar exists in CLASSPATH
>
> Hi,
>>>>>> "T" == TomohitoNakayama <to...@basil.ocn.ne.jp> wrote:
> T>
> T> Hello.
> T> I tried "export LC_CTYPE=en_US" but not successed....
> T>
> T> I run it on Windows using cygwin.
>
> Actually, on Windows XP/Cygwin I changed language temporarily to US
> English via the Properties->Region/language dialogue.
> That made that particular test which failed, run cleanly for me.
>
> T> This environment variable may works only on unix ....
>
> Seems so. I guess jala picks it up from the registry.
>
> Thanks,
> Dag
>
>
> T>
> T> Best regards.
> T>
> T> /*
> T>
> T> Tomohito Nakayama
> T> tomonaka@basil.ocn.ne.jp
> T> tomohito@rose.zero.ad.jp
> T>
> T> Naka
> T> http://www5.ocn.ne.jp/~tomohito/TopPage.html
> T>
> T> */
> T> ----- Original Message -----
> T> From: "Dag H. Wanvik" <Da...@Sun.COM>
> T> To: "Derby Development" <de...@db.apache.org>; "Myrna van Lunteren"
> T> <m....@gmail.com>
> T> Sent: Monday, May 30, 2005 10:24 AM
> T> Subject: Re: All of derby_all fails when environment corresponding
> T> derbyLocale_**.jar exists in CLASSPATH
> T>
> T>
> T> >
> T> > Hi,
> T> >>>>>> "MvL" == Myrna van Lunteren <m....@gmail.com> wrote:
> T> >
> T> > MvL> Would it be totally unacceptable to document we expect the test
> T> > harness to
> T> > MvL> be run in en_US locale? Naka, would that be impossible for you?
> If
> T> > you run
> T> > MvL> the tests with those properties you mention, does that work?
> We'd
> T> > probably
> T> > MvL> need to pass them into the test harness using -Djvmflags=... Or
> maybe
> T> > even
> T> > MvL> just force it from insite RunSuite/RunTest.
> T> > MvL> How do the folks in Norway run these?
> T> >
> T> > I used the setting below setting in the shell (bash) when running
> T> > tests. Worked for me, but then only one test failed due to the no_NO
> T> > setting originally (I forget which one, I can re-run to find out?).
> T> > Otherwise, I agree, ideally tests should be agnostic to
> T> > current language/region, but if that isn't achievable, the harness
> T> > could check for correct setting.
> T> >
> T> > export LC_CTYPE=en_US
> T> >
> T> > Dag
> T> >
> T> >
> T> >
> T> > --
> T> > No virus found in this incoming message.
> T> > Checked by AVG Anti-Virus.
> T> > Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27
> T> >
> T> >
> T>
> T>
> T>
> T> --
> T> No virus found in this outgoing message.
> T> Checked by AVG Anti-Virus.
> T> Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27
> T>
> --
> Dag H. Wanvik
> Sun Microsystems, Web Services, Database Technology Group
> Haakon VII gt. 7b, N-7485 Trondheim, Norway
> Tel: x43496/+47 73842196, Fax: +47 73842101
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> NOTICE: This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged
> information. Any unauthorized review, use, disclosure or distribution
> is prohibited. If you are not the intended recipient, please contact
> the sender by reply email and destroy all copies of the original
> message.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> --
> 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 outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 5/27/2005
Re: Discussion about DERBY-318 (Re: DERBY-308 just be done and ....
(Re: [jira] Updated: (DERBY-308) Modify dblook to support
"GENERATED BY DEFAULT AS IDENTITY")) derbyLocale_**.jar exists in CLASSPATH
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Hi,
>>>>> "T" == TomohitoNakayama <to...@basil.ocn.ne.jp> wrote:
T>
T> Hello.
T> I tried "export LC_CTYPE=en_US" but not successed....
T>
T> I run it on Windows using cygwin.
Actually, on Windows XP/Cygwin I changed language temporarily to US
English via the Properties->Region/language dialogue.
That made that particular test which failed, run cleanly for me.
T> This environment variable may works only on unix ....
Seems so. I guess jala picks it up from the registry.
Thanks,
Dag
T>
T> Best regards.
T>
T> /*
T>
T> Tomohito Nakayama
T> tomonaka@basil.ocn.ne.jp
T> tomohito@rose.zero.ad.jp
T>
T> Naka
T> http://www5.ocn.ne.jp/~tomohito/TopPage.html
T>
T> */
T> ----- Original Message -----
T> From: "Dag H. Wanvik" <Da...@Sun.COM>
T> To: "Derby Development" <de...@db.apache.org>; "Myrna van Lunteren"
T> <m....@gmail.com>
T> Sent: Monday, May 30, 2005 10:24 AM
T> Subject: Re: All of derby_all fails when environment corresponding
T> derbyLocale_**.jar exists in CLASSPATH
T>
T>
T> >
T> > Hi,
T> >>>>>> "MvL" == Myrna van Lunteren <m....@gmail.com> wrote:
T> >
T> > MvL> Would it be totally unacceptable to document we expect the test
T> > harness to
T> > MvL> be run in en_US locale? Naka, would that be impossible for you? If
T> > you run
T> > MvL> the tests with those properties you mention, does that work? We'd
T> > probably
T> > MvL> need to pass them into the test harness using -Djvmflags=... Or maybe
T> > even
T> > MvL> just force it from insite RunSuite/RunTest.
T> > MvL> How do the folks in Norway run these?
T> >
T> > I used the setting below setting in the shell (bash) when running
T> > tests. Worked for me, but then only one test failed due to the no_NO
T> > setting originally (I forget which one, I can re-run to find out?).
T> > Otherwise, I agree, ideally tests should be agnostic to
T> > current language/region, but if that isn't achievable, the harness
T> > could check for correct setting.
T> >
T> > export LC_CTYPE=en_US
T> >
T> > Dag
T> >
T> >
T> >
T> > --
T> > No virus found in this incoming message.
T> > Checked by AVG Anti-Virus.
T> > Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27
T> >
T> >
T>
T>
T>
T> --
T> No virus found in this outgoing message.
T> Checked by AVG Anti-Virus.
T> Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27
T>
--
Dag H. Wanvik
Sun Microsystems, Web Services, Database Technology Group
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax: +47 73842101
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact
the sender by reply email and destroy all copies of the original
message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: All of derby_all fails when environment corresponding derbyLocale_**.jar exists in CLASSPATH
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
I tried "export LC_CTYPE=en_US" but not successed....
I run it on Windows using cygwin.
This environment variable may works only on unix ....
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: "Dag H. Wanvik" <Da...@Sun.COM>
To: "Derby Development" <de...@db.apache.org>; "Myrna van Lunteren"
<m....@gmail.com>
Sent: Monday, May 30, 2005 10:24 AM
Subject: Re: All of derby_all fails when environment corresponding
derbyLocale_**.jar exists in CLASSPATH
>
> Hi,
>>>>>> "MvL" == Myrna van Lunteren <m....@gmail.com> wrote:
>
> MvL> Would it be totally unacceptable to document we expect the test
> harness to
> MvL> be run in en_US locale? Naka, would that be impossible for you? If
> you run
> MvL> the tests with those properties you mention, does that work? We'd
> probably
> MvL> need to pass them into the test harness using -Djvmflags=... Or maybe
> even
> MvL> just force it from insite RunSuite/RunTest.
> MvL> How do the folks in Norway run these?
>
> I used the setting below setting in the shell (bash) when running
> tests. Worked for me, but then only one test failed due to the no_NO
> setting originally (I forget which one, I can re-run to find out?).
> Otherwise, I agree, ideally tests should be agnostic to
> current language/region, but if that isn't achievable, the harness
> could check for correct setting.
>
> export LC_CTYPE=en_US
>
> Dag
>
>
>
> --
> 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 outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27
Re: All of derby_all fails when environment corresponding
derbyLocale_**.jar exists in CLASSPATH
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
>>>>>>>>>>>> Dag H. Wanvik wrote (2005-05-30 03:24:37):
> I used the setting below setting in the shell (bash) when running
> tests. Worked for me, but then only one test failed due to the no_NO
> setting originally (I forget which one, I can re-run to find out?).
> Otherwise, I agree, ideally tests should be agnostic to
> current language/region,
The pprpoer solution is of course to stop using
getMessage()/toString() in tests. (Unless for tests of locales) To
identify errors, one would have enumerate them and use the
SQLException's vendorCode and getErrorCode() to check in the tests. I
believe the errorCode is not systematically used in Derby.
Bernt
> but if that isn't achievable, the harness
> could check for correct setting.
>
> export LC_CTYPE=en_US
>
> Dag
--
Bernt Marius Johnsen, Database Technology Group,
Sun Microsystems, Trondheim, Norway
Re: All of derby_all fails when environment corresponding
derbyLocale_**.jar exists in CLASSPATH
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Hi,
>>>>> "MvL" == Myrna van Lunteren <m....@gmail.com> wrote:
MvL> Would it be totally unacceptable to document we expect the test harness to
MvL> be run in en_US locale? Naka, would that be impossible for you? If you run
MvL> the tests with those properties you mention, does that work? We'd probably
MvL> need to pass them into the test harness using -Djvmflags=... Or maybe even
MvL> just force it from insite RunSuite/RunTest.
MvL> How do the folks in Norway run these?
I used the setting below setting in the shell (bash) when running
tests. Worked for me, but then only one test failed due to the no_NO
setting originally (I forget which one, I can re-run to find out?).
Otherwise, I agree, ideally tests should be agnostic to
current language/region, but if that isn't achievable, the harness
could check for correct setting.
export LC_CTYPE=en_US
Dag
Re: All of derby_all fails when environment corresponding derbyLocale_**.jar exists in CLASSPATH
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
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 <to...@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" <to...@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
Re: All of derby_all fails when environment corresponding derbyLocale_**.jar exists in CLASSPATH
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
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 <to...@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" <to...@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
Re: All of derby_all fails when environment corresponding derbyLocale_**.jar exists in CLASSPATH
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
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 <to...@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" <to...@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
Re: All of derby_all fails when environment corresponding derbyLocale_**.jar
exists in CLASSPATH
Posted by Jack Klebanoff <kl...@sbcglobal.net>.
Øystein Grøvlen wrote:
>>>>>>"DJD" == Daniel John Debrunner <dj...@debrunners.com> writes:
>>>>>>
>>>>>>
>
> DJD> I think the test suite has to have a known environment to allow it to
> DJD> run successfully on widely different machines. Examples of this known
> DJD> environment are the expected locale, character set encoding for the
> DJD> scripts etc. Ideally the test harness should set this environment itself.
>
>Asa long as you have a test harness that is based on evaluating the
>output to file from each test program, I think you are right.
>However, I think it should be possible to build a locale independent
>test harness in JUnit by instead evaluating the return values from API
>calls (e.g., message ids instead of message strings).
>
>
>
Error messages are important. We should test them.
Remember that the messages are generated by substituting argument values
into strings fetched from the messages files. There may be bugs in the
message generation system, more often Derby programmers make mistakes in
messages and arguments. So if a test just looks at the message IDs and
not at the message strings we will miss some bugs.
Jack Klebanoff
Re: All of derby_all fails when environment corresponding
derbyLocale_**.jar exists in CLASSPATH
Posted by Øystein Grøvlen <Oy...@Sun.COM>.
>>>>> "DJD" == Daniel John Debrunner <dj...@debrunners.com> writes:
DJD> I think the test suite has to have a known environment to allow it to
DJD> run successfully on widely different machines. Examples of this known
DJD> environment are the expected locale, character set encoding for the
DJD> scripts etc. Ideally the test harness should set this environment itself.
Asa long as you have a test harness that is based on evaluating the
output to file from each test program, I think you are right.
However, I think it should be possible to build a locale independent
test harness in JUnit by instead evaluating the return values from API
calls (e.g., message ids instead of message strings).
--
Øystein
Re: All of derby_all fails when environment corresponding derbyLocale_**.jar
exists in CLASSPATH
Posted by Daniel John Debrunner <dj...@debrunners.com>.
TomohitoNakayama wrote:
> 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.
I think the test suite has to have a known environment to allow it to
run successfully on widely different machines. Examples of this known
environment are the expected locale, character set encoding for the
scripts etc. Ideally the test harness should set this environment itself.
> 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....
However, there should also be specific tests which require and set
different environments, such as Japanese locale.
Dan.
Re: All of derby_all fails when environment corresponding derbyLocale_**.jar exists in CLASSPATH
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
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 <to...@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" <to...@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
Re: All of derby_all fails when environment corresponding derbyLocale_**.jar exists in CLASSPATH
Posted by Myrna van Lunteren <m....@gmail.com>.
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 <http://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 <to...@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" <to...@basil.ocn.ne.jp>
> To: "Derby Development" <de...@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
>
>
Re: All of derby_all fails when environment corresponding derbyLocale_**.jar exists in CLASSPATH
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
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" <to...@basil.ocn.ne.jp>
To: "Derby Development" <de...@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