----- Original Message -----
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.
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.
/*
*/
----- Original Message -----
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 <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
-----
Original Message -----
From: "TomohitoNakayama" <[EMAIL PROTECTED]>
To:
"Derby Development" <[email protected]
>
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
> [EMAIL PROTECTED]
>
[EMAIL PROTECTED]
>
>
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
