[
https://issues.apache.org/jira/browse/DERBY-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614799#action_12614799
]
Kathey Marsden commented on DERBY-3780:
---------------------------------------
Thanks Knut for looking at this. Below is my analysis.
--------------------------------------------------------------------------------------------
ClobTest, BlobClob4Blob and LargeDataLocks tests assume length of string
inserted into a binary column is equal to the length of the bytes that
represent the string. These did not fail on Zos because even though the values
are different for EBCDIC, the alphabet characters still only take one byte.
The tests should be changed to not make this assumption.
1)
testGetCharacterStreamClobUpdates(org.apache.derbyTesting.functionTests.tests.jdbc4.ClobTest)java.sql.SQLException:
The position argument '53' exceeds the size of the BLOB/CLOB.
16)
testPositionBlob(org.apache.derbyTesting.functionTests.tests.jdbcapi.BlobClob4BlobTest)junit.framework.AssertionFailedError:
FAIL - wrong match found for ??? starting at 52 and length of 3 expected:<57>
but was:<-1>
17)
testGetBlobBeforeAndAfterUpdate(org.apache.derbyTesting.functionTests.tests.jdbcapi.BlobClob4BlobTest)junit.framework.AssertionFailedError:
FAIL - wrong blob value
18)
testGetBlobBeforeAndAfterUpdateStream(org.apache.derbyTesting.functionTests.tests.jdbcapi.BlobClob4BlobTest)junit.framework.AssertionFailedError:
FAIL - wrong blob value
19)
testPositionBytes(org.apache.derbyTesting.functionTests.tests.jdbcapi.BlobClob4BlobTest)junit.framework.AssertionFailedError:
FAIL - wrong match found for ? starting at 40 and length of 1 expected:<62>
but was:<47>
20) testPositionBlob(org.apache.derbyTesting.functionTests.tests.jdbcapi.Blob
Clob4BlobTest)junit.framework.AssertionFailedError: FAIL - wrong match found
for ????????? starting at 38 and length of 9 expected:<39> but was:<-1>
27)
testGetBytes(org.apache.derbyTesting.functionTests.tests.jdbcapi.LargeDataLocksTest)junit.framework.AssertionFailedError:
expected:<38000> but was:<76002>
at
org.apache.derbyTesting.functionTests.tests.jdbcapi.LargeDataLocksTest.te
26)
testGetBinaryStream(org.apache.derbyTesting.functionTests.tests.jdbcapi.LargeDataLocksTest)junit.framew
ork.AssertionFailedError: expected:<38000> but was:<76002>
------------------------------------------------------------------------
File not imported with US-ASCII codeset. Test needs to be fixed.
30)
testEarlyEndOfFile(org.apache.derbyTesting.functionTests.tests.tools.ImportExportTest)junit.framework.ComparisonFailure:
Unexpected SQL state. expected:<XIE0E> but was:<42X04>
--------------------------------------------------------------------
Tests that spawn processes that don't have the same file.encoding. Can't
really fix this without passing the file.encoding on to the spawned process
which we probably don't want to do since it is not a standard property.
2) SecureServerTest( Opened = false, Authenticated= false,
CustomDerbyProperties= null, WildCardHost= null
)junit.framework.AssertionFailedError: SecureServerTest( Opened = false,
Authenticated= false, CustomDerbyProperties= null, WildCardHost= null )
Expected: Security manager installed using the Basic server security policy.
But saw:
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
----------------------------------------------------------------------------
Problem reading error log vti. The support file is in ascii and the
SYSCS_DIAG.ERROR_LOG_READER vti I think correctly reads in the default
encoding, so I don't think this is a problem. Not sure why this one didn't
show up on Zos.
13)
testErrorLogReader(org.apache.derbyTesting.functionTests.tests.lang.SysDiagVTIMappingTest)junit.framework.AssertionFailedError:
Unexpected row count: expected:<2> but was:<0>
---------------------------------------------------------------------------
Permgen Space errors and cascading DatabaseMetaDataTest failures. This just
occured because I forgot to up the Permgen space when running with the sun jvm.
-------------------------------------------------------------------
Pemission errors getting context class loader in DropDatabaseTestSetup. Not
sure what could be causing this or even what test is causing the problem.
Maybe an encoding problem reading the policy file, but only a few tests seemed
to have this problem.
19) Encryption Algorithm: defaultjava.security.AccessControlException: access
denied (java.lang.RuntimePermission getClassLoader)
--------------------------------------------------------------------------------------------------------------------
In general the conclusion is running this way popped a few more test encoding
issues and this is a nice trick to reproduce encoding issues on Windows with
Sun JVM's (doesn't work with IBM jvms). I don't see any product encoding
issues. Running with -Dfile.encoding=UTF-16 it is not really suitable for a
nightly run, which I had hoped, because of the spawned processes and
AccessControl exceptions.
> Run junit tests with -Dfile.encoding="UTF-16" to expose encoding issues and
> analyze failures
> --------------------------------------------------------------------------------------------
>
> Key: DERBY-3780
> URL: https://issues.apache.org/jira/browse/DERBY-3780
> Project: Derby
> Issue Type: Task
> Components: Test
> Affects Versions: 10.5.0.0
> Reporter: Kathey Marsden
> Priority: Minor
> Attachments: ReadEncodedFile.java, suites_all_utf16.txt
>
>
> Wth sun jkd 1.5 and 1.6 you can run JUnit tests with -Dfile.encoding="UTF-16"
> to help expose encoding issues with Derby and tests. Run suites.All and
> analyze failures.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
