Issue 2089: Custom marshalling wire format (java2idl-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: The full wire format produced by ObjectOutputStream really needs to be specified. E.g., I would assume that anything written with writeObject gets marshalled as an Any. In normal Java serialization, consecutive primitive writes (writeByte, writeInt, etc.) are aggregated into chunks with size lengths, and tagged to distinguish it from other data. In this way, ObjectInputStream can ensure that major stream corruption never occurs: it can make sure that a primitive read never eats into object data, and vice versa. Is a similar format used for IIOP? Resolution: Closed, accepted Revised Text: In section 28.3.5.6, change the mapping for Serializable classes with a writeObject method so that non-public fields are mapped to IDL private fields in the custom valuetype. Add the following section after section 28.3.5.6: 28.3.5.7 Custom Marshaling Format When an RMI/IDL value type is custom marshaled over GIOP, the following data is transmitted: 1. Serializable objects with a writeObject method. octet Format version. Always 1. boolean True if defaultWriteObject was called, false otherwise. ... (optional) Data written by defaultWriteObject. The ordering of the fields is the same as the order in which they appear in the mapped IDL valuetype, and these fields are encoded exactly as they would be if the class did not have a writeObject method. ... (optional) Additional data written by writeObject, encoded as specified below. 2. Externalizable objects. octet Format version. Always 1. ... (optional) Data written by writeExternal, encoded as specified below. Primitive Java types are marshaled as their corresponding IDL primitives (see section 28.3.3). Java objects are marshaled in the form of an IDL abstract interface, i.e., a union with a boolean discriminator containing either an object reference if the discriminator is true or a value type if the discriminator is false. RMI/IDL stubs, RMI/IDL remote implementations, and IDL stubs are marshaled as object references (IORs). All other Java objects are marshaled as value types. The value type encoding is determined from the object's runtime type by applying the mappings specified in sections 28.3.5, 28.3.6, and 28.3.7. This encoding ensures that primitive data is marshaled using a chunked encoding and cannot incorrectly be read in as object data. The GIOP specification states that custom marshaled types must be marshaled using a chunked encoding. Therefore, if primitive data is written followed by a value object, the currently open chunk for the primitive data will automatically be ended before the value tag is written. This prevents primitive read operations from consuming a value header (chunk underflow), and also prevents read_Value operations from consuming primitive data (chunk overflow). This mechanism does not prevent primitive reads from consuming non-matching primitive data, which is also true for Java deserialization. However, it is possible for primitive reads to consume IOR data, and vice versa. Reading an incorrect IOR will either cause a MARSHAL error or in rare cases create an unusable object reference (e.g., incorrect host name, port number, or object key). Since neither of these violates the integrity of the local system, this small exposure is acceptable. Actions taken: October 16, 1998: received issue June 4, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Date: Fri, 16 Oct 1998 17:56:03 +0100 From: Simon Nash Organization: IBM To: issues@omg.org CC: java2idl-rtf@omg.org Subject: Custom marshalling wire format The following Java to IDL issue was raised by Bob Scheifler. It needs to be added to the issues database. The full wire format produced by ObjectOutputStream really needs to be specified. E.g., I would assume that anything written with writeObject gets marshalled as an Any. In normal Java serialization, consecutive primitive writes (writeByte, writeInt, etc.) are aggregated into chunks with size lengths, and tagged to distinguish it from other data. In this way, ObjectInputStream can ensure that major stream corruption never occurs: it can make sure that a primitive read never eats into object data, and vice versa. Is a similar format used for IIOP? 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