Myrna van Lunteren wrote:
On 2/9/06, *Mike Matrigali* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
It would seem reasonable to mark this test to not run in nightly
under solaris 10 until you resolve the jvm issue or change the test.
Maybe someone can give some hints if this is possible under the
current test harness (I know it is pretty easy to mark not run
under a specific JVM, just not sure of OS).
The only way to handle os-specific details right now is to modify the
test, or, for .sql files the *only* solution, to mask differing lines
in the output using a <test>_sed.properties file, if the test doesn't
fail too miserably.
There is no platform-specific skipping, or diffing.
Myrna
The test does fail too miserably :)
Actually, the test won't be able to create the encrypted database, which
is the initial step for almost all test cases exercised by the ij script.
An alternative solution would be to reduce the key length, as I have
described in the Jira issue. Since there are no comments about the key
length, I do not know if the test was written to test the handling of
keys that are too long, or if the key is just too long (for the
specified encryption algorithm) for some other reason. We could perhaps
modify the test to use a key of correct length for all test cases except
one, and then use Myrna's trick of using sed to mask out the differing
lines.
Just for information, the code block where things go wrong is a
try-catch. If the code inside the try block fails, a security provider
method is executed in the catch block to translate the apparently
invalid key to a valid key. Then the same steps as those inside the try
block are retried. If it fails again (but this time in the catch block -
the code is duplicated), i.e. the key was/could not be translated to a
valid key, the exception from the Cipher.init method is wrapped and thrown.
I would appreciate some more information of what the test is actually
written to test before I go ahead and change it!
--
Kristian
