Issue 2092: RMI/ORB marshalling interface (java2idl-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: The ORB should be responsible for marshalling all value headers and other protocol specific data. The RMI runtime should only marshal the state of the object. In other words, we exepect the contract between the ORB and RMI to be the similar to that of the ORB and an IDL generated ValueHelper. - The APIs should allow all RMI types supported by the IDL-Java mapping to be marshalled completely and correctly. - The APIs should be flexible enough to allow for some change in either RMI/Serialization semantics or changes to OBV wire protocol. Resolution: Closed, accepted Revised Text: 1. Add the following methods to ValueHandler: java.lang.String getRMIRepositoryID(java.lang.Class clz); boolean isCustomMarshaled(java.lang.Class clz); SendingContext.CodeBase getRunTimeCodeBase(); java.io.Serializable writeReplace(java.io.Serializable value); When marshaling an RMI value, the ORB stream must call Util.getCodeBase to get the codebase string, ValueHandler.getRMIRepositoryID to get the repository ID string, and ValueHandler.isCustomMarshaled to see if the value is custom marshaled and therefore requires a chunked encoding. The ORB stream writes the value tag, codebase (if any), and repository ID. It calls ValueHandler.write_Value to write the state of the value. The ORB stream deals with nulls, indirections, chunking, and end tags. The ORB obtains the SendingContextRunTime service context from the ValueHandler by calling the ValueHandler.getRunTimeCodeBase method. Clients must send this service context on the first GIOP request that flows over a connection that may be used to send RMI values to the server. Servers must send this service context on the first GIOP reply that flows over a connection that may be used to send RMI values to the client. The ORB calls the writeReplace method before calling writeValue. The result from calling this method is passed to ValueHandler.writeValue unless either a. it is a previously marshalled value, in which case it is marshalled as an indirection, or b. its class implements org.omg.CORBA.Object, in which case it is marshalled as an object reference. An ORB stream instance must only call writeReplace once for each value that it marshals. 2. Change the names of the ValueHandler read_Value and write_Value methods to readValue and writeValue to be consistent with Java method naming conventions. 3. Change the readValue method of ValueHandler to the following signature: java.io.Serializable readValue( org.omg.CORBA.portable.InputStream in, int offset, java.lang.Class clz, String repositoryID, org.omg.SendingContext.RunTime sender) { ... } When demarshaling an RMI value, the ORB stream must read the value tag, codebase (if any), and repository ID. The ORB stream calls Util.loadClass to load the value's class, passing the Java class name contained in the RMI-style repository ID and the codebase string from the value's GIOP encoding (if present) or the SendingContextRunTime service context. The ORB stream calls ValueHandler.readValue to read the state of the value, passing the current stream offset, the class returned by loadClass, the repository ID, and the sender's SendingContext.RunTime object reference. The repository ID is needed so that the ValueHandler can determine if the class passed in is structurally identical to the class used by the sender to marshal the value. The ORB stream deals with nulls, indirections, chunking, and end tags. 4. Add a new exception org.omg.CORBA.portable.IndirectionException: public class IndirectionException extends org.omg.CORBA.SystemException { int offset; } The ORB input stream throws this exception when it is called to demarshal a value that is encoded as an indirection that is in the process of being demarshalled. This can occur when the ORB stream calls the ValueHandler to demarshal an RMI value whose state contains a recursive reference to itself. Because the top-level ValueHandler.readValue call has not yet returned a value, the ORB stream's indirection table contains no entry for an object with the stream offset specified by the indirection tag. This stream offset is returned in the exception's "offset" field. When the ValueHandler receives this exception, it stores the stream offset together with a reflective object that can be used later to update the field to which the result of calling the ORB stream's read_Value method would have been assigned. These [offset,fieldref] pairs are stored in a "fixup" table that is associated with the InputStream that the ValueHandler is using for its current demarshaling operation. Before the ValueHandler.readValue method returns to the ORB stream, it checks this fixup table for an entry with the offset passed in on the readValue call. If an entry matching the offset is found, it performs a fixup using the reflective fieldref object and the value it is about to return, then removes this fixup entry. When the top-level readValue call returns, the fixup table should be empty, indicating that all fixups have successfully been performed. If the table is not empty, this indicates an incorrect indirection in the GIOP value encoding, and a MARSHAL exception is thrown to indicate this. This scheme deals successfully with recursive references without introducing new API calls and with minimal overheads in the common case of a value that does not contain recursive references. In this case, the only overhead is the need to pass the "offset" parameter on the call to ValueHandler.readValue. Actions taken: October 16, 1998: received issue June 4, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Date: Fri, 16 Oct 1998 18:18:45 +0100 From: Simon Nash Organization: IBM To: issues@omg.org CC: java2idl-rtf@omg.org Subject: RMI/ORB marshalling interface The following Java to IDL issue was raised by George Scott. It needs to be added to the issues database. - The ORB should be responsible for marshalling all value headers and other protocol specific data. The RMI runtime should only marshal the state of the object. In other words, we exepect the contract between the ORB and RMI to be the similar to that of the ORB and an IDL generated ValueHelper. - The APIs should allow all RMI types supported by the IDL-Java mapping to be marshalled completely and correctly. - The APIs should be flexible enough to allow for some change in either RMI/Serialization semantics or changes to OBV wire protocol. Simon -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb