Mikhail Loenko wrote:
On 1/18/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
Mikhail Loenko wrote:
On 1/18/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
Mikhail Loenko wrote:
Finally, three serialization tests failed they depend on package name.
That's what I suspected. Question - how did you know definitively?
(this is good learning for all of us...)
These serial tests use own implementation of CertPath. So, the golden files
contain actual class name.
So what are we testing here? Is there a chance that this misses testing
of interop with other implementations?
We test that Timestamp is implemented in a serialization compatible way.
We do not test that we have CertPath implementation serialization compatible
with RI. Moreover according to the spec we might not to have any CertPath
implementation at all.
There are chances that we missed interop with others, moreover to
be interoperable we need to have the same implementations of CertPath
on both sides, e.g. have the same crypto provider on both sides.
Ok - something to look into going forward.
I'll generate new golden data files for those tests.
And you are going to tell us how you did it, so that this aspect of our
life here in Harmony-land is fully understood.
It would be nice, actually, if they could be safely and predictably
generated at test prep time, right?
Right.
To test serialization the base class SerializationTest is used.
This class also may be used for golden files generation.
This is from the class description (see SerializationTest.java):
There are two modes of test run: reference generation mode and testing
mode. The actual mode is selected via "test.mode" system property. The
testing mode is the default mode.
To turn on the reference generation mode , the test.mode property
should be set to value "serial.reference". In this mode, no testing is
performed but golden files are produced, which contain reference
serialized objects. This mode should be run on a pure Implementation
classes, which are targeted for compartibility.
The location of golden files (in both modes) is controlled via
"TEST_SRC_DIR" system property.
So if I set
<property name="test.mode" value="serial.reference" />
then it overlays the golden files with new ones?
Yes, all golden files will be replaced, if you run all the tests. But
as far as our
classes are in the bootclasspath new files will be generated from
*our* classes.
Remove them from bootclasspath to generate from RI.
I did it with our classes, and things work splendidly. I'll try now
with RI.
I've generated those 7 files. Would you prefer generating them yourself or
me submitting them to JIRA?
I'll do them myself. It's an excellent learning opportunity for me. If
you could stare at the problem with LoginContextTest_1 that would be great.
Thanks
geir
Thanks,
Mikhail
Will TEST_SRC_DIR default to the right place?
Thanks,
Mikhail
geir
Meanwhile I'll try to move drlx and fortress packages from
com.openintel to org.apache to see what happens
Thanks,
Mikhail
On 1/18/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
Seems like I've managed to reproduce the problem:
I've refactored the code using Eclipse: all that is under
com.openintel.drl.security
I've moved under
org.apache.harmony
Then I've searched for and found 18 files that still contained
"com.openintel.drl.security" for some reason, and made
search&replace
After that build failed:
BUILD FAILED
build.xml:393: Test java.security.serialization.CodeSignerTest failed
Will investigate...
BTW, where will we move "com.openintel.drlx" to?
org.apache.harmony_x ?
org.apache.harmonx ?
org.apache.hx ?
Thanks,
Mikhail
On 1/18/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
I've just updated from SVN, all unit tests from security2 passed
(including serialization ones).
Could you please provide more details?
Thanks,
Mikhail
On 1/18/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
I am haplessly plodding along. I found one problem (mine) which fixed a
test, and now I seem to have a more interesting problem with the
serialization tests...
Are the serialization tests "golden data" files somehow dependent the
com.openintel package structure and would be allergic to a
org.apache.harmony package structure?
geir
Geir Magnusson Jr wrote:
I've been trying to refactor security2 into the org.apache pacakage space.
I'm now having test failures.
Can someone else do a co of security2 and verify? I've backed out the
change so that you need junit and bcprov on your classpath (argh!) and
turned on haltonfailure so that the tests will stop once something goes
wrong.
I thought I was being careful - while it's clear that I have no idea
what I'm doing, there's clearly something a little more subtle going on
here because I wouldn't think that just moving package names would be a
problem. I assume that there's some provider or other configuration-ish
issue.
This would be a good learning experience for all of us how this works. I
need to run out for about 20 min... bbiab.
geir
