[ http://issues.apache.org/jira/browse/DERBY-658?page=all ]
Myrna van Lunteren updated DERBY-658:
-------------------------------------
Attachment: DERBY-658_102_20060413.stat
DERBY-658_102_20060413.diff
I think the approach to modify the run resource functionality is better than
the way I approached it, because it reduces the number of files to get
changed...
So I'm attaching a new version of the 10.2 patch - DERBY-658_102_20060413.* -
which includes the ij change, does not have all the run resource and .sql and
_app.properties file changes. It does, however, include the implermentation for
the utf8out file - this is only useable with an individual test, as discussed
before.
With this patch, on linux - jdk14 - derbyall passed with the familiar in my
environment failures for runtimeinfo, wisconsin, and sysinfo (re db2jcc
security permissions). On zOS / os390 there are some problems that will need to
be addressed separately.
Still to be done:
- matching patch for 10.1 (derbyall on linux is running).
- update to testing/README.html.
> test harness improvements required for running on non-ASCII systems
> -------------------------------------------------------------------
>
> Key: DERBY-658
> URL: http://issues.apache.org/jira/browse/DERBY-658
> Project: Derby
> Type: Bug
> Components: Test
> Versions: 10.1.1.0
> Environment: all but especially testing should be done on zOS
> Reporter: Myrna van Lunteren
> Assignee: Myrna van Lunteren
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: DERBY-658_101_20060407_1.diff, DERBY-658_101_20060407_1.stat,
> DERBY-658_102_20060307_1.diff, DERBY-658_102_20060307_1.stat,
> DERBY-658_102_20060413.diff, DERBY-658_102_20060413.stat,
> run_resource.patch.txt
>
> The current functionTests test harness needs adjustment for running on
> non-ASCII systems like zOS.
> Currently, when using derbyTesting.jar built for instance on a windows or
> linux system on zOS the tests do not run, because the properties and runall
> files cannot be understood.
> Until now, testers on zOS had to unjar derbyTesting.jar, then run
> native2ascii -Cp 1047 -reverse on all appropriate files (.sql, .txt, .out,
> .properties, .runall, .asc, .exclude, etc).
> This is a labor intensive and error prone process. Furthermore, it causes
> test failures such as reported with DERBY-575, because tests may assume a
> certain file to be a specific length, which no longer holds true after the
> native2ascii conversion.
> The test harness should get modified to always read the files in the same
> encoding.
> Note however, that the comparison of actual .out and the master should still
> result in files readable on the local system, to enable a human to evaluate
> failures and results. At the same time, this raises the concern that someone
> might check-in an update to the master with an incorrect encoding.
> To resolve the main issue, I propose the following:
> - Set the default encoding in the harness.
> - for each test
> 1) determine if the test encoding is set. We can probably use ij.ui.codeset
> - otherwise a new property is needed.
> Note that this means that .properties, .runall and .exclude files are
> always read in fixed/default encoding.
> 2) read the master/sql files in in the default/fixed encoding unless the
> encoding property is set for a test
> 3) Write the output out in the local encoding (the way is done currently)
> unless the encoding property is set (if set, write out in that encoding)
> 4) Change the code that creates tmpmstr to always apply instead of only for
> networkserver. tmpmstr files will be created in the local encoding.
> 5) Have FileCompare read tmpmstr in in the local encoding for the comparison.
> 6) either document that test development/adjustment need to be at least be
> verified on an ascii system, or add another property that causes a copy of
> the actual output to be created in the default/fixed encoding.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
