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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED])
> > > > 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
