[kaffe] Re: RMI bugs and quirks

[Jeremy.Buisson at irisa.fr]

Hi,

This is exactly the problem I met. This comes from the=20
java.io.ObjectInputStream class. In facts, the one you merged from Classp=
ath=20
is not the latest version from CVS, and still contains bugs. The one that=
=20
interests us resides in the readClassDescriptor() method : to load the cl=
ass,=20
it uses resolveClass(String), which seems to be non-standard, instead of =
the=20
resolveClass(ObjectStreamClass). Doing so inhibits the redefinitions of t=
he=20
method in derivated classes (such as RMIObjectInputStream). RMI shows thi=
s bug=20
because it redefines the resolveClass(ObjectStreamClass) in particular in=
=20
order to extract annotations from the object stream. The thrown exception=
 only=20
means that this : annotations have not been read.

It seems that the latest version of java.io.ObjectInputStream in Classpat=
h's=20
CVS fixes at least this bug. I started to integrate it in my local Kaffe,=
 but=20
it seems like I made it a bit too fast :-/ I still have not looked for=20
dependencies upon other classes that are still not present in Kaffe.

Cheers,
Jeremy, ashamed of posting with M$


En r=E9ponse =E0 Dalibor Topic <robilad@kaffe.org>:

> Hi,
>=20
> here's some more information on the RMI merge from Classpath:
>=20
> I've had to replace the RMISecurityManager from Classpath by the old,=20
> insecure RMISecurityManager from kaffe, since it allows basically any=20
> action to be performed, in contrary to the spec. But unfortunately,=20
> using a more restrictive RMISecurityManager, like Classpath's, leads to
>=20
> kaffe not being able to load and link native libraries, in particular=20
> java.net support, which means no Sockets, which in turn kills RMI=20
> completely.
>=20
> So use RMI for now with care. My plan is to switch to Classpath's=20
> SecurityManager eventually. I belive that an implementation of=20
> AccessControl and Policy file parsing will be necessary, as well, in=20
> order to allow privileged actions to work.
>=20
> I've also patched up RMIC a little, on a few occassions. I'll be postin=
g
>=20
> the patches to the Classpath mailing lists for inclusion in their sourc=
e
>=20
> tree.
>=20
> Unfortunately, there are still some bugs. Running the code from the=20
> "Getting Started Using RMI" document[1], I've found some problems with=20
> RMI/serialization code, where I'd need some advice on how to go about=20
> fixing it.
>=20
> In order to repeat what I have, you'll need to fetch=20
> http://java.sun.com/j2se/1.4.2/docs/guide/rmi/archives/getStart.zip
> unzip getStart.zip
> cd getStart
> mkdir examples
> mkdir examples/hello
> mv *.java *.html examples/hello
> kjc examples/hello/*.java
> rmic examples.hello.HelloImpl
> rmiregistry &
>=20
> and then
>=20
> bash-2.05a$ kaffe examples/hello/HelloImpl
> HelloImpl err: Try to read exception object but failed; nested exceptio=
n
> is:
>          java.io.IOException: Data annotated to class was not
> consumed.112
> java.rmi.UnmarshalException: Try to read exception object but failed;=20
> nested exception is:
>          java.io.IOException: Data annotated to class was not
> consumed.112
>     at gnu.java.rmi.server.UnicastRemoteCall.executeCall=20
> (UnicastRemoteCall.java:196)
>     at gnu.java.rmi.server.UnicastRef.invoke (UnicastRef.java:206)
>     at gnu.java.rmi.registry.RegistryImpl_Stub.rebind=20
> (RegistryImpl_Stub.java:230)
>     at java.rmi.Naming.rebind (Naming.java:103)
>     at examples.hello.HelloImpl.main (HelloImpl.java:66)
> Caused by: java.io.IOException: Data annotated to class was not
> consumed.112
>     at java.io.ObjectInputStream.readObject
> (ObjectInputStream.java:232)
>     at java.io.ObjectInputStream.readObject
> (ObjectInputStream.java:272)
>     at gnu.java.rmi.server.UnicastRemoteCall.executeCall=20
> (UnicastRemoteCall.java:191)
>     ...4 more
>=20
> so there seems to be something cheesy with class annotations. Grepping=20
> for annotateClass in gnu/java/rmi/ finds it in=20
> libraries/javalib/gnu/java/rmi/server/RMIObjectOutputStream.java .
>=20
> The spec says that:
> "The annotateClass method is called while a Class is being serialized,=20
> and after the class descriptor has been written to the stream.=20
> Subclasses may extend this method and write other information to the=20
> stream about the class. This information must be read by the=20
> resolveClass method in a corresponding ObjectInputStream subclass."
>=20
> So I'd expect gnu/java/rmi/server/RMIObjectInputStream.java to read in=20
> the annotated information. Which it does, though I'm not sure if it doe=
s
>=20
> so correctly. I'd be grateful if someone with more insight into=20
> serialization could take a look at what's goping wrong.
>=20
> cheers,
> dalibor topic
>=20
>=20
> [1] http://java.sun.com/j2se/1.4.2/docs/guide/rmi/getstart.doc.html
>=20