[kaffe] Re: RMI bugs and quirks

[Jeremy.Buisson at irisa.fr]

Hi,

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

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

Cheers,
Jeremy, ashamed of posting with M$


En réponse à Dalibor Topic <robilad at kaffe.org>:

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