[ http://issues.apache.org/jira/browse/DERBY-658?page=all ]
Myrna van Lunteren updated DERBY-658:
-------------------------------------
Attachment: DERBY-658_102_20060307_1.stat
DERBY-658_102_20060307_1.diff
Here is the patch for main - DERBY-658_102_20060307_1.*.
Again, most files changed are because not being able to use the 'run resource'
with .sql files on non-ISO5889 systems.
The details of this change:
- now a file .tmpmstr is *always* created for comparison with the .out file -
before this change, the .tmpmstr was only created with networkserver.
- all .properties, .sql, .exclude, etc files are read/accessed using fixed
encoding, thus assuming they come from a .jar built on an ISO-5889 system.
- all .sql, .txt and .view files listed in supportfiles= in _app.properties
files, and the .policy file are copied to the machine in local encoding. Other
files are copied in fixed encoding.
- changes were needed in .sql tests that used 'run resource', and thus also in
_app.properties files for thos tests. Most of the changes were in the
tests/store directory.
I ran derbyall on linux with jdk14 with this patch, and had the following
failures also seen elsewhere:
- lang/wisconsin.java
- lang/checkDataSource30.java times out (hang?)
Also saw test derbynet/runtimeinfo.java fail again, which it has been doing
intermittingly with builds from this particular setup. I've seen one other
person mention this, although it doesn't show on any nightly failures...Also
passes on another system of mine...
Also saw the following failures after I sync-ed up, rebuilt, and reran derbyall
(without making further changes, so I rather think it wasn't related):
- derbynet/sysinfo.java and derbynet/sysinfo_withproperties.java (with db2jcc
in my classpath):
-----------------
> [Unable to access Protection Domain or Code Source for class class
> com.ibm.db2.jcc.DB2Driver: access denied (java.lang.RuntimePermission
> getProtectionDomain)] 2.6 - (90)
41a43
> [Unable to access Protection Domain or Code Source for class class
> com.ibm.db2.jcc.DB2Driver: access denied (java.lang.RuntimePermission
> getProtectionDomain)] 2.6 - (90)
69a72
> [Unable to access Protection Domain or Code Source for class class
> com.ibm.db2.jcc.DB2Driver: access denied (java.lang.RuntimePermission
> getProtectionDomain)] 2.6 - (90)
-----------------------
> 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
>
> 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
