harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [general][tests]To restrict the side-effect of junit tests by launching it in a different VM.
Date Fri, 08 Dec 2006 01:59:50 GMT
Leo,
Thank you for explaining! I wonder if you read enough correct objects,
would it clear the cache from incorrect ones?



On 11/29/06, Leo Li <liyilei1979@gmail.com> wrote:
> Hi, Alexei:
>     Excuse me if I confusing you. Actually it is in the original patch. It
> is about the caching mechanism adopted by ObjectInputStream in resolving
> class.
>     Once I have written such a testcase:
>
>      public static class ObjectOutputStreamWithWriteDesc extends
>            ObjectOutputStream {
>        public ObjectOutputStreamWithWriteDesc(OutputStream os)
>                throws IOException {
>            super(os);
>        }
>
>        public void writeClassDescriptor(ObjectStreamClass desc)
>                throws IOException {
>        }
>    }
>
>    public static class ObjectIutputStreamWithReadDesc extends
>            ObjectInputStream {
>        private Class returnClass;
>
>        public ObjectIutputStreamWithReadDesc(InputStream is, Class
> returnClass)
>                throws IOException {
>            super(is);
>            this.returnClass = returnClass;
>        }
>
>        public ObjectStreamClass readClassDescriptor() throws IOException,
>                ClassNotFoundException {
>            return ObjectStreamClass.lookup(returnClass);
>        }
>    }
>
>    public void test_ClassDescriptor() throws IOException,
>            ClassNotFoundException {
>
>        // Conversion between classes
>        ByteArrayOutputStream baos = new ByteArrayOutputStream();
>         ObjectOutputStreamWithWriteDesc  oos = new
> ObjectOutputStreamWithWriteDesc(baos);
>        oos.writeObject(String.class);
>        oos.close();
>
>        Class cls = Integer.class;
>        bais = new ByteArrayInputStream(baos.toByteArray());
>        ObjectIutputStreamWithReadDesc ois = new
> ObjectIutputStreamWithReadDesc(bais, cls);
>  * //Here  I changed the information of Integer Class Desc in
> ObjectInputStream's cache not so as normal.
> *        Object obj = ois.readObject();
>        ...}
>
>
>     But in SerialStressTest,
>      ...
>
>   oos.writeObject(new Object[] { Integer.class, new Integer(1) });
>   oos.close();
>
>   ois = new ObjectInputStreamSubclass(loadStream());
>   ois.readObject();
>   ois.close();
>
>   Class[] resolvedClasses = ((ObjectInputStreamSubclass) ois)
>    .resolvedClasses();
>
>   but here is resolvedClasses there are only two class: Object.class and
> Integer.class, but without Number.class which is expected in the normal
> case. This is because I inited the ObjectInputStream' s caching state of
> Integer.class unnormally in the first testcase. Furthermore, through public
> interface, I cannot rollback the state.(RI will pass this example, but it
> also has its own caching mechanism so I can site another problem to let it
> behave different from normal.)
>
> On 11/29/06, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> >
> > Leo,
> > Could you please share more info about the problem?
> >
> > Could you please name a test case which affects other test cases? I
> > have tried to check http://issues.apache.org/jira/browse/HARMONY-2249
> > but it doesn't contain any clue.
> >
> > Why this test case cannot be fixed to clean environment on exit?
> > --
> > Thank you,
> > Alexei
> >
> >
> > On 11/29/06, Leo Li <liyilei1979@gmail.com> wrote:
> > >  Anyway, using exec, the test is running in a standalone java program
> > rather
> > > than the normal junit test.:)
> > >
> > > On 11/28/06, Stepan Mishura <stepan.mishura@gmail.com> wrote:
> > > >
> > > > On 11/28/06, Leo Li wrote:
> > > > >
> > > > > OK. It will do in exec, but the style is a little different.:)
> > > >
> > > >
> > > > Sorry, I didn't catch - what "different style" means here?
> > > >
> > > > Thanks,
> > > > Stepan.
> > > >
> > > > And I also believe run most tests in one VM will save time.(Actually
> > it
> > > > > has been quite long currently.)
> > > > > I just want to denote the tests that should run in seperate VM while
> > > > > remaining the style of junit tests except some configurations. (Like
> > > > > something in AOP and without intruding.)
> > > > >
> > > > >
> > > > > On 11/28/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
> > > > > >
> > > > > > Stepan Mishura wrote:
> > > > > > > On 11/27/06, Leo Li wrote:
> > > > > > >>
> > > > > > >> Hi, all:
> > > > > > >>     During fixing the bug of Harmony-2249, I found
that the
> > > > testcase
> > > > > in
> > > > > > >> one
> > > > > > >> junit test file might lead to other fail in a different
junit
> > file.
> > > > > > After
> > > > > > >> digging into it, I am aware that testcase can influence
the
> > global
> > > > > > state
> > > > > > >> of
> > > > > > >> a VM, for example, the resolution of class (both RI
and Harmony
> > > > have
> > > > > > >> similar
> > > > > > >> behavior). Although I changed the testcase as a workaround,
 it
> > is
> > > > > not
> > > > > > >> tested so thoroughly as I expected in order not to
lead other
> > tests
> > > > > to
> > > > > > >> fail.
> > > > > > >
> > > > > > >
> > > > > > > If a test's execution influence of VM state and this is
critical
> > for
> > > > > > other
> > > > > > > test then the test can fork VM (via Support_Exec.execJava())
and
> > do
> > > > > all
> > > > > > > testing in the forked VM.
> > > > > >
> > > > > > +1 -- and this should be the exception, in general tests should
> > put
> > > > > > things back as they found them.  exec'ing a new Java is for
those
> > > > cases
> > > > > > where you cannot do that.
> > > > > >
> > > > > > Regards,
> > > > > > Tim
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Tim Ellison (t.p.ellison@gmail.com)
> > > > > > IBM Java technology centre, UK.
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Leo Li
> > > > > China Software Development Lab, IBM
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Stepan Mishura
> > > > Intel Middleware Products Division
> > > >
> > > >
> > >
> > >
> > > --
> > > Leo Li
> > > China Software Development Lab, IBM
> > >
> > >
> >
> >
> > --
> > Thank you,
> > Alexei
> >
>
>
>
> --
> Leo Li
> China Software Development Lab, IBM
>
>


-- 
With best regards,
Alexei,
ESSD, Intel

Mime
View raw message