harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Li" <liyilei1...@gmail.com>
Subject Re: [general][tests]To restrict the side-effect of junit tests by launching it in a different VM.
Date Wed, 29 Nov 2006 11:36:19 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message