Issue 4795: RMI-IIOP interop bet. J2SE 1.3 and 1.4 (java2idl-rtf) Source: Oracle (Mr. Everett Anderson, ) Nature: Uncategorized Issue Severity: Critical Summary: I'd like to raise the following as an urgent issue for the Java to IDL RTF: RuntimeExceptions/Errors are broken in RMI-IIOP when interoperating between J2SE 1.3 and 1.4 (or "class evolution in service contexts is broken"). When an unchecked exception (RuntimeException, Error) occurs in RMI-IIOP, it is translated into a CORBA UNKNOWN system exception, and the real Java exception is marshaled as a CDR encapsulation in the UnknownExceptionInfo service context. (Java to IDL formal 01-06-07 1.4.7, 1.4.8.1) In J2SE 1.4, java.lang.Throwable has evolved to add several new non-transient fields including private Throwable cause; private StackTraceElement[] stackTrace; This means that when J2SE 1.3.x talks to 1.4 and an unchecked exception occurs, there is a class evolution scenario occurring inside of the UnknownExceptionInfo service context. Normally, class evolution is handled by using the SendingContextRunTime CodeBase to find out what the sender put on the wire. This service context is sent by the client on the first request on a connection and by the server on the first reply on a connection. (Java to IDL formal 01-06-07 1.5.1) This presents two problems: 1. Since the UnknownExceptionInfo service context has the Throwable in an encapsulation, technically it has no connection information. 2. Even if we assumed that we use the connection on which this encapsulation is transmitted, we would need to make sure that the SendingContextRunTime service context is unmarshaled BEFORE the UnknownExceptionInfo service context so that the connection has the CodeBase to use to unmarshal the evolved Throwable class. Here are two possible solutions: 1. Service context ordering proposal (strawman): Require that service context encapsulations use the connection on which they are sent if they need the CodeBase, and that the UnknownExceptionInfo service context must be unmarshaled after the SendingContextRunTime service context. Specifically, add this language to the Java to IDL spec in section 1.4.8.1. Note: We may need to be careful not to generalize to all service contexts. For instance, code sets for wstring/wchar inside of service context encapsulations should probably be explicitly stated when defining the service context at the spec level. 2. New service context & backwards compatibility proposal: Add a new UnknownExceptionInfo service context called something like UnknownExceptionInfoPlusCodeBase service context. It contains the CodeBase IOR followed by the java.lang.Throwable. Thus, all necessary information is contained, and we can support evolution going forward in this particular service context. Older receivers would just disregard it. For backwards compatibility with J2SE 1.3 and before, we must still also send the original UnknownExceptionInfo service context containing something that looks like the J2SE 1.3 java.lang.Throwable class. Thus, we must define the format of this new structure and how to translate from J2SE 1.4 or later Throwables to it. Resolution: see below Revised Text: Add a new paragraph at the end of section 1.4.7 of the Java to IDL mapping specification, as follows: "In order to support versioning of the Java exception marshaled within an UnknownExceptionInfo service context, a SendingContextRunTime service context must previously have been processed for the connection. If a GIOP message carrying both an UnknownExceptionInfo service context and a SendingContextRunTime service context is received, and no SendingContextRunTime service context has previously been processed for this connection, then the SendingContextRunTime service context must be processed before the data within the UnknownExceptionInfo service context is unmarshaled." Actions taken: December 19, 2001: received issue May 13, 2002: closed issue Discussion: Resolution: In order to make progress on issue 4795, the proposal is that we split it into two parts: a) the immediate need to fix an interoperability problem between JDK 1.3 and JDK 1.4 when certain exceptions are thrown b) the desire expressed by many RTF members and others to allow full type information to be sent with valuetypes, so that callbacks to the SendingContextRunTime aren't needed for versioning This split would allow us to do a fix for part a) in this RTF to close this issue and allow JDK 1.3 to talk to JDK 1.4 correctly, and raise a new issue for part b) to be resolved by the next RTF. The fix for part b) could be part of a new GIOP level and might involve fairly significant CDR changes. The proposed resolution to part a) is to require that the SendingContextRunTime service context be processed before the UnknownExceptionInfo service context. If the UnknownExceptionInfo service context happens to physically precede the SendingContextRunTime service context on the wire, and no SendingContextRunTime service context had previously been processed for the connection, then the UnknownExceptionInfo service context would have to be copied to a temporary buffer and its data unmarshalled after the SendingContextRunTime service context has been processed. This should be quite easy to implement, and could be retrofitted to JDK 1.3 in a service update. Adopting this resolution for the immediate problem would not preclude making a further change later to add optional type information to CDR valuetypes so that the need for a callback could be eliminated. End of Annotations:===== Date: Tue, 18 Dec 2001 14:16:09 -0800 From: Everett Anderson X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf,ja MIME-Version: 1.0 To: issues@omg.org, java-rtf@omg.org Subject: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3 and 1.4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: D8!!!N);!!&(X!!\#e!! Hi, I'd like to raise the following as an urgent issue for the Java to IDL RTF: RuntimeExceptions/Errors are broken in RMI-IIOP when interoperating between J2SE 1.3 and 1.4 (or "class evolution in service contexts is broken"). When an unchecked exception (RuntimeException, Error) occurs in RMI-IIOP, it is translated into a CORBA UNKNOWN system exception, and the real Java exception is marshaled as a CDR encapsulation in the UnknownExceptionInfo service context. (Java to IDL formal 01-06-07 1.4.7, 1.4.8.1) In J2SE 1.4, java.lang.Throwable has evolved to add several new non-transient fields including private Throwable cause; private StackTraceElement[] stackTrace; This means that when J2SE 1.3.x talks to 1.4 and an unchecked exception occurs, there is a class evolution scenario occurring inside of the UnknownExceptionInfo service context. Normally, class evolution is handled by using the SendingContextRunTime CodeBase to find out what the sender put on the wire. This service context is sent by the client on the first request on a connection and by the server on the first reply on a connection. (Java to IDL formal 01-06-07 1.5.1) This presents two problems: 1. Since the UnknownExceptionInfo service context has the Throwable in an encapsulation, technically it has no connection information. 2. Even if we assumed that we use the connection on which this encapsulation is transmitted, we would need to make sure that the SendingContextRunTime service context is unmarshaled BEFORE the UnknownExceptionInfo service context so that the connection has the CodeBase to use to unmarshal the evolved Throwable class. Here are two possible solutions: 1. Service context ordering proposal (strawman): Require that service context encapsulations use the connection on which they are sent if they need the CodeBase, and that the UnknownExceptionInfo service context must be unmarshaled after the SendingContextRunTime service context. Specifically, add this language to the Java to IDL spec in section 1.4.8.1. Note: We may need to be careful not to generalize to all service contexts. For instance, code sets for wstring/wchar inside of service context encapsulations should probably be explicitly stated when defining the service context at the spec level. 2. New service context & backwards compatibility proposal: Add a new UnknownExceptionInfo service context called something like UnknownExceptionInfoPlusCodeBase service context. It contains the CodeBase IOR followed by the java.lang.Throwable. Thus, all necessary information is contained, and we can support evolution going forward in this particular service context. Older receivers would just disregard it. For backwards compatibility with J2SE 1.3 and before, we must still also send the original UnknownExceptionInfo service context containing something that looks like the J2SE 1.3 java.lang.Throwable class. Thus, we must define the format of this new structure and how to translate from J2SE 1.4 or later Throwables to it. - Everett Date: Tue, 18 Dec 2001 22:37:18 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: java2idl-rtf@omg.org Subject: [Fwd: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3 and 1.4] Content-Type: multipart/mixed; boundary="------------C3806858307AF41D3A554D0F" X-UIDL: )FG!!'(T!!551e9AK:!! I think Everett meant to copy this to the java2idl-rtf list, not java-rtf. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgbReceived: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [9.20.62.15]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA35408 for ; Tue, 18 Dec 2001 22:19:08 GMT Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA23806 for ; Tue, 18 Dec 2001 22:19:07 GMT Received: from ha2sca-mail1.SFBay.Sun.COM ([129.145.155.62]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA01108; Tue, 18 Dec 2001 14:18:53 -0800 (PST) Received: from sun.com (d-usca14-133-108 [129.145.133.108]) by ha2sca-mail1.SFBay.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.1p1) with ESMTP id fBIMIro22799; Tue, 18 Dec 2001 14:18:53 -0800 (PST) Message-ID: <3C1FC029.9CF89069@sun.com> Date: Tue, 18 Dec 2001 14:16:09 -0800 From: Everett Anderson X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf,ja MIME-Version: 1.0 To: issues@omg.org, java-rtf@omg.org Subject: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3 and 1.4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mozilla-Status2: 00000000 Hi, I'd like to raise the following as an urgent issue for the Java to IDL RTF: RuntimeExceptions/Errors are broken in RMI-IIOP when interoperating between J2SE 1.3 and 1.4 (or "class evolution in service contexts is broken"). When an unchecked exception (RuntimeException, Error) occurs in RMI-IIOP, it is translated into a CORBA UNKNOWN system exception, and the real Java exception is marshaled as a CDR encapsulation in the UnknownExceptionInfo service context. (Java to IDL formal 01-06-07 1.4.7, 1.4.8.1) In J2SE 1.4, java.lang.Throwable has evolved to add several new non-transient fields including private Throwable cause; private StackTraceElement[] stackTrace; This means that when J2SE 1.3.x talks to 1.4 and an unchecked exception occurs, there is a class evolution scenario occurring inside of the UnknownExceptionInfo service context. Normally, class evolution is handled by using the SendingContextRunTime CodeBase to find out what the sender put on the wire. This service context is sent by the client on the first request on a connection and by the server on the first reply on a connection. (Java to IDL formal 01-06-07 1.5.1) This presents two problems: 1. Since the UnknownExceptionInfo service context has the Throwable in an encapsulation, technically it has no connection information. 2. Even if we assumed that we use the connection on which this encapsulation is transmitted, we would need to make sure that the SendingContextRunTime service context is unmarshaled BEFORE the UnknownExceptionInfo service context so that the connection has the CodeBase to use to unmarshal the evolved Throwable class. Here are two possible solutions: 1. Service context ordering proposal (strawman): Require that service context encapsulations use the connection on which they are sent if they need the CodeBase, and that the UnknownExceptionInfo service context must be unmarshaled after the SendingContextRunTime service context. Specifically, add this language to the Java to IDL spec in section 1.4.8.1. Note: We may need to be careful not to generalize to all service contexts. For instance, code sets for wstring/wchar inside of service context encapsulations should probably be explicitly stated when defining the service context at the spec level. 2. New service context & backwards compatibility proposal: Add a new UnknownExceptionInfo service context called something like UnknownExceptionInfoPlusCodeBase service context. It contains the CodeBase IOR followed by the java.lang.Throwable. Thus, all necessary information is contained, and we can support evolution going forward in this particular service context. Older receivers would just disregard it. For backwards compatibility with J2SE 1.3 and before, we must still also send the original UnknownExceptionInfo service context containing something that looks like the J2SE 1.3 java.lang.Throwable class. Thus, we must define the format of this new structure and how to translate from J2SE 1.4 or later Throwables to it. - Everett Date: Tue, 18 Dec 2001 22:45:45 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Everett Anderson CC: java-rtf@omg.org, java2idl-rtf@omg.org, orb_revision@omg.org Subject: Re: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3 and 1.4 References: <3C1FC029.9CF89069@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: i5!! Everett, I prefer your option 1 since I don't like having to marshal the Throwable twice. SendingContextRunTime is not a java2idl thing; it is defined in chapter 5 of the CORBA core. Any change to the processing of this service context would need to be approved by the Core RTF. Is there any significance in the physical ordering of service contexts on the wire with respect to the order of processing them? Simon Everett Anderson wrote: > > Hi, > > I'd like to raise the following as an urgent issue for the Java to IDL > RTF: > > RuntimeExceptions/Errors are broken in RMI-IIOP when interoperating > between J2SE 1.3 and 1.4 (or "class evolution in service contexts is > broken"). > > When an unchecked exception (RuntimeException, Error) occurs in > RMI-IIOP, it is translated into a CORBA UNKNOWN system exception, and > the real Java exception is marshaled as a CDR encapsulation in the > UnknownExceptionInfo service context. (Java to IDL formal 01-06-07 > 1.4.7, 1.4.8.1) > > In J2SE 1.4, java.lang.Throwable has evolved to add several new > non-transient fields including > > private Throwable cause; > private StackTraceElement[] stackTrace; > > This means that when J2SE 1.3.x talks to 1.4 and an unchecked > exception occurs, there is a class evolution scenario occurring inside > of the UnknownExceptionInfo service context. Normally, class > evolution is handled by using the SendingContextRunTime CodeBase to > find out what the sender put on the wire. This service context is > sent by the client on the first request on a connection and by the > server on the first reply on a connection. (Java to IDL formal > 01-06-07 1.5.1) > > This presents two problems: > > 1. Since the UnknownExceptionInfo service context has the Throwable > in an encapsulation, technically it has no connection information. > > 2. Even if we assumed that we use the connection on which this > encapsulation is transmitted, we would need to make sure that the > SendingContextRunTime service context is unmarshaled BEFORE the > UnknownExceptionInfo service context so that the connection has the > CodeBase to use to unmarshal the evolved Throwable class. > > Here are two possible solutions: > > 1. Service context ordering proposal (strawman): > > Require that service context encapsulations use the connection on > which they are sent if they need the CodeBase, and that the > UnknownExceptionInfo service context must be unmarshaled after the > SendingContextRunTime service context. Specifically, add this > language to the Java to IDL spec in section 1.4.8.1. > > Note: We may need to be careful not to generalize to all service > contexts. For instance, code sets for wstring/wchar inside of service > context encapsulations should probably be explicitly stated when > defining the service context at the spec level. > > 2. New service context & backwards compatibility proposal: > > Add a new UnknownExceptionInfo service context called something like > UnknownExceptionInfoPlusCodeBase service context. It contains the > CodeBase IOR followed by the java.lang.Throwable. Thus, all necessary > information is contained, and we can support evolution going forward > in this particular service context. Older receivers would just > disregard it. > > For backwards compatibility with J2SE 1.3 and before, we must still > also send the original UnknownExceptionInfo service context containing > something that looks like the J2SE 1.3 java.lang.Throwable class. > Thus, we must define the format of this new structure and how to > translate from J2SE 1.4 or later Throwables to it. > > - Everett -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Dec 2001 15:00:48 -0800 To: Simon Nash , Everett Anderson From: Andy Piper Subject: Re: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3 and 1.4 Cc: java-rtf@omg.org, java2idl-rtf@omg.org, orb_revision@omg.org In-Reply-To: <3C1FC719.8AE65B72@hursley.ibm.com> References: <3C1FC029.9CF89069@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: #l\!!S`@!!ElCe9FeT!! FWIW I'm uncomfortable with SendingContextRuntime having to be supported to process something as fundamental as exceptions. Especially as there are currently incompatible bugs in the JDK 1.3 and 1.4 with this. I would prefer that we define some sort of portable Throwable. andy At 10:45 PM 12/18/2001 +0000, Simon Nash wrote: Everett, I prefer your option 1 since I don't like having to marshal the Throwable twice. SendingContextRunTime is not a java2idl thing; it is defined in chapter 5 of the CORBA core. Any change to the processing of this service context would need to be approved by the Core RTF. Is there any significance in the physical ordering of service contexts on the wire with respect to the order of processing them? Simon Everett Anderson wrote: > > Hi, > > I'd like to raise the following as an urgent issue for the Java to IDL > RTF: > > RuntimeExceptions/Errors are broken in RMI-IIOP when interoperating > between J2SE 1.3 and 1.4 (or "class evolution in service contexts is > broken"). > > When an unchecked exception (RuntimeException, Error) occurs in > RMI-IIOP, it is translated into a CORBA UNKNOWN system exception, and > the real Java exception is marshaled as a CDR encapsulation in the > UnknownExceptionInfo service context. (Java to IDL formal 01-06-07 > 1.4.7, 1.4.8.1) > > In J2SE 1.4, java.lang.Throwable has evolved to add several new > non-transient fields including > > private Throwable cause; > private StackTraceElement[] stackTrace; > > This means that when J2SE 1.3.x talks to 1.4 and an unchecked > exception occurs, there is a class evolution scenario occurring inside > of the UnknownExceptionInfo service context. Normally, class > evolution is handled by using the SendingContextRunTime CodeBase to > find out what the sender put on the wire. This service context is > sent by the client on the first request on a connection and by the > server on the first reply on a connection. (Java to IDL formal > 01-06-07 1.5.1) > > This presents two problems: > > 1. Since the UnknownExceptionInfo service context has the Throwable > in an encapsulation, technically it has no connection information. > > 2. Even if we assumed that we use the connection on which this > encapsulation is transmitted, we would need to make sure that the > SendingContextRunTime service context is unmarshaled BEFORE the > UnknownExceptionInfo service context so that the connection has the > CodeBase to use to unmarshal the evolved Throwable class. > > Here are two possible solutions: > > 1. Service context ordering proposal (strawman): > > Require that service context encapsulations use the connection on > which they are sent if they need the CodeBase, and that the > UnknownExceptionInfo service context must be unmarshaled after the > SendingContextRunTime service context. Specifically, add this > language to the Java to IDL spec in section 1.4.8.1. > > Note: We may need to be careful not to generalize to all service > contexts. For instance, code sets for wstring/wchar inside of service > context encapsulations should probably be explicitly stated when > defining the service context at the spec level. > > 2. New service context & backwards compatibility proposal: > > Add a new UnknownExceptionInfo service context called something like > UnknownExceptionInfoPlusCodeBase service context. It contains the > CodeBase IOR followed by the java.lang.Throwable. Thus, all necessary > information is contained, and we can support evolution going forward > in this particular service context. Older receivers would just > disregard it. > > For backwards compatibility with J2SE 1.3 and before, we must still > also send the original UnknownExceptionInfo service context containing > something that looks like the J2SE 1.3 java.lang.Throwable class. > Thus, we must define the format of this new structure and how to > translate from J2SE 1.4 or later Throwables to it. > > - Everett -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Tue, 18 Dec 2001 15:17:37 -0800 From: Everett Anderson X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf,ja MIME-Version: 1.0 To: Simon Nash CC: java-rtf@omg.org, java2idl-rtf@omg.org, orb_revision@omg.org Subject: Re: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3 and 1.4 References: <3C1FC029.9CF89069@sun.com> <3C1FC719.8AE65B72@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 4\0e9Tbld9%2@!!d`$!! Hi, Bob Scheifler just pointed out that this also occurs for all java.rmi.RemoteExceptions and their subclasses. (It doesn't occur for normal user exceptions, though.) > I prefer your option 1 since I don't like having to marshal the Throwable twice. > > SendingContextRunTime is not a java2idl thing; it is defined in chapter 5 of > the CORBA core. Any change to the processing of this service context would need > to be approved by the Core RTF. I guess I'm in favor of the second proposal -- it doesn't require changing anything about the SendingContextRunTime service context. > Is there any significance in the physical ordering of service contexts on the > wire with respect to the order of processing them? You can process them in any order. However, in general CORBA has seemed opposed to ordering. For instance, if you have a large number of service contexts spread across multiple fragments, you would need to keep them in memory until you have all of them, then order them, then unmarshal them. With respect to Andy's comments: I don't want to lose the ability of J2SE 1.4 to transmit the root cause exception or even the stack trace information if possible. Also, it would be nice to take advantage of future improvements in Throwable after J2SE 1.4. Furthermore, this issue could occur for any RMI-IIOP types in service contexts. While it is unfortunate that Sun's ValueHandler and CodeBase implementation have had some bugs, for instance returning a tk_string rather than a tk_wstring type code when describing that a Java class has a certain java.lang.String field, I feel it is somewhat inappropriate to make spec decisions due to the shortcomings of one implementation. In this case, since Sun is responsible for providing a CodeBase implementation for RMI-IIOP, though, perhaps we can do so. Still, even if we define a new portable Throwable, we would need to do the same thing as my proposal with the double marshaling for backwards compatibility unless we made it look exactly like the wire form of J2SE 1.3's Throwable. - Everett > > Everett Anderson wrote: > > > > Hi, > > > > I'd like to raise the following as an urgent issue for the Java to > IDL > > RTF: > > > > RuntimeExceptions/Errors are broken in RMI-IIOP when > interoperating > > between J2SE 1.3 and 1.4 (or "class evolution in service contexts > is > > broken"). > > > > When an unchecked exception (RuntimeException, Error) occurs in > > RMI-IIOP, it is translated into a CORBA UNKNOWN system exception, > and > > the real Java exception is marshaled as a CDR encapsulation in the > > UnknownExceptionInfo service context. (Java to IDL formal > 01-06-07 > > 1.4.7, 1.4.8.1) > > > > In J2SE 1.4, java.lang.Throwable has evolved to add several new > > non-transient fields including > > > > private Throwable cause; > > private StackTraceElement[] stackTrace; > > > > This means that when J2SE 1.3.x talks to 1.4 and an unchecked > > exception occurs, there is a class evolution scenario occurring > inside > > of the UnknownExceptionInfo service context. Normally, class > > evolution is handled by using the SendingContextRunTime CodeBase > to > > find out what the sender put on the wire. This service context is > > sent by the client on the first request on a connection and by the > > server on the first reply on a connection. (Java to IDL formal > > 01-06-07 1.5.1) > > > > This presents two problems: > > > > 1. Since the UnknownExceptionInfo service context has the > Throwable > > in an encapsulation, technically it has no connection information. > > > > 2. Even if we assumed that we use the connection on which this > > encapsulation is transmitted, we would need to make sure that the > > SendingContextRunTime service context is unmarshaled BEFORE the > > UnknownExceptionInfo service context so that the connection has > the > > CodeBase to use to unmarshal the evolved Throwable class. > > > > Here are two possible solutions: > > > > 1. Service context ordering proposal (strawman): > > > > Require that service context encapsulations use the connection on > > which they are sent if they need the CodeBase, and that the > > UnknownExceptionInfo service context must be unmarshaled after the > > SendingContextRunTime service context. Specifically, add this > > language to the Java to IDL spec in section 1.4.8.1. > > > > Note: We may need to be careful not to generalize to all service > > contexts. For instance, code sets for wstring/wchar inside of > service > > context encapsulations should probably be explicitly stated when > > defining the service context at the spec level. > > > > 2. New service context & backwards compatibility proposal: > > > > Add a new UnknownExceptionInfo service context called something > like > > UnknownExceptionInfoPlusCodeBase service context. It contains the > > CodeBase IOR followed by the java.lang.Throwable. Thus, all > necessary > > information is contained, and we can support evolution going > forward > > in this particular service context. Older receivers would just > > disregard it. > > > > For backwards compatibility with J2SE 1.3 and before, we must > still > > also send the original UnknownExceptionInfo service context > containing > > something that looks like the J2SE 1.3 java.lang.Throwable class. > > Thus, we must define the format of this new structure and how to > > translate from J2SE 1.4 or later Throwables to it. > > > > - Everett > > -- > Simon C Nash, Chief Technical Officer, IBM Java Technology > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Dec 2001 15:47:11 -0800 To: Everett Anderson , Simon Nash From: Andy Piper Subject: Re: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3 and 1.4 Cc: java-rtf@omg.org, java2idl-rtf@omg.org, orb_revision@omg.org In-Reply-To: <3C1FCE91.3E53156A@sun.com> References: <3C1FC029.9CF89069@sun.com> <3C1FC719.8AE65B72@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: (Med9ic?e9^G+e9$!K!! With respect to Andy's comments: I don't want to lose the ability of J2SE 1.4 to transmit the root cause exception or even the stack trace information if possible. Also, it would be nice to take advantage of future improvements in Throwable after J2SE 1.4. Furthermore, this issue could occur for any RMI-IIOP types in service contexts. The issue for me is what happens if there is an error while you are trying to access the codebase? This could easily happen - and given that an error has already occured (a system-level error not a user error) what hope do you have that you will even be able to contact the target to figure out what the exception looks like? This IMO will result in extreme unusability when you need it least (you're trying to figure out what went wrong). I would prefer at least some fallback, e.g. marshal a portable Throwable that everyone knows how to deal with and then nest the extra data opaquely somewhere - just as we do for UNKNOWN. While it is unfortunate that Sun's ValueHandler and CodeBase implementation have had some bugs, for instance returning a tk_string rather than a tk_wstring type code when describing that a Java class has a certain java.lang.String field, I feel it is somewhat inappropriate to make spec decisions due to the shortcomings of one implementation. In this case, since Sun is responsible for providing a CodeBase implementation for RMI-IIOP, though, perhaps we can do so. I don't disagree that allowing evolution in this instance is a good thing, I do disagree that it should be the only thing. Still, even if we define a new portable Throwable, we would need to do the same thing as my proposal with the double marshaling for backwards compatibility unless we made it look exactly like the wire form of J2SE 1.3's Throwable. That seems reasonable to me :) andy Date: Tue, 18 Dec 2001 15:52:11 -0800 From: Everett Anderson X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf,ja MIME-Version: 1.0 To: Andy Piper CC: Simon Nash , java-rtf@omg.org, java2idl-rtf@omg.org, orb_revision@omg.org Subject: Re: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3and 1.4 References: <3C1FC029.9CF89069@sun.com> <3C1FC719.8AE65B72@hursley.ibm.com> <4.3.2.7.2.20011218154149.00a9ccf8@san-francisco.beasys.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: The issue for me is what happens if there is an error while you are trying > to access the codebase? This could easily happen - and given that an error > has already occured (a system-level error not a user error) what hope do > you have that you will even be able to contact the target to figure out > what the exception looks like? This IMO will result in extreme unusability That's a good point. I think this kind of thing would probably result in mapping the CORBA system exception (probably COMM_FAILURE or MARSHAL) to a type of RemoteException as in section 1.4.8. Before J2SE 1.4 which has the ability to nest the root cause exception, it is quite difficult to figure out what really went wrong. > I don't disagree that allowing evolution in this instance is a good thing, > I do disagree that it should be the only thing. > > >Still, even if we define a new portable Throwable, we would need to do > >the same thing as my proposal with the double marshaling for backwards > >compatibility unless we made it look exactly like the wire form of > >J2SE 1.3's Throwable. > > That seems reasonable to me :) In that case, it sounds a lot like my second proposal. For instance, we could continue to marshal the UnknownExceptionInfo service context using what looks like the J2SE 1.3 Throwable format. Then, we could add a new service context which newer systems could choose to use that has the CodeBase and newer exception form. This sounds good to me. The trick is that if you want to fall back on the old UnknownExceptionInfo service context, you need to get it off the stream first rather than start looking inside the newer service context. Perhaps this ordering is okay since even new systems could just ignore the newer service context -- it is just a feature issue. - Everett Date: Tue, 18 Dec 2001 15:55:58 -0800 From: Everett Anderson X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf,ja MIME-Version: 1.0 To: Andy Piper CC: Simon Nash , java-rtf@omg.org, java2idl-rtf@omg.org, orb_revision@omg.org Subject: Re: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3and 1.4 References: <3C1FC029.9CF89069@sun.com> <3C1FC719.8AE65B72@hursley.ibm.com> <4.3.2.7.2.20011218154149.00a9ccf8@san-francisco.beasys.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: :4Le9dnSd9V/p!!kP1!! Hi Andy, > The issue for me is what happens if there is an error while you are trying > to access the codebase? This could easily happen - and given that an error > has already occured (a system-level error not a user error) what hope do > you have that you will even be able to contact the target to figure out > what the exception looks like? This IMO will result in extreme unusability > when you need it least (you're trying to figure out what went wrong). I > would prefer at least some fallback, e.g. marshal a portable Throwable that > everyone knows how to deal with and then nest the extra data opaquely > somewhere - just as we do for UNKNOWN. I just want to make sure we're on the same page, here. My issue is only about the transmission of RemoteExceptions (and subclasses) and unchecked exceptions via the UNKNOWN+UnknownExceptionInfo service context mechanism. I am not trying to address the general case that normal user exceptions marshaled in the message body between J2SE 1.3 and 1.4 are subject to class evolution that requires a CodeBase. I do not think it is appropriate to change this part of the spec since it does work as is. From: "Andy Piper" To: "Everett Anderson" Cc: "Simon Nash" , , , Subject: RE: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3and 1.4 Date: Tue, 18 Dec 2001 16:08:51 -0800 Message-ID: <004901c18821$56aef750$947ba8c0@TSUNAMI> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3C1FD78E.4C084CFD@sun.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: oo!"!T`[!!*?De9'E$e9 Right. andy > -----Original Message----- > From: Everett Anderson [mailto:everett.anderson@sun.com] > Sent: Tuesday, December 18, 2001 3:56 PM > To: Andy Piper > Cc: Simon Nash; java-rtf@omg.org; java2idl-rtf@omg.org; > orb_revision@omg.org > Subject: Re: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3and > 1.4 > > > Hi Andy, > > > The issue for me is what happens if there is an error while you > are trying > > to access the codebase? This could easily happen - and given > that an error > > has already occured (a system-level error not a user error) what hope do > > you have that you will even be able to contact the target to figure out > > what the exception looks like? This IMO will result in extreme > unusability > > when you need it least (you're trying to figure out what went wrong). I > > would prefer at least some fallback, e.g. marshal a portable > Throwable that > > everyone knows how to deal with and then nest the extra data opaquely > > somewhere - just as we do for UNKNOWN. > > I just want to make sure we're on the same page, here. My issue is > only about the transmission of RemoteExceptions (and subclasses) and > unchecked exceptions via the UNKNOWN+UnknownExceptionInfo service > context mechanism. > > I am not trying to address the general case that normal user > exceptions marshaled in the message body between J2SE 1.3 and 1.4 are > subject to class evolution that requires a CodeBase. I do not think > it is appropriate to change this part of the spec since it does work > as is. > From: Jeffrey Mischkinsky Message-Id: <200112190151.RAA02126@wheel.dcn.davis.ca.us> Subject: Re: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3 and 1.4 To: everett.anderson@sun.com (Everett Anderson) Date: Tue, 18 Dec 2001 17:51:54 -0800 (PST) Cc: nash@hursley.ibm.com (Simon Nash), java-rtf@omg.org, java2idl-rtf@omg.org, orb_revision@omg.org In-Reply-To: <3C1FCE91.3E53156A@sun.com> from "Everett Anderson" at Dec 18, 2001 03:17:37 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: G[S!!^o?e9VO$e9Q`f!! 'Everett Anderson' writes: > > While it is unfortunate that Sun's ValueHandler and CodeBase > implementation have had some bugs, for instance returning a tk_string > rather than a tk_wstring type code when describing that a Java class > has a certain java.lang.String field, I feel it is somewhat > inappropriate to make spec decisions due to the shortcomings of one > implementation. In this case, since Sun is responsible for providing > a CodeBase implementation for RMI-IIOP, though, perhaps we can do so. Under the "new" rules, vendors will be allowed to replace broken code in the JDK with correctly functioning code, so this should not be an issue anymore (except for those who actually use the JDK code :-) jeff > > Still, even if we define a new portable Throwable, we would need to do > the same thing as my proposal with the double marshaling for backwards > compatibility unless we made it look exactly like the wire form of > J2SE 1.3's Throwable. > > - Everett > > > > > > > Everett Anderson wrote: > > > > > > Hi, > > > > > > I'd like to raise the following as an urgent issue for the Java to IDL > > > RTF: > > > > > > RuntimeExceptions/Errors are broken in RMI-IIOP when interoperating > > > between J2SE 1.3 and 1.4 (or "class evolution in service contexts is > > > broken"). > > > > > > When an unchecked exception (RuntimeException, Error) occurs in > > > RMI-IIOP, it is translated into a CORBA UNKNOWN system exception, and > > > the real Java exception is marshaled as a CDR encapsulation in the > > > UnknownExceptionInfo service context. (Java to IDL formal 01-06-07 > > > 1.4.7, 1.4.8.1) > > > > > > In J2SE 1.4, java.lang.Throwable has evolved to add several new > > > non-transient fields including > > > > > > private Throwable cause; > > > private StackTraceElement[] stackTrace; > > > > > > This means that when J2SE 1.3.x talks to 1.4 and an unchecked > > > exception occurs, there is a class evolution scenario occurring inside > > > of the UnknownExceptionInfo service context. Normally, class > > > evolution is handled by using the SendingContextRunTime CodeBase to > > > find out what the sender put on the wire. This service context is > > > sent by the client on the first request on a connection and by the > > > server on the first reply on a connection. (Java to IDL formal > > > 01-06-07 1.5.1) > > > > > > This presents two problems: > > > > > > 1. Since the UnknownExceptionInfo service context has the Throwable > > > in an encapsulation, technically it has no connection information. > > > > > > 2. Even if we assumed that we use the connection on which this > > > encapsulation is transmitted, we would need to make sure that the > > > SendingContextRunTime service context is unmarshaled BEFORE the > > > UnknownExceptionInfo service context so that the connection has the > > > CodeBase to use to unmarshal the evolved Throwable class. > > > > > > Here are two possible solutions: > > > > > > 1. Service context ordering proposal (strawman): > > > > > > Require that service context encapsulations use the connection on > > > which they are sent if they need the CodeBase, and that the > > > UnknownExceptionInfo service context must be unmarshaled after the > > > SendingContextRunTime service context. Specifically, add this > > > language to the Java to IDL spec in section 1.4.8.1. > > > > > > Note: We may need to be careful not to generalize to all service > > > contexts. For instance, code sets for wstring/wchar inside of service > > > context encapsulations should probably be explicitly stated when > > > defining the service context at the spec level. > > > > > > 2. New service context & backwards compatibility proposal: > > > > > > Add a new UnknownExceptionInfo service context called something like > > > UnknownExceptionInfoPlusCodeBase service context. It contains the > > > CodeBase IOR followed by the java.lang.Throwable. Thus, all necessary > > > information is contained, and we can support evolution going forward > > > in this particular service context. Older receivers would just > > > disregard it. > > > > > > For backwards compatibility with J2SE 1.3 and before, we must still > > > also send the original UnknownExceptionInfo service context containing > > > something that looks like the J2SE 1.3 java.lang.Throwable class. > > > Thus, we must define the format of this new structure and how to > > > translate from J2SE 1.4 or later Throwables to it. > > > > > > - Everett > > > > -- > > Simon C Nash, Chief Technical Officer, IBM Java Technology > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff.mischkinsky@oracle.com +1 650-506-1975 Date: Wed, 19 Dec 2001 11:24:08 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Everett Anderson CC: Andy Piper , java-rtf@omg.org, java2idl-rtf@omg.org, orb_revision@omg.org Subject: Re: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3and 1.4 References: <3C1FC029.9CF89069@sun.com> <3C1FC719.8AE65B72@hursley.ibm.com> <4.3.2.7.2.20011218154149.00a9ccf8@san-francisco.beasys.com> <3C1FD6AB.AC9BBF6A@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: b]_d9$)8!!Vi2e9L?Xd9 Everett and Andy, Everett Anderson wrote: > > Hi, > > > The issue for me is what happens if there is an error while you are trying > > to access the codebase? This could easily happen - and given that an error > > has already occured (a system-level error not a user error) what hope do > > you have that you will even be able to contact the target to figure out > > what the exception looks like? This IMO will result in extreme unusability > > That's a good point. I think this kind of thing would probably result > in mapping the CORBA system exception (probably COMM_FAILURE or > MARSHAL) to a type of RemoteException as in section 1.4.8. Before > J2SE 1.4 which has the ability to nest the root cause exception, it is > quite difficult to figure out what really went wrong. > > > I don't disagree that allowing evolution in this instance is a good thing, > > I do disagree that it should be the only thing. > > > > >Still, even if we define a new portable Throwable, we would need to do > > >the same thing as my proposal with the double marshaling for backwards > > >compatibility unless we made it look exactly like the wire form of > > >J2SE 1.3's Throwable. > > > > That seems reasonable to me :) > > In that case, it sounds a lot like my second proposal. For instance, > we could continue to marshal the UnknownExceptionInfo service context > using what looks like the J2SE 1.3 Throwable format. Then, we could > add a new service context which newer systems could choose to use that > has the CodeBase and newer exception form. This sounds good to me. > Unfortunately, this doesn't work. The server exception marshalled in the service contact is not a java.lang.Throwable. It is a subclass of java.lang.Throwable that may contain data specific to that subclass. So a portable format for all possible subclasses would have to be defined. This sounds a lot like reinventing Java serialization. I'd like to propose another approach that removes the need to access the target's codebase. This callback approach to get the codebase is not only problematic in error cases, but also has difficulty traversing firewalls. The metadata needed to support evolution (in this and possibly other cases) could be provided in the form of a full TypeCode for the exception valuetype. This is equivalent to marshalling the exception valuetype as an "any", i.e., as it would be marshalled on a remote method call with a declared parameter type of java.lang.Object. With this approach, we would add a new service context that contains the Throwable subclass object marshalled in the form of an any. The current UnknownExceptionInfo service context would be deprecated but still recognized for backwards compatibility. New ORBs would send the new context, and also the old one in case they were talking to a down-level ORB. They would look for the new context in preference to the old context and use the TypeCode in the new context to perform the class evolution if necessary. If the new context were not present, they could attempt evolution using the codebase object if it is available and usable, or else fall back to throwing a suitable subclass of RemoteException such as UnexpectedException or MarshalException. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb X-Sender: andrew@192.67.184.65 Message-Id: In-Reply-To: <3C1FC029.9CF89069@sun.com> Mime-Version: 1.0 Date: Wed, 19 Dec 2001 14:14:18 +0000 To: Everett Anderson From: Andrew Watson Subject: Re: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3 and 1.4 Cc: java2idl-rtf@omg.org Content-Type: text/plain; charset="us-ascii" X-UIDL: Kn/!!4Td!!!>A!!COfd9 Everett, You wrote: > I'd like to raise the following as an urgent issue for the Java to IDL > RTF: > > RuntimeExceptions/Errors are broken in RMI-IIOP when interoperating > between J2SE 1.3 and 1.4 (or "class evolution in service contexts is > broken"). In order to label this issue as "Urgent", I need to be sure that there is a pressing reason to have the resolution set in stone within the next two weeks, and that this can't wait for the RTF report, due on 4th February. Can you give me some background on the product impact of the issue? Thanks, Andrew Date: Wed, 19 Dec 2001 10:46:09 -0500 (EST) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3and 1.4 To: nash@hursley.ibm.com Cc: java-rtf@omg.org, java2idl-rtf@omg.org, orb_revision@omg.org MIME-Version: 1.0 Content-MD5: TSrZK1Mf15iwXGflhUhuOg== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: Dg/e9dkD!!LRNe9EmG!! > I'd like to propose another approach that removes the need to access the > target's codebase. This callback approach to get the codebase is not only > problematic in error cases, but also has difficulty traversing firewalls. > The metadata needed to support evolution (in this and possibly other cases) > could be provided in the form of a full TypeCode for the exception valuetype. > This is equivalent to marshalling the exception valuetype as an "any", > i.e., as it would be marshalled on a remote method call with a declared > parameter type of java.lang.Object. I can only smile; I argued for in-band type information (consistent with normal Java serialization) from the outset of the OBV effort, but it fell on deaf ears. The ability to send in-band information shouldn't be restricted to the UnknownExceptionInfo exception, it should apply to all marshalled value type instances. - Bob From: " Steve Vinoski" To: "Bob Scheifler - SMI Software Development" , Cc: , , Subject: RE: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3and 1.4 Date: Wed, 19 Dec 2001 12:19:42 -0500 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200112191542.KAA26651@eastmail1.East.Sun.COM> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Type: text/plain; charset="us-ascii" X-UIDL: A<$!!IBXd9aSp!!i,Q!! Ditto for me, Bob, I couldn't agree with you more. I argued vehemently for the same. Unlike you, though, I'm not smiling, given that we had to sacrifice having decent and useable OBV because certain people couldn't see the light, apparently until now. --steve -----Original Message----- From: Bob Scheifler - SMI Software Development [mailto:rws@east.sun.com] Sent: Wednesday, December 19, 2001 10:46 AM To: nash@hursley.ibm.com Cc: java-rtf@omg.org; java2idl-rtf@omg.org; orb_revision@omg.org Subject: Re: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3and 1.4 > I'd like to propose another approach that removes the need to access the > target's codebase. This callback approach to get the codebase is not only > problematic in error cases, but also has difficulty traversing firewalls. > The metadata needed to support evolution (in this and possibly other cases) > could be provided in the form of a full TypeCode for the exception valuetype. > This is equivalent to marshalling the exception valuetype as an "any", > i.e., as it would be marshalled on a remote method call with a declared > parameter type of java.lang.Object. I can only smile; I argued for in-band type information (consistent with normal Java serialization) from the outset of the OBV effort, but it fell on deaf ears. The ability to send in-band information shouldn't be restricted to the UnknownExceptionInfo exception, it should apply to all marshalled value type instances. - Bob Date: Wed, 19 Dec 2001 13:36:46 -0800 From: Everett Anderson X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf,ja MIME-Version: 1.0 To: Simon Nash CC: Andy Piper , java-rtf@omg.org, java2idl-rtf@omg.org, orb_revision@omg.org Subject: Re: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3and 1.4 References: <3C1FC029.9CF89069@sun.com> <3C1FC719.8AE65B72@hursley.ibm.com> <4.3.2.7.2.20011218154149.00a9ccf8@san-francisco.beasys.com> <3C1FD6AB.AC9BBF6A@sun.com> <3C2078D8.47A8E0FF@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: RI[!!lF#!!_en!!)X,!! Hi Simon, > Unfortunately, this doesn't work. The server exception marshalled in the > service contact is not a java.lang.Throwable. It is a subclass of > java.lang.Throwable that may contain data specific to that subclass. Ah, yes, you're right. > I'd like to propose another approach that removes the need to access the > target's codebase. This callback approach to get the codebase is not only > problematic in error cases, but also has difficulty traversing firewalls. > The metadata needed to support evolution (in this and possibly other cases) > could be provided in the form of a full TypeCode for the exception valuetype. > This is equivalent to marshalling the exception valuetype as an "any", > i.e., as it would be marshalled on a remote method call with a declared > parameter type of java.lang.Object. I'm not too hot on that since the CodeBase callback is still required for any exception marshaling not in the UnknownExceptionInfo service context, unless we do some major changes to RMI-IIOP to always send the full type info (as has been suggested previously). I do agree that it seems like the only idea so far that works for future systems to evolve their unchecked exceptions or RemoteExceptions, though. > With this approach, we would add a new service context that contains the > Throwable subclass object marshalled in the form of an any. The current > UnknownExceptionInfo service context would be deprecated but still > recognized for backwards compatibility. New ORBs would send the new > context, and also the old one in case they were talking to a down-level > ORB. They would look for the new context in preference to the old > context and use the TypeCode in the new context to perform the class > evolution if necessary. If the new context were not present, they could > attempt evolution using the codebase object if it is available and usable, > or else fall back to throwing a suitable subclass of RemoteException such > as UnexpectedException or MarshalException. The problem here is that this still means pre-J2SE 1.4 RMI-IIOP code that was working fine, receiving the proper unchecked exceptions, will start to get CORBA UNKNOWNs or some other strange behavior when talking to J2SE 1.4 or later systems. Can anyone think of a way to maintain the backwards compatibility here? - Everett Date: Wed, 19 Dec 2001 13:36:46 -0800 From: Everett Anderson X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf,ja MIME-Version: 1.0 To: Simon Nash CC: Andy Piper , java-rtf@omg.org, java2idl-rtf@omg.org, orb_revision@omg.org Subject: Re: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3and 1.4 References: <3C1FC029.9CF89069@sun.com> <3C1FC719.8AE65B72@hursley.ibm.com> <4.3.2.7.2.20011218154149.00a9ccf8@san-francisco.beasys.com> <3C1FD6AB.AC9BBF6A@sun.com> <3C2078D8.47A8E0FF@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: RI[!!lF#!!_en!!)X,!! Hi Simon, > Unfortunately, this doesn't work. The server exception marshalled in the > service contact is not a java.lang.Throwable. It is a subclass of > java.lang.Throwable that may contain data specific to that subclass. Ah, yes, you're right. > I'd like to propose another approach that removes the need to access the > target's codebase. This callback approach to get the codebase is not only > problematic in error cases, but also has difficulty traversing firewalls. > The metadata needed to support evolution (in this and possibly other cases) > could be provided in the form of a full TypeCode for the exception valuetype. > This is equivalent to marshalling the exception valuetype as an "any", > i.e., as it would be marshalled on a remote method call with a declared > parameter type of java.lang.Object. I'm not too hot on that since the CodeBase callback is still required for any exception marshaling not in the UnknownExceptionInfo service context, unless we do some major changes to RMI-IIOP to always send the full type info (as has been suggested previously). I do agree that it seems like the only idea so far that works for future systems to evolve their unchecked exceptions or RemoteExceptions, though. > With this approach, we would add a new service context that contains the > Throwable subclass object marshalled in the form of an any. The current > UnknownExceptionInfo service context would be deprecated but still > recognized for backwards compatibility. New ORBs would send the new > context, and also the old one in case they were talking to a down-level > ORB. They would look for the new context in preference to the old > context and use the TypeCode in the new context to perform the class > evolution if necessary. If the new context were not present, they could > attempt evolution using the codebase object if it is available and usable, > or else fall back to throwing a suitable subclass of RemoteException such > as UnexpectedException or MarshalException. The problem here is that this still means pre-J2SE 1.4 RMI-IIOP code that was working fine, receiving the proper unchecked exceptions, will start to get CORBA UNKNOWNs or some other strange behavior when talking to J2SE 1.4 or later systems. Can anyone think of a way to maintain the backwards compatibility here? - Everett X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Dec 2001 14:01:47 -0800 To: Everett Anderson , Simon Nash From: Andy Piper Subject: Re: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3and 1.4 Cc: java-rtf@omg.org, java2idl-rtf@omg.org, orb_revision@omg.org In-Reply-To: <3C21086E.ECB2B03D@sun.com> References: <3C1FC029.9CF89069@sun.com> <3C1FC719.8AE65B72@hursley.ibm.com> <4.3.2.7.2.20011218154149.00a9ccf8@san-francisco.beasys.com> <3C1FD6AB.AC9BBF6A@sun.com> <3C2078D8.47A8E0FF@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: &-S!!nWBe9J]I!!W"Sd9 At 01:36 PM 12/19/2001 -0800, Everett Anderson wrote: The problem here is that this still means pre-J2SE 1.4 RMI-IIOP code that was working fine, receiving the proper unchecked exceptions, will start to get CORBA UNKNOWNs or some other strange behavior when talking to J2SE 1.4 or later systems. Can anyone think of a way to maintain the backwards compatibility here? Its a pity we can't mandate that exceptions are chunked. If they were we could easily skip data we didn't understand without invoking the codebase. andy Date: Wed, 19 Dec 2001 22:58:04 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Andy Piper CC: Everett Anderson , java-rtf@omg.org, java2idl-rtf@omg.org, orb_revision@omg.org Subject: Re: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE1.3and 1.4 References: <3C1FC029.9CF89069@sun.com> <3C1FC719.8AE65B72@hursley.ibm.com> <4.3.2.7.2.20011218154149.00a9ccf8@san-francisco.beasys.com> <3C1FD6AB.AC9BBF6A@sun.com> <3C2078D8.47A8E0FF@hursley.ibm.com> <4.3.2.7.2.20011219140058.00b5c308@san-francisco.beasys.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: %OJ!!FOP!!alEe9=de!! Andy, Andy Piper wrote: > > At 01:36 PM 12/19/2001 -0800, Everett Anderson wrote: > > >The problem here is that this still means pre-J2SE 1.4 RMI-IIOP code > >that was working fine, receiving the proper unchecked exceptions, will > >start to get CORBA UNKNOWNs or some other strange behavior when > >talking to J2SE 1.4 or later systems. Can anyone think of a way to > >maintain the backwards compatibility here? > > Its a pity we can't mandate that exceptions are chunked. If they were we > could easily skip data we didn't understand without invoking the codebase. > Skipping to the end of the current chunk doesn't work when the extra data contains chunks of its own, which is possible when dealing with arbitrary RuntimeException subclasses. This is the problem described in issue 3151. If the 3151 problem were solved (this is a shameless plug for feedback on my proposed resolution, sent out on October 14), then we might be able to do what you suggest. It would be necessary for 1.4 to add a writeObject method to Throwable, which would call defaultWriteObject to write all the 1.3 fields. The 1.4 writeObject would then write the extra 1.4 data. 1.4 would also have to force the hashcode to the same value as 1.3 uses, to prevent 1.3 trying to do class evolution. Forcing a different hashcode value is not part of the standard API today, so this capability would need to be added. Then 1.3 would be able to get the data it needs from the defaultWriteObject data written by 1.4, and would automatically discard the extra data written by 1.4's writeObject method using the mechanism proposed in issue 3151's reolution. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Dec 2001 15:02:48 -0800 To: Simon Nash From: Andy Piper Subject: Re: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE1.3and 1.4 Cc: Everett Anderson , java-rtf@omg.org, java2idl-rtf@omg.org, orb_revision@omg.org In-Reply-To: <3C211B7B.EF0CF608@hursley.ibm.com> References: <3C1FC029.9CF89069@sun.com> <3C1FC719.8AE65B72@hursley.ibm.com> <4.3.2.7.2.20011218154149.00a9ccf8@san-francisco.beasys.com> <3C1FD6AB.AC9BBF6A@sun.com> <3C2078D8.47A8E0FF@hursley.ibm.com> <4.3.2.7.2.20011219140058.00b5c308@san-francisco.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: *_7e9S#ed927Wd9%-Qe9 At 10:58 PM 12/19/2001 +0000, Simon Nash wrote: If the 3151 problem were solved (this is a shameless plug for feedback on my proposed resolution, sent out on October 14), then we might be able to I must have missed this. Is it possible for you to resend it? Thanks andy Date: Wed, 19 Dec 2001 23:09:39 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Everett Anderson CC: Andy Piper , java-rtf@omg.org, java2idl-rtf@omg.org, orb_revision@omg.org Subject: Re: Urgent Java to IDL issue: RMI-IIOP interop bet. J2SE 1.3and 1.4 References: <3C1FC029.9CF89069@sun.com> <3C1FC719.8AE65B72@hursley.ibm.com> <4.3.2.7.2.20011218154149.00a9ccf8@san-francisco.beasys.com> <3C1FD6AB.AC9BBF6A@sun.com> <3C2078D8.47A8E0FF@hursley.ibm.com> <3C21086E.ECB2B03D@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: TJpd9In-e9`!:!!Qj?e9 Everett, Everett Anderson wrote: > > Hi Simon, > > > Unfortunately, this doesn't work. The server exception marshalled in the > > service contact is not a java.lang.Throwable. It is a subclass of > > java.lang.Throwable that may contain data specific to that subclass. > > Ah, yes, you're right. > > > I'd like to propose another approach that removes the need to access the > > target's codebase. This callback approach to get the codebase is not only > > problematic in error cases, but also has difficulty traversing firewalls. > > The metadata needed to support evolution (in this and possibly other cases) > > could be provided in the form of a full TypeCode for the exception valuetype. > > This is equivalent to marshalling the exception valuetype as an "any", > > i.e., as it would be marshalled on a remote method call with a declared > > parameter type of java.lang.Object. > > I'm not too hot on that since the CodeBase callback is still required > for any exception marshaling not in the UnknownExceptionInfo service > context, unless we do some major changes to RMI-IIOP to always send > the full type info (as has been suggested previously). > True, but these exceptions will be unmarshalled after the SendingContextRunTime service context has been processed, so the problem we are trying to solve doesn't apply in this case. We only need to do something for exceptions marshalled in the UnknownExceptionInfo service context. > I do agree that it seems like the only idea so far that works for > future systems to evolve their unchecked exceptions or > RemoteExceptions, though. > > > With this approach, we would add a new service context that > contains the > > Throwable subclass object marshalled in the form of an any. The > current > > UnknownExceptionInfo service context would be deprecated but still > > recognized for backwards compatibility. New ORBs would send the > new > > context, and also the old one in case they were talking to a > down-level > > ORB. They would look for the new context in preference to the old > > context and use the TypeCode in the new context to perform the > class > > evolution if necessary. If the new context were not present, they > could > > attempt evolution using the codebase object if it is available and > usable, > > or else fall back to throwing a suitable subclass of > RemoteException such > > as UnexpectedException or MarshalException. > > The problem here is that this still means pre-J2SE 1.4 RMI-IIOP code > that was working fine, receiving the proper unchecked exceptions, > will > start to get CORBA UNKNOWNs or some other strange behavior when > talking to J2SE 1.4 or later systems. Can anyone think of a way to > maintain the backwards compatibility here? > These existing products would require a service update in order to > talk to 1.4 correctly. The service update would process the new service > context and perform type evolution based on the TypeCode. This is not ideal, > but it is workable, and our customers have accepted this approach in the > past. If we are going to require such a service update to existing systems then we could say that 1.4 systems only send the new service context, which eliminates the need for duplicate marshalling. This isn't unreasonable, since 1.3 systems won't be able to process an UnknownExceptionInfo containing a 1.4 exception unless they have the necessary logic to process the SendingContextRunTime service context before the UnknownExceptionInfo service context. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 31 Dec 2001 23:06:40 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji , Vijay Natarajan , Harold Carr , Jeff Mischkinsky , Yoshitaka Honishi , Andy Piper , Xudong Chen , java2idl-rtf@omg.org Subject: Issue 4795 resolution options Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: OSJe9EPI!!T@Qd9jVRd9 Status: RO To summarize the discussion on issue 4795, there are three options for resolving it: 1. Specify an order of service context processing that ensures the SendingContextRunTime service context will always be processed before the UnknownExceptionInfo service context. The concern with this is that a callback to the SendingContext::CodeBase object is required to process the versioned exception and in some error cases this callback may not work. 2. Introduce a new service context that contains the marshaled throwable object together with the IOR for the SendingContext::CodeBase object. The concern with this is the same as for option 1. 3. Introduce a new service context that contains the marshaled throwable object in the form of an "any" with full typecode information which can be used to do versioned unmarshaling. This doesn't need a callback but does require ORBs to support versioned unmarshaling of Java throwables based on TypeCode information. Before I write up a formal proposal, I'd like to informally poll RTF members to see if there is a consensus in favor of one of these options. IBM's preference is for option 3. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Wed, 2 Jan 2002 11:16:34 -0500 (EST) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: Issue 4795 resolution options To: nash@hursley.ibm.com Cc: jishnu_mukerji@hp.com, vnatarajan@borland.com, harold.carr@Sun.COM, jeff.mischkinsky@oracle.com, honi@fsc.fujitsu.com, andyp@bea.com, xdchen@borland.com, java2idl-rtf@omg.org MIME-Version: 1.0 Content-MD5: o7y6oZojGy3Ng6ctt2E6sA== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: RN_!!R\~!!cL>!!ca,e9 > To summarize the discussion on issue 4795, there are three options for > resolving it: Why isn't adding full in-band type information for value types, and then requiring its use in this situation, an option? - Bob Date: Thu, 03 Jan 2002 20:02:10 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Bob Scheifler - SMI Software Development CC: jishnu_mukerji@hp.com, vnatarajan@borland.com, harold.carr@Sun.COM, jeff.mischkinsky@oracle.com, honi@fsc.fujitsu.com, andyp@bea.com, xdchen@borland.com, java2idl-rtf@omg.org Subject: Re: Issue 4795 resolution options References: <200201021612.LAA14258@eastmail1.East.Sun.COM> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: l($!!NF:!!oMWd9AgNd9 Bob, The reason I didn't include this option is that I was trying to focus on solving the specific problem raised in issue 4795 regarding RMI-IIOP non-interoperability for exceptions between J2SE 1.3 and 1.4. I'd like to get a solution for this serious problem agreed in the current RTF, which closes on February 4. Adding full in-band type information to valuetypes is a valid technical approach but would need to be part of GIOP 1.3 since it's a signifcant redesign of the valuetype CDR encoding. Given that neither J2SE 1.3 or 1.4 are ever likely to support GIOP 1.3, a solution that pre-reqs GIOP 1.3 would not solve the specific problem of J2SE 1.3/1.4 interoperability. Simon Bob Scheifler - SMI Software Development wrote: > > > To summarize the discussion on issue 4795, there are three options for > > resolving it: > > Why isn't adding full in-band type information for value types, and > then requiring its use in this situation, an option? > > - Bob -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Thu, 3 Jan 2002 15:24:48 -0500 (EST) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: Issue 4795 resolution options To: nash@hursley.ibm.com Cc: jishnu_mukerji@hp.com, vnatarajan@borland.com, harold.carr@Sun.COM, jeff.mischkinsky@oracle.com, honi@fsc.fujitsu.com, andyp@bea.com, xdchen@borland.com, java2idl-rtf@omg.org MIME-Version: 1.0 Content-MD5: 39c3Hk6D59N7yX1aC9UREQ== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: /\R!!%&b!!\'Pe9&,F!! > The reason I didn't include this option is that I was trying to focus on > solving the specific problem raised in issue 4795 regarding RMI-IIOP > non-interoperability for exceptions between J2SE 1.3 and 1.4. > Given that neither J2SE 1.3 or 1.4 are ever likely to support > GIOP 1.3 Can you clarify: do you mean "Sun's implementations of J2SE 1.3 and 1.4", or something else? And how do any of the proposed options provide interoperability with existing J2SE 1.3 implementations that are already in the field? - Bob Date: Thu, 03 Jan 2002 23:11:22 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Bob Scheifler - SMI Software Development CC: jishnu_mukerji@hp.com, vnatarajan@borland.com, harold.carr@Sun.COM, jeff.mischkinsky@oracle.com, honi@fsc.fujitsu.com, andyp@bea.com, xdchen@borland.com, java2idl-rtf@omg.org Subject: Re: Issue 4795 resolution options References: <200201032020.PAA05854@eastmail2.East.Sun.COM> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: W'V!!EE_d9lF1!!eb5!! Status: RO Bob, Yes, that is what I meant. Bob Scheifler - SMI Software Development wrote: > > > The reason I didn't include this option is that I was trying to focus on > > solving the specific problem raised in issue 4795 regarding RMI-IIOP > > non-interoperability for exceptions between J2SE 1.3 and 1.4. > > > Given that neither J2SE 1.3 or 1.4 are ever likely to support > > GIOP 1.3 > > Can you clarify: do you mean "Sun's implementations of J2SE 1.3 and 1.4", > or something else? > I was thinking of Sun's implementation when I wrote this, but I also think it's unlikely that other J2SE licensees would add this support unless Sun does so. > And how do any of the proposed options provide interoperability with > existing J2SE 1.3 implementations that are already in the field? > They would all require some service update to existing J2SE 1.3 > implementations in the field. I don't find it too much of a stretch to imagine a > service update adding support for a new service context to fix interoperability > problems, but I would be very surprised to see a J2SE 1.3 service update add support > for a new GIOP version. I'd also be surprised if we could get agreement on a > new valuetype format before the current RTF cycle ends on February 4. But all the above is my own opinion. If any RTF members think that the best way to fix the problem described by issue 4795 is to change the CDR valuetype format to add full type information, please respond accordingly. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Jan 2002 11:10:37 -0800 To: Simon Nash , Jishnu Mukerji , Vijay Natarajan , Harold Carr , Jeff Mischkinsky , Yoshitaka Honishi , Xudong Chen , java2idl-rtf@omg.org From: Andy Piper Subject: Re: Issue 4795 resolution options In-Reply-To: <3C30EF80.480476C0@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: iORd9$OQ!!Xg+!!~=+!! At 11:06 PM 12/31/2001 +0000, Simon Nash wrote: Before I write up a formal proposal, I'd like to informally poll RTF members to see if there is a consensus in favor of one of these options. IBM's preference is for option 3. BEA 3 also, but I would like to see some coordination with 3151 wrt versioning of the streams. It seems to me we are in danger of throwing in the kitchen sink to solve edge cases. I would prefer to tie all of these version decisions to a new version of GIOP, and if we do that it seems that we should also allow full TypeCode information for all valuetypes .... andy Date: Thu, 10 Jan 2002 13:21:18 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Andy Piper CC: Jishnu Mukerji , Vijay Natarajan , Harold Carr , Yoshitaka Honishi , Xudong Chen , java2idl-rtf@omg.org Subject: Re: Issue 4795 resolution options References: <4.3.2.7.2.20020109110723.0390c460@san-francisco.beasys.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: V@Ae9\XVd9>1md9 Andy, Thanks for this response. 4795 is different from 3151 regarding versioning of the streams. With 3151, the sender needs to know the capability of the receiver to avoid sending it a format that it can't handle. If it detects a down-level receiver, it can send a down-level form of the data that the down-level receiver is able to handle. With 4795, even if a J2SE 1.4 sender knows it is talking to a legacy J2SE 1.3 receiver, it cannot marshal J2SE 1.4 exceptions in a form that the legacy J2SE 1.3 ORB can unmarshal. So knowing the receiver's capability (whether by stream versioning or GIOP level) doesn't help here. The only way to make J2SE 1.4 and J2SE 1.3 interoperate is for J2SE 1.4 to send the new format (whichever one we decide to adopt) and for legacy J2SE 1.3 ORBs to apply a service update to allow them to accept the new format. If we go to a new GIOP level with full inline valuetype information to solve this, as you suggest, the need for a service update to existing products still applies. However, this would allow the current service context definition for UnknownExceptionInfo to remain unchanged instead of introducing a new flavor of this that holds an any. So let me sketch out an option 4 to add to the list: a. In GIOP 1.3, change the valuetype CDR representation to allow an optional TypeCode to be included. b. Require that exception valuetypes in UnknownExceptionInfo service contexts be encoded with TypeCode information when using GIOP 1.3. Would you prefer this to the current option 3? Simon Andy Piper wrote: > > At 11:06 PM 12/31/2001 +0000, Simon Nash wrote: > >Before I write up a formal proposal, I'd like to informally poll RTF members > >to see if there is a consensus in favor of one of these options. > > > >IBM's preference is for option 3. > > BEA 3 also, but I would like to see some coordination with 3151 wrt > versioning of the streams. It seems to me we are in danger of throwing in > the kitchen sink to solve edge cases. I would prefer to tie all of these > version decisions to a new version of GIOP, and if we do that it seems that > we should also allow full TypeCode information for all valuetypes .... > > andy -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 10 Jan 2002 12:34:08 -0800 To: Simon Nash From: Andy Piper Subject: Re: Issue 4795 resolution options Cc: Jishnu Mukerji , Vijay Natarajan , Harold Carr , Yoshitaka Honishi , Xudong Chen , java2idl-rtf@omg.org In-Reply-To: <3C3D954E.21339280@hursley.ibm.com> References: <4.3.2.7.2.20020109110723.0390c460@san-francisco.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: d~Yd9:mX!!RHZd9oYVd9 At 01:21 PM 1/10/2002 +0000, Simon Nash wrote: Thanks for this response. 4795 is different from 3151 regarding versioning of the streams. With 3151, the sender needs to know the capability of the receiver to avoid sending it a format that it can't handle. If it detects a down-level receiver, it can send a down-level form of the data that the down-level receiver is able to handle. With 4795, even if a J2SE 1.4 sender knows it is talking to a legacy J2SE 1.3 receiver, it cannot marshal J2SE 1.4 exceptions in a form that the legacy J2SE 1.3 ORB can unmarshal. So knowing the receiver's capability (whether by stream versioning or GIOP level) doesn't help here. The only way to make J2SE 1.4 and J2SE 1.3 interoperate is for J2SE 1.4 to send the new format (whichever one we decide to adopt) and for legacy J2SE 1.3 ORBs to apply a service update to allow them to accept the new format. If we go to a new GIOP level with full inline valuetype information to solve this, as you suggest, the need for a service update to existing products still applies. However, this would allow the current service context definition for UnknownExceptionInfo to remain unchanged instead of introducing a new flavor of this that holds an any. So let me sketch out an option 4 to add to the list: a. In GIOP 1.3, change the valuetype CDR representation to allow an optional TypeCode to be included. b. Require that exception valuetypes in UnknownExceptionInfo service contexts be encoded with TypeCode information when using GIOP 1.3. Would you prefer this to the current option 3? I guess. Yes. It still grieves me that we are contemplating such complexity for unknown exceptions. Relying on a service update seems problematic to me. I would almost prefer that if the sender knows the receiver is going to choke that it marshals an UNKNOWN with UnknownExceptionInfo containing a null valuetype. At least then the sender could marshal something that it knows will be understood. andy Date: Thu, 10 Jan 2002 21:52:23 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Andy Piper CC: Jishnu Mukerji , Vijay Natarajan , Harold Carr , Yoshitaka Honishi , Xudong Chen , java2idl-rtf@omg.org, interop@omg.org, michi.henning@iona.com, everett.anderson@Sun.COM Subject: Re: Issue 4795 resolution options References: <4.3.2.7.2.20020109110723.0390c460@san-francisco.beasys.com> <4.3.2.7.2.20020110121949.00b28178@san-francisco.beasys.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ?b*!!fo9!!NbRd90ajd9 Andy, Andy Piper wrote: > > At 01:21 PM 1/10/2002 +0000, Simon Nash wrote: > >Thanks for this response. 4795 is different from 3151 regarding versioning > >of the streams. With 3151, the sender needs to know the capability of the > >receiver to avoid sending it a format that it can't handle. If it detects > >a down-level receiver, it can send a down-level form of the data that the > >down-level receiver is able to handle. > > > >With 4795, even if a J2SE 1.4 sender knows it is talking to a legacy J2SE 1.3 > >receiver, it cannot marshal J2SE 1.4 exceptions in a form that the legacy > >J2SE 1.3 ORB can unmarshal. So knowing the receiver's capability (whether by > >stream versioning or GIOP level) doesn't help here. The only way to make > >J2SE 1.4 and J2SE 1.3 interoperate is for J2SE 1.4 to send the new format > >(whichever one we decide to adopt) and for legacy J2SE 1.3 ORBs to apply a > >service update to allow them to accept the new format. > > > >If we go to a new GIOP level with full inline valuetype information to solve > >this, as you suggest, the need for a service update to existing products > >still applies. However, this would allow the current service context > >definition for UnknownExceptionInfo to remain unchanged instead of introducing > >a new flavor of this that holds an any. > > > >So let me sketch out an option 4 to add to the list: > > a. In GIOP 1.3, change the valuetype CDR representation to allow an optional > > TypeCode to be included. > > b. Require that exception valuetypes in UnknownExceptionInfo service > > contexts > > be encoded with TypeCode information when using GIOP 1.3. > > > >Would you prefer this to the current option 3? > > I guess. Yes. > OK, I'll write up a proposal for this. It would have been nice to get more feedback, but we need some kind of straw man that we can vote on. Also, this requires a change in the interop RTF to change the CDR format for valuetypes. I think the best way to proceed is for the Java to IDL RTF to vote on an option 4 proposal subject to the interop RTF making this change, then if the Java to IDL vote passes I can ask Michi to initiate a fast-path vote in the interop RTF. I'm copying Michi and the interop list on this reply to see if there are any howls of protest about this. I'm also copying Everett, since he might have some views on this. > It still grieves me that we are contemplating such complexity for unknown > exceptions. Relying on a service update seems problematic to me. I would > almost prefer that if the sender knows the receiver is going to choke that > it marshals an UNKNOWN with UnknownExceptionInfo containing a null > valuetype. At least then the sender could marshal something that it knows > will be understood. > Even this might not work. I don't think it's possible to throw a null exception. The only way to avoid a service update for J2SE 1.3 ORBs would be a) tie the fix to GIOP 1.3 b) when 1.4 ORBs marshal UnknownExceptionInfo over GIOP 1.2, they must exactly emulate the J2SE 1.3 exception SUID/hashcode/data. a) is easy, but b) is very difficult. We could add machinery to do this, but I fear the cure is worse than the disease. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Sender: jon@floorboard.com Message-ID: <3C3E1777.8A4D4E29@floorboard.com> Date: Thu, 10 Jan 2002 14:36:39 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Andy Piper , Jishnu Mukerji , Vijay Natarajan , Harold Carr , Yoshitaka Honishi , Xudong Chen , java2idl-rtf@omg.org, interop@omg.org, michi.henning@iona.com, everett.anderson@Sun.COM Subject: Re: Issue 4795 resolution options References: <4.3.2.7.2.20020109110723.0390c460@san-francisco.beasys.com> <4.3.2.7.2.20020110121949.00b28178@san-francisco.beasys.com> <3C3E0D17.A46C90F7@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 6@Ge9bZ!!!dl"!!ji8e9 Status: RO Simon Nash wrote: > OK, I'll write up a proposal for this. It would have been nice to get more > feedback, but we need some kind of straw man that we can vote on. Also, this > requires a change in the interop RTF to change the CDR format for valuetypes. > I think the best way to proceed is for the Java to IDL RTF to vote on an > option 4 proposal subject to the interop RTF making this change, then if the > Java to IDL vote passes I can ask Michi to initiate a fast-path vote in the > interop RTF. I'm copying Michi and the interop list on this reply to see if > there are any howls of protest about this. I'm also copying Everett, since > he might have some views on this. [I'm mising a lot of context, since I'm not on the list that this conversation started on...] I worked up a change last year to CDR to allow ORBs to properly receive and remarshal unknown valuetypes without having to know the full typecode of the valuetype. The reason that I did it this way is that adding typecodes to the valuetype marshalling still doesn't address the problem of custom valuetypes, and also leaves a serious inefficiency problem with the sender transmitting typecodes that the receiver may already know. This may have some bearing on the 4795 issue as well. Here is the proposal I worked up last March that would resolve 4137: 1. Add a flag to both the value_tag and chunk_size_tag to indicate the byte order used for the encoded valuetype by stealing the top bit. This means that chunks are now limited in size to < 0x3fffff00 and value_tags take the range 0x3fffff00 to 0x3fffffff. The valuetype header itself and chunk_size_tag values will be encoded using the current byte order of the CDR stream, but all valuetype data will be encoded using the byte order of the new flag. 2. Require that a new value chunk always be started at a truncation boundary. So, if I have: // IDL valuetype A { ... }; valuetype B : truncatable A { ... }; an encoding of a B must have at least two valuechunks, first at least one for the A part and then at least one for the B part. 3. Change the bullet that read: o For the purposes of chunking, values encoded as indirections or null are treated as non-value data. to: o For the purposes of chunking, values encoded as null are treated as non-value data. This means that indirections are removed from the valuetype state stream and are promoted to the same level as all other valuetype headers. I think this solves the problems, since we can now identify the byte order of all valuetype chunks (allowing them to be remarshalled without change), we can identify the location of truncation boundaries in the stream (given only the type information of the valuetype that we are truncating to), and we can identify all valuetype indirections so that they can be remarshalled properly with new valuetype offsets. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 10 Jan 2002 14:49:43 -0800 To: Simon Nash From: Andy Piper Subject: Re: Issue 4795 resolution options Cc: Jishnu Mukerji , Vijay Natarajan , Harold Carr , Yoshitaka Honishi , Xudong Chen , java2idl-rtf@omg.org, interop@omg.org, michi.henning@iona.com, everett.anderson@Sun.COM In-Reply-To: <3C3E0D17.A46C90F7@hursley.ibm.com> References: <4.3.2.7.2.20020109110723.0390c460@san-francisco.beasys.com> <4.3.2.7.2.20020110121949.00b28178@san-francisco.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: e1e9:Dhd9 Status: RO At 09:52 PM 1/10/2002 +0000, Simon Nash wrote: a) tie the fix to GIOP 1.3 b) when 1.4 ORBs marshal UnknownExceptionInfo over GIOP 1.2, they must exactly emulate the J2SE 1.3 exception SUID/hashcode/data. a) is easy, but b) is very difficult. We could add machinery to do this, but I fear the cure is worse than the disease. Hmmn, ok I prefer (a). I'm also, I suppose, trying to prejudge what interop requirements will be made by J2EE 1.4 say. andy Date: Thu, 10 Jan 2002 15:55:54 -0800 From: Everett Anderson X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf,ja MIME-Version: 1.0 To: Simon Nash CC: Andy Piper , Jishnu Mukerji , Vijay Natarajan , Harold Carr , Yoshitaka Honishi , Xudong Chen , java2idl-rtf@omg.org, interop@omg.org, michi.henning@iona.com Subject: Re: Issue 4795 resolution options References: <4.3.2.7.2.20020109110723.0390c460@san-francisco.beasys.com> <4.3.2.7.2.20020110121949.00b28178@san-francisco.beasys.com> <3C3E0D17.A46C90F7@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 9O@!!eX > Andy, > > Andy Piper wrote: > > > > At 01:21 PM 1/10/2002 +0000, Simon Nash wrote: > > >Thanks for this response. 4795 is different from 3151 regarding versioning > > >of the streams. With 3151, the sender needs to know the capability of the > > >receiver to avoid sending it a format that it can't handle. If it detects > > >a down-level receiver, it can send a down-level form of the data that the > > >down-level receiver is able to handle. > > > > > >With 4795, even if a J2SE 1.4 sender knows it is talking to a legacy J2SE 1.3 > > >receiver, it cannot marshal J2SE 1.4 exceptions in a form that the legacy > > >J2SE 1.3 ORB can unmarshal. So knowing the receiver's capability (whether by > > >stream versioning or GIOP level) doesn't help here. The only way to make > > >J2SE 1.4 and J2SE 1.3 interoperate is for J2SE 1.4 to send the new format > > >(whichever one we decide to adopt) and for legacy J2SE 1.3 ORBs to apply a > > >service update to allow them to accept the new format. > > > > > >If we go to a new GIOP level with full inline valuetype information to solve > > >this, as you suggest, the need for a service update to existing products > > >still applies. However, this would allow the current service context > > >definition for UnknownExceptionInfo to remain unchanged instead of introducing > > >a new flavor of this that holds an any. > > > > > >So let me sketch out an option 4 to add to the list: > > > a. In GIOP 1.3, change the valuetype CDR representation to allow an optional > > > TypeCode to be included. > > > b. Require that exception valuetypes in UnknownExceptionInfo service > > > contexts > > > be encoded with TypeCode information when using GIOP 1.3. > > > > > >Would you prefer this to the current option 3? > > > > I guess. Yes. > > > OK, I'll write up a proposal for this. It would have been nice to get more > feedback, but we need some kind of straw man that we can vote on. Also, this > requires a change in the interop RTF to change the CDR format for valuetypes. > I think the best way to proceed is for the Java to IDL RTF to vote on an > option 4 proposal subject to the interop RTF making this change, then if the > Java to IDL vote passes I can ask Michi to initiate a fast-path vote in the > interop RTF. I'm copying Michi and the interop list on this reply to see if > there are any howls of protest about this. I'm also copying Everett, since > he might have some views on this. > > > It still grieves me that we are contemplating such complexity for unknown > > exceptions. Relying on a service update seems problematic to me. I would > > almost prefer that if the sender knows the receiver is going to choke that > > it marshals an UNKNOWN with UnknownExceptionInfo containing a null > > valuetype. At least then the sender could marshal something that it knows > > will be understood. > > > Even this might not work. I don't think it's possible to throw a null > exception. The only way to avoid a service update for J2SE 1.3 ORBs would be > a) tie the fix to GIOP 1.3 > b) when 1.4 ORBs marshal UnknownExceptionInfo over GIOP 1.2, they must > exactly emulate the J2SE 1.3 exception SUID/hashcode/data. > > a) is easy, but b) is very difficult. We could add machinery to do this, but > I fear the cure is worse than the disease. > > Simon > -- > Simon C Nash, Chief Technical Officer, IBM Java Technology > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Fri, 11 Jan 2002 09:02:59 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Andy Piper CC: Jishnu Mukerji , Vijay Natarajan , Harold Carr , Yoshitaka Honishi , Xudong Chen , java2idl-rtf@omg.org, interop@omg.org, michi.henning@iona.com, everett.anderson@Sun.COM Subject: Re: Issue 4795 resolution options References: <4.3.2.7.2.20020109110723.0390c460@san-francisco.beasys.com> <4.3.2.7.2.20020110121949.00b28178@san-francisco.beasys.com> <4.3.2.7.2.20020110144832.00b16320@san-francisco.beasys.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: hmm!!J]nd9PLN!!C+nd9 Andy, Sorry that I wasn't clear. a) and b) are not alternatives. Adopting a) without b) requires existing J2SE 1.3 ORBs to have service updates to interoperate with J2SE 1.4, which is what you were trying to avoid. Simon Andy Piper wrote: > > At 09:52 PM 1/10/2002 +0000, Simon Nash wrote: > > a) tie the fix to GIOP 1.3 > > b) when 1.4 ORBs marshal UnknownExceptionInfo over GIOP 1.2, they must > > exactly emulate the J2SE 1.3 exception SUID/hashcode/data. > > > >a) is easy, but b) is very difficult. We could add machinery to do this, but > >I fear the cure is worse than the disease. > > Hmmn, ok I prefer (a). I'm also, I suppose, trying to prejudge what interop > requirements will be made by J2EE 1.4 say. > > andy -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Jan 2002 00:42:38 -0800 To: Harold Carr , Simon Nash From: Andy Piper Subject: Re: Java to IDL 2001 RTF Vote 3 Cc: Jishnu Mukerji , Vijay Natarajan , Jeff Mischkinsky , Yoshitaka Honishi , Xudong Chen , java2idl-rtf@omg.org, juergen@omg.org In-Reply-To: <3C3E21D2.19F455BA@sun.com> References: <3C34DF7A.32E0A64E@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: _CMe9ZVV!!=-P!!(K>e9 I think that Jeff put it best. Its not that I am against it, its more that we are throwing in significant complexity late in the day and I am not convinced that it will achieve the overall goal. I mostly say this because I remain to be convinced that interop at this level with J2SE 1.3 will *ever* be possible, but also because we appear to be contemplating multiple, possibly overlapping versioning solutions. Given that current versioning technology (chunking and SendingContextRunTime) are both broken in J2SE 1.3 and one is broken in J2SE 1.4 I don't see the need for rushing it. Incidentally, who owns the ValueHandler (is it this group or Sun)? Many of the current proposals impact the ValueHandler and I'm coming to the conclusion that the ValueHandler is currently too tightly tied to the Orb infrastructure. For instance how do we tell the ValueHandler about versioning information? andy At 03:20 PM 1/10/2002 -0800, Harold Carr wrote: 1. Why is anyone against the versioning in the proposal? 2. Why just solve it going forward when versioning can solve it going backward as well? 3. Won't making the versioning dependent on GIOP 1.3 slow down the solution consideraby compared to including a versioning scheme in a Java-to-IDL solution? 4. This seems to be involving solutions to 4795 also, right? X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Jan 2002 00:48:45 -0800 To: Jonathan Biggar , Simon Nash From: Andy Piper Subject: Re: Issue 4795 resolution options Cc: Jishnu Mukerji , Vijay Natarajan , Harold Carr , Yoshitaka Honishi , Xudong Chen , java2idl-rtf@omg.org, interop@omg.org, michi.henning@iona.com, everett.anderson@Sun.COM In-Reply-To: <3C3E1777.8A4D4E29@floorboard.com> References: <4.3.2.7.2.20020109110723.0390c460@san-francisco.beasys.com> <4.3.2.7.2.20020110121949.00b28178@san-francisco.beasys.com> <3C3E0D17.A46C90F7@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: T\c!!&WMe9YY+e99hS!! At 02:36 PM 1/10/2002 -0800, Jonathan Biggar wrote: 1. Add a flag to both the value_tag and chunk_size_tag to indicate the byte order used for the encoded valuetype by stealing the top bit. This means that chunks are now limited in size to < 0x3fffff00 and value_tags take the range 0x3fffff00 to 0x3fffffff. The valuetype header itself and chunk_size_tag values will be encoded using the current byte order of the CDR stream, but all valuetype data will be encoded using the byte order of the new flag. Wouldn't you also have to put in a statement about alignment of the chunk? Its unfortunate that this would also mean that endtag < chunk size < value tag would no long be necessarily true as I understand it. But I guess that can't be helped. andy Date: Fri, 11 Jan 2002 11:44:20 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: Andy Piper , Jishnu Mukerji , Vijay Natarajan , Harold Carr , Yoshitaka Honishi , Xudong Chen , java2idl-rtf@omg.org, interop@omg.org, michi.henning@iona.com, everett.anderson@Sun.COM Subject: Re: Issue 4795 resolution options References: <4.3.2.7.2.20020109110723.0390c460@san-francisco.beasys.com> <4.3.2.7.2.20020110121949.00b28178@san-francisco.beasys.com> <3C3E0D17.A46C90F7@hursley.ibm.com> <3C3E1777.8A4D4E29@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ]';!!amVd9\*Ne9@^9e9 Jon, This problem and its solution are orthogonal to issue 4795, which has to do with allowing RMI-IIOP versioning to be done on the basis of embedded type information rather than using the SendingContextRunTime callback. Regarding your proposal, does the value_tag need to indicate byte order? It's not possible to remarshal an unchunked value without either having its implementation or its TypeCode, since the length of the data would be unknown. So I would think that only the chunk_size tag needs to have this flag. Simon Jonathan Biggar wrote: > > Simon Nash wrote: > > OK, I'll write up a proposal for this. It would have been nice to get more > > feedback, but we need some kind of straw man that we can vote on. Also, this > > requires a change in the interop RTF to change the CDR format for valuetypes. > > I think the best way to proceed is for the Java to IDL RTF to vote on an > > option 4 proposal subject to the interop RTF making this change, then if the > > Java to IDL vote passes I can ask Michi to initiate a fast-path vote in the > > interop RTF. I'm copying Michi and the interop list on this reply to see if > > there are any howls of protest about this. I'm also copying Everett, since > > he might have some views on this. > > [I'm mising a lot of context, since I'm not on the list that this > conversation started on...] > > I worked up a change last year to CDR to allow ORBs to properly receive > and remarshal unknown valuetypes without having to know the full > typecode of the valuetype. The reason that I did it this way is that > adding typecodes to the valuetype marshalling still doesn't address the > problem of custom valuetypes, and also leaves a serious inefficiency > problem with the sender transmitting typecodes that the receiver may > already know. > > This may have some bearing on the 4795 issue as well. > > Here is the proposal I worked up last March that would resolve 4137: > > 1. Add a flag to both the value_tag and chunk_size_tag to indicate the > byte order used for the encoded valuetype by stealing the top bit. This > means that chunks are now limited in size to < 0x3fffff00 and value_tags > take the range 0x3fffff00 to 0x3fffffff. The valuetype header itself > and chunk_size_tag values will be encoded using the current byte order > of the CDR stream, but all valuetype data will be encoded using the byte > order of the new flag. > > 2. Require that a new value chunk always be started at a truncation > boundary. So, if I have: > > // IDL > valuetype A { ... }; > valuetype B : truncatable A { ... }; > > an encoding of a B must have at least two valuechunks, first at least > one for the A part and then at least one for the B part. > > 3. Change the bullet that read: > > o For the purposes of chunking, values encoded as indirections or null > are treated as non-value data. > > to: > > o For the purposes of chunking, values encoded as null are treated as > non-value data. > > This means that indirections are removed from the valuetype state stream > and are promoted to the same level as all other valuetype headers. > > I think this solves the problems, since we can now identify the byte > order of all valuetype chunks (allowing them to be remarshalled without > change), we can identify the location of truncation boundaries in the > stream (given only the type information of the valuetype that we are > truncating to), and we can identify all valuetype indirections so that > they can be remarshalled properly with new valuetype offsets. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Fri, 11 Jan 2002 16:23:32 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Everett Anderson CC: Andy Piper , Jishnu Mukerji , Vijay Natarajan , Harold Carr , Yoshitaka Honishi , Xudong Chen , java2idl-rtf@omg.org, interop@omg.org, michi.henning@iona.com Subject: Re: Issue 4795 resolution options References: <4.3.2.7.2.20020109110723.0390c460@san-francisco.beasys.com> <4.3.2.7.2.20020110121949.00b28178@san-francisco.beasys.com> <3C3E0D17.A46C90F7@hursley.ibm.com> <3C3E2A0A.C7702EC4@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: #p&e9(8Oe9NlGe9!Fmd9 Everett, Everett Anderson wrote: > > Hi Simon, > > I don't have all the context as to what's been discussed in changing > 3151, so please accept my apology if my questions have already been > covered: > > It sounds like someone proposed adding full type information to the > CDR valuetype encoding in GIOP 1.3 rather than trying to address 3151 > by your valuetype nesting proposal. I had initially favored this, and > we had discussed it, but concluded that it would be impossible to > change GIOP 1.3 (1.4? 1.5?) to solve a RMI-IIOP-only problem and it > would take an eternity. Has that perception changed? > This does not solve the 3151 problem. It was proposed in the context of 4795, and would solve that problem. The 3151 problem is caused by an inability to identify the end of custom data, and TypeCode information doesn't say anything about custom data. > Also, while it seems neat to put in field information, how would the > current ValueHandler system access the information? It seems like > it > would need to be read before invoking the ValueHandler and passed to > it, and we'd still need to tell the ValueHandler what RMI-IIOP > version > to use. What was the problem with the versioning proposal? > The problem with the versioning proposal for 3151 was that it didn't > pass the vote. I don't think there was any technical problem, just a > concern that this was adding too much complexity and machinery to solve a > corner case. Also, it now seems more likely now that GIOP 1.3 will happen soon, > which would remove the disadvantage of tying the 3151 fix to GIOP 1.3. The proposal to add field information to solve the 4795 problem has yet to be written up. My initial thoughts were to add an optional TypeCode field after the repid(s) and before the state data, and have the ValueHandler read this from the input stream that the ORB passes to it. However, since this information is optional, the ValueHandler would need to receive some indication that it is present. It is therefore probably better to add a new interface ValueHandlerGIOP13 (or some such name) with an overloaded readValue method that takes an additional TypeCode parameter, and make the ORB stream responsible for unmarshaling the TypeCode if it is present. Its presence would be indicated by a new flag (0x00000010) in the value tag. There is also the corresponding question of how to control whether or not TypeCode information is sent as part of a marshaled valuetype. The only place where this would be required (at least for this issue resolution) is the throwable valuetype that is marshaled as part of the UnknownExceptionInfo service context. Currently, this is done by code within the ORB calling OutputStream.write_value(thowableobj). Perhaps the cleanest way to control this is to make it a property of the output stream whether or not TypeCodes are written for valuetypes marshaled to this output stream. It would be possible to add a new overloaded ORB.create_output_stream() method to create an output stream with this "inline TypeCodes" property, or it could be left to ORB implementations to have an internal way of creating such an output stream (since the creation of UnknownExceptionInfo is internal to the ORB). For symmetry with the InputStream side, it seems reasonable for the ORB stream to write the TypeCode (if required), which means there's no need to change the interface to the ValueHandler. WHat do you think about this? > With respect to issue 4795, I don't think you can tie the fix to GIOP > 1.3 alone since it wouldn't solve the problem with talking to J2SE 1.3 > or 1.4 which have/will have the old service context. You could go > back and patch them to recognize and use the type information in the > new service context, maybe, but you couldn't go back and patch them to > start using a later GIOP version -- it would just be too big of a > change, right? > I can see both sides of this. Adding a new service context without bumping the GIOP level seems simpler for back-level ORBs to implement, including the J2SE 1.3 and 1.4 ORBs. This was my starting point and my preferred option. However, other RTF members (i.e., Andy) have expressed a preference for tying the fix to GIOP 1.3. When I polled the RTF on options recently, I received no feedback from Sun's RTF member. Do you have a preference for one of options 1, 2, 3 or 4 as previously described? Of these, only option 4 requires tying the fix to GIOP 1.3. > Sounds like these need some thought before coming to a vote. If we > really think we can change the CDR encoding for valuetypes to > include > type info, doing that might be better than creating some really > complicated separate solutions for 3151 and 4795. > Again, this will not solve the 3151 problem. This requires a way to > delimit custom data in the stream on a "per class in the hierarchy" basis. I > still think the current 3151 proposal (minus the stream versioning) is the simplest way of achieving this. Unlike 4795, it's not a big problem > to tie this fix to GIOP 1.3, since it doesn't affect J2SE 1.3 to J2SE 1.4 interoperability. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Fri, 11 Jan 2002 11:51:34 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Andy Piper CC: Jonathan Biggar , Jishnu Mukerji , Vijay Natarajan , Harold Carr , Yoshitaka Honishi , Xudong Chen , java2idl-rtf@omg.org, interop@omg.org, michi.henning@iona.com, everett.anderson@Sun.COM Subject: Re: Issue 4795 resolution options References: <4.3.2.7.2.20020109110723.0390c460@san-francisco.beasys.com> <4.3.2.7.2.20020110121949.00b28178@san-francisco.beasys.com> <3C3E0D17.A46C90F7@hursley.ibm.com> <4.3.2.7.2.20020111004502.00b41908@san-francisco.beasys.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Zi/e9pl(e9%61!!2HXd9 Andy, If we could restrict the new flag to chunk size only (see my other note), then the endtag < chunk size < value tag relationship would still hold true. I think you are correct about alignment, which is unfortunate since aligning every chunk on a 8-byte boundary could add a lot of extra padding. Simon Andy Piper wrote: > > At 02:36 PM 1/10/2002 -0800, Jonathan Biggar wrote: > >1. Add a flag to both the value_tag and chunk_size_tag to indicate the > >byte order used for the encoded valuetype by stealing the top bit. This > >means that chunks are now limited in size to < 0x3fffff00 and value_tags > >take the range 0x3fffff00 to 0x3fffffff. The valuetype header itself > >and chunk_size_tag values will be encoded using the current byte order > >of the CDR stream, but all valuetype data will be encoded using the byte > >order of the new flag. > > Wouldn't you also have to put in a statement about alignment of the chunk? > > Its unfortunate that this would also mean that > > endtag < chunk size < value tag > > would no long be necessarily true as I understand it. But I guess that > can't be helped. > > andy -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Jan 2002 08:34:32 -0800 To: Simon Nash From: Andy Piper Subject: Re: Issue 4795 resolution options Cc: Jonathan Biggar , Jishnu Mukerji , Vijay Natarajan , Harold Carr , Yoshitaka Honishi , Xudong Chen , java2idl-rtf@omg.org, interop@omg.org, michi.henning@iona.com, everett.anderson@Sun.COM In-Reply-To: <3C3ED1C6.66C857A8@hursley.ibm.com> References: <4.3.2.7.2.20020109110723.0390c460@san-francisco.beasys.com> <4.3.2.7.2.20020110121949.00b28178@san-francisco.beasys.com> <3C3E0D17.A46C90F7@hursley.ibm.com> <4.3.2.7.2.20020111004502.00b41908@san-francisco.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: 'I_!!8$od9Rn9e9'aXd9 At 11:51 AM 1/11/2002 +0000, Simon Nash wrote: If we could restrict the new flag to chunk size only (see my other note), then the endtag < chunk size < value tag relationship would still hold true. Cool. I think you are correct about alignment, which is unfortunate since aligning every chunk on a 8-byte boundary could add a lot of extra padding. I was more thinking that we would enforce alignment relative to the beginning of the chunk as per encapsulations. andy Sender: jon@floorboard.com Message-ID: <3C3F4702.180722A5@floorboard.com> Date: Fri, 11 Jan 2002 12:11:46 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Andy Piper , Jishnu Mukerji , Vijay Natarajan , Harold Carr , Yoshitaka Honishi , Xudong Chen , java2idl-rtf@omg.org, interop@omg.org, michi.henning@iona.com, everett.anderson@Sun.COM Subject: Re: Issue 4795 resolution options References: <4.3.2.7.2.20020109110723.0390c460@san-francisco.beasys.com> <4.3.2.7.2.20020110121949.00b28178@san-francisco.beasys.com> <3C3E0D17.A46C90F7@hursley.ibm.com> <4.3.2.7.2.20020111004502.00b41908@san-francisco.beasys.com> <3C3ED1C6.66C857A8@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: F_Me9J<*e9,^H!!*,b!! Simon Nash wrote: > > Andy, > If we could restrict the new flag to chunk size only (see my other note), > then the endtag < chunk size < value tag relationship would still hold true. > > I think you are correct about alignment, which is unfortunate since aligning > every chunk on a 8-byte boundary could add a lot of extra padding. Yes, we do need to do something. Rather than require 8 byte padding on chunks, we could just say they are marshalled like encapsulations--only on 4 byte boundaries. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@floorboard.com Message-ID: <3C3F482F.45B5D13C@floorboard.com> Date: Fri, 11 Jan 2002 12:16:47 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Andy Piper , Jishnu Mukerji , Vijay Natarajan , Harold Carr , Yoshitaka Honishi , Xudong Chen , java2idl-rtf@omg.org, interop@omg.org, michi.henning@iona.com, everett.anderson@Sun.COM Subject: Re: Issue 4795 resolution options References: <4.3.2.7.2.20020109110723.0390c460@san-francisco.beasys.com> <4.3.2.7.2.20020110121949.00b28178@san-francisco.beasys.com> <3C3E0D17.A46C90F7@hursley.ibm.com> <3C3E1777.8A4D4E29@floorboard.com> <3C3ED014.54906D28@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: FYh!!L"Pe9Md-e9 > Jon, > This problem and its solution are orthogonal to issue 4795, which has to > do with allowing RMI-IIOP versioning to be done on the basis of embedded > type information rather than using the SendingContextRunTime callback. OK. > Regarding your proposal, does the value_tag need to indicate byte order? > It's not possible to remarshal an unchunked value without either having its > implementation or its TypeCode, since the length of the data would be unknown. > So I would think that only the chunk_size tag needs to have this flag. Yes, you are right. That is a bit unfortunate, since I was hoping to be able to have it handle all valuetype encodings. Either we punt on that part (which means that things like the Event Service will have to rely on SendingContextRunTime to get the typecode for some valuetypes), or else we modify the unchunked valuetype encoding to have a length as well, in which case the byte order bit becomes useful again. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 11 Jan 2002 22:54:24 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: Andy Piper , Jishnu Mukerji , Vijay Natarajan , Harold Carr , Yoshitaka Honishi , Xudong Chen , java2idl-rtf@omg.org, interop@omg.org, michi.henning@iona.com, everett.anderson@Sun.COM Subject: Re: Issue 4795 resolution options References: <4.3.2.7.2.20020109110723.0390c460@san-francisco.beasys.com> <4.3.2.7.2.20020110121949.00b28178@san-francisco.beasys.com> <3C3E0D17.A46C90F7@hursley.ibm.com> <3C3E1777.8A4D4E29@floorboard.com> <3C3ED014.54906D28@hursley.ibm.com> <3C3F482F.45B5D13C@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ;SYd9Si'e991]!!oB^!! Status: RO Jon, Jonathan Biggar wrote: > > Simon Nash wrote: > > > > Regarding your proposal, does the value_tag need to indicate byte order? > > It's not possible to remarshal an unchunked value without either having its > > implementation or its TypeCode, since the length of the data would be unknown. > > So I would think that only the chunk_size tag needs to have this flag. > > Yes, you are right. That is a bit unfortunate, since I was hoping to be > able to have it handle all valuetype encodings. Either we punt on that > part (which means that things like the Event Service will have to rely > on SendingContextRunTime to get the typecode for some valuetypes), or > else we modify the unchunked valuetype encoding to have a length as > well, in which case the byte order bit becomes useful again. > This would effectively be abolishing the unchunked format and saying that all valuetypes must be chunked. This was discussed by the original submission team but the consensus was that the unchunked form was a useful optimization. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Sender: jon@floorboard.com Message-ID: <3C407D27.D4CF4030@floorboard.com> Date: Sat, 12 Jan 2002 10:15:03 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash , interop@omg.org Subject: Re: Issue 4795 resolution options References: <4.3.2.7.2.20020109110723.0390c460@san-francisco.beasys.com> <4.3.2.7.2.20020110121949.00b28178@san-francisco.beasys.com> <3C3E0D17.A46C90F7@hursley.ibm.com> <3C3E1777.8A4D4E29@floorboard.com> <3C3ED014.54906D28@hursley.ibm.com> <3C3F482F.45B5D13C@floorboard.com> <3C3F6D20.6F7AEAD8@hursley.ibm.com> <3C3F7114.53031D43@floorboard.com> <3C3F769C.BFC61403@hursley.ibm.com> <3C3F79FE.9F978987@floorboard.com> <3C407696.B0DF8CC1@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Tn'e9adYd9!;'!!o > Agreed. I guess the question comes down to whether it is worth getting > > rid of the non-chunked form in order to gain the ability to handle > > valuetypes in generic services like the Event Service without having to > > load the implementations. I think the problem is serious enough to > > accept the extra overhead of chunking. > > > I don't think all valuetypes should carry this overhead just in case they are > being used by generic services. In such cases the valuetype could be sent as an > any, or chunked encoding could be used. Well, here's the problem. The any encoding doesn't guarantee that the valuetype is parsable, since the TypeCode embedded in the any may only be a base type of the actual valuetype transmitted. As for using chunked encoding in such cases, how do you know you are talking to a generic service? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 15 Jan 2002 16:56:01 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: java2idl-rtf@omg.org Subject: Issue 4795 roadmap and revised proposal Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 5GM!!9Ah!!:]Be9~ZH!! In order to make progress on issue 4795, I'd like to suggest that we split it into two parts: a) the immediate need to fix an interoperability problem between JDK 1.3 and JDK 1.4 when certain exceptions are thrown b) the desire expressed by many RTF members and others to allow full type information to be sent with valuetypes, so that callbacks to the SendingContextRunTime aren't needed for versioning This split would allow us to do a fix for part a) in this RTF to close this issue and allow JDK 1.3 to talk to JDK 1.4 correctly, and raise a new issue for part b) to be resolved by the next RTF. The fix for part b) could be part of a new GIOP level and might involve fairly significant CDR changes. If RTF members agree that this plan is reasonable, I'd like to propose resolving part a) by requiring that the SendingContextRunTime service context be processed before the UnknownExceptionInfo service context. If the UnknownExceptionInfo service context happens to physically precede the SendingContextRunTime service context on the wire, and no SendingContextRunTime service context had previously been processed for the connection, then the UnknownExceptionInfo service context would have to be copied to a temporary buffer and its data unmarshalled after the SendingContextRunTime service context has been processed. This should be quite easy to implement, and could be retrofitted to JDK 1.3 in a service update. Adopting this resolution for the immediate problem would not preclude making a further change later to add optional type information to CDR valuetypes so that the need for a callback could be eliminated. Here is the proposed spec change for the resolution to issue 4795: Add a new paragraph at the end of section 1.4.7 of the Java to IDL mapping specification, as follows: In order to support versioning of the Java exception marshalled within an UnknownExceptionInfo service context, a SendingContextRunTime service context must previously have been processed for the connection. If a GIOP message carrying both an UnknownExceptionInfo service context and a SendingContextRunTime service context is received, and no SendingContextRunTime service context has previously been processed for this connection, then the SendingContextRunTime service context must be processed before the data within the UnknownExceptionInfo service context is unmarshalled. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Jan 2002 09:32:01 -0800 To: Simon Nash , java2idl-rtf@omg.org From: Andy Piper Subject: Re: Issue 4795 roadmap and revised proposal In-Reply-To: <3C445F21.16A4E5B9@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: '-2e9`dn!!N),e9OI-!! Ok by me. andy At 04:56 PM 1/15/2002 +0000, Simon Nash wrote: In order to make progress on issue 4795, I'd like to suggest that we split it into two parts: a) the immediate need to fix an interoperability problem between JDK 1.3 and JDK 1.4 when certain exceptions are thrown b) the desire expressed by many RTF members and others to allow full type information to be sent with valuetypes, so that callbacks to the SendingContextRunTime aren't needed for versioning This split would allow us to do a fix for part a) in this RTF to close this issue and allow JDK 1.3 to talk to JDK 1.4 correctly, and raise a new issue for part b) to be resolved by the next RTF. The fix for part b) could be part of a new GIOP level and might involve fairly significant CDR changes. If RTF members agree that this plan is reasonable, I'd like to propose resolving part a) by requiring that the SendingContextRunTime service context be processed before the UnknownExceptionInfo service context. If the UnknownExceptionInfo service context happens to physically precede the SendingContextRunTime service context on the wire, and no SendingContextRunTime service context had previously been processed for the connection, then the UnknownExceptionInfo service context would have to be copied to a temporary buffer and its data unmarshalled after the SendingContextRunTime service context has been processed. This should be quite easy to implement, and could be retrofitted to JDK 1.3 in a service update. Adopting this resolution for the immediate problem would not preclude making a further change later to add optional type information to CDR valuetypes so that the need for a callback could be eliminated. Here is the proposed spec change for the resolution to issue 4795: Add a new paragraph at the end of section 1.4.7 of the Java to IDL mapping specification, as follows: In order to support versioning of the Java exception marshalled within an UnknownExceptionInfo service context, a SendingContextRunTime service context must previously have been processed for the connection. If a GIOP message carrying both an UnknownExceptionInfo service context and a SendingContextRunTime service context is received, and no SendingContextRunTime service context has previously been processed for this connection, then the SendingContextRunTime service context must be processed before the data within the UnknownExceptionInfo service context is unmarshalled. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Thu, 17 Jan 2002 13:51:59 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: interop@omg.org Subject: Re: Issue 4795 resolution options References: <4.3.2.7.2.20020109110723.0390c460@san-francisco.beasys.com> <4.3.2.7.2.20020110121949.00b28178@san-francisco.beasys.com> <3C3E0D17.A46C90F7@hursley.ibm.com> <3C3E1777.8A4D4E29@floorboard.com> <3C3ED014.54906D28@hursley.ibm.com> <3C3F482F.45B5D13C@floorboard.com> <3C3F6D20.6F7AEAD8@hursley.ibm.com> <3C3F7114.53031D43@floorboard.com> <3C3F769C.BFC61403@hursley.ibm.com> <3C3F79FE.9F978987@floorboard.com> <3C407696.B0DF8CC1@hursley.ibm.com> <3C407D27.D4CF4030@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 9E"!!:(H!!*~ld9g-i!! Jon, Jonathan Biggar wrote: > > Simon Nash wrote: > > > Agreed. I guess the question comes down to whether it is worth getting > > > rid of the non-chunked form in order to gain the ability to handle > > > valuetypes in generic services like the Event Service without having to > > > load the implementations. I think the problem is serious enough to > > > accept the extra overhead of chunking. > > > > > I don't think all valuetypes should carry this overhead just in case they are > > being used by generic services. In such cases the valuetype could be sent as an > > any, or chunked encoding could be used. > > Well, here's the problem. The any encoding doesn't guarantee that the > valuetype is parsable, since the TypeCode embedded in the any may only > be a base type of the actual valuetype transmitted. > In such cases, declaring the derived (actual) type as truncatable to the base (TypeCode) type would ensure it is marshaled using chunked encoding. > As for using chunked encoding in such cases, how do you know you are > talking to a generic service? > The example previously given for this was the event service. The > application knows whether or not it is sending data to the event service. The > interfaces for doing this take anys. If the any might contain a derived > valuetype, then the user would have to declare the derived valuetype as truncatable in > order to ensure the use of chunked encoding within the any. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Sender: jon@floorboard.com Message-ID: <3C4B313C.B08898C1@floorboard.com> Date: Sun, 20 Jan 2002 13:06:04 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: interop@omg.org Subject: Re: Issue 4795 resolution options References: <4.3.2.7.2.20020109110723.0390c460@san-francisco.beasys.com> <4.3.2.7.2.20020110121949.00b28178@san-francisco.beasys.com> <3C3E0D17.A46C90F7@hursley.ibm.com> <3C3E1777.8A4D4E29@floorboard.com> <3C3ED014.54906D28@hursley.ibm.com> <3C3F482F.45B5D13C@floorboard.com> <3C3F6D20.6F7AEAD8@hursley.ibm.com> <3C3F7114.53031D43@floorboard.com> <3C3F769C.BFC61403@hursley.ibm.com> <3C3F79FE.9F978987@floorboard.com> <3C407696.B0DF8CC1@hursley.ibm.com> <3C407D27.D4CF4030@floorboard.com> <3C46D6FF.DEB5632B@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Abjd9D#:e9WgXd9#1[d9 Simon Nash wrote: > > Jon, > > Jonathan Biggar wrote: > > > > Simon Nash wrote: > > > > Agreed. I guess the question comes down to whether it is worth getting > > > > rid of the non-chunked form in order to gain the ability to handle > > > > valuetypes in generic services like the Event Service without having to > > > > load the implementations. I think the problem is serious enough to > > > > accept the extra overhead of chunking. > > > > > > > I don't think all valuetypes should carry this overhead just in case they are > > > being used by generic services. In such cases the valuetype could be sent as an > > > any, or chunked encoding could be used. > > > > Well, here's the problem. The any encoding doesn't guarantee that the > > valuetype is parsable, since the TypeCode embedded in the any may only > > be a base type of the actual valuetype transmitted. > > > In such cases, declaring the derived (actual) type as truncatable to the base > (TypeCode) type would ensure it is marshaled using chunked encoding. > > > As for using chunked encoding in such cases, how do you know you are > > talking to a generic service? > > > The example previously given for this was the event service. The application > knows whether or not it is sending data to the event service. The interfaces > for doing this take anys. If the any might contain a derived valuetype, then > the user would have to declare the derived valuetype as truncatable in order > to ensure the use of chunked encoding within the any. That seems essentially error prone, particularly when composing other services that use anys with the event service. Essentially designers will have to declare all derived valuetypes as truncatable to avoid future problems when integrating with generic services. I think it is far better to bite the bullet of the exra small amount of overhead to make sure that valuetypes embedded in an any work everywhere. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org