Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 16170 invoked from network); 18 Jan 2006 12:42:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 18 Jan 2006 12:42:08 -0000 Received: (qmail 62822 invoked by uid 500); 18 Jan 2006 12:42:02 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 62757 invoked by uid 500); 18 Jan 2006 12:42:02 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 62746 invoked by uid 99); 18 Jan 2006 12:42:02 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Jan 2006 04:42:02 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of mloenko@gmail.com designates 66.249.92.200 as permitted sender) Received: from [66.249.92.200] (HELO uproxy.gmail.com) (66.249.92.200) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Jan 2006 04:41:59 -0800 Received: by uproxy.gmail.com with SMTP id m3so197810ugc for ; Wed, 18 Jan 2006 04:41:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Sth1nuSx5BZuTSqf2xmuaCUa5vE8m1y7O3FQh10oL7Kos+9J+EF65b6BxzWQyOqQvr0CwwDoss3GZX0ge5gL4TbjluCzHINexpMz+nydChHKMav7X345uaiq/AntnOp/flAyX0gNgxYS+Fn0M/ICeyn0zTI5aj/OtQuwQhzxucc= Received: by 10.66.252.9 with SMTP id z9mr3906015ugh; Wed, 18 Jan 2006 04:41:37 -0800 (PST) Received: by 10.66.244.18 with HTTP; Wed, 18 Jan 2006 04:41:37 -0800 (PST) Message-ID: <906dd82e0601180441w57aad24eo2f4303a1364e362c@mail.gmail.com> Date: Wed, 18 Jan 2006 18:41:37 +0600 From: Mikhail Loenko To: harmony-dev@incubator.apache.org, geir@pobox.com Subject: Re: problems with security2 In-Reply-To: <43CE2639.8060605@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43CD2548.40608@pobox.com> <43CD73F8.3050107@pobox.com> <906dd82e0601172109k6229fc09yab25808db329de54@mail.gmail.com> <906dd82e0601180012s509884b1kbdf87ede4c2832e7@mail.gmail.com> <906dd82e0601180108k7ef9ec68rf44be4dd2b196a5a@mail.gmail.com> <43CE2639.8060605@pobox.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 1/18/06, Geir Magnusson Jr 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. > > 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. 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 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 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 wrote: > >>>> I am haplessly plodding along. I found one problem (mine) which fix= ed 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 t= he > >>>> 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 ide= a > >>>>> what I'm doing, there's clearly something a little more subtle goin= g 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 configuratio= n-ish > >>>>> issue. > >>>>> > >>>>> This would be a good learning experience for all of us how this wor= ks. I > >>>>> need to run out for about 20 min... bbiab. > >>>>> > >>>>> geir > >>>>> > >>>>> > > > > >