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 <[EMAIL PROTECTED]>: > 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 > _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
