Issue 3405: Transferring Java exception reason string across the wire (interop) Source: International Business Machines (Mr. Russell Butek, ) Nature: Uncategorized Issue Severity: Summary: Although this is a Java-specific issue, I suspect it will have to be decided in interop, therefore I'd like this to be an interop issue. I've cc'ed java-rtf since I'm sure they'll be interested. System exceptions only have: minor code, completion status. Java exceptions all have a reason string as well. This is a potentially significant bit of info that is not getting transferred across the wire in Java ORB implementations. Our rmi over iiop customers expect this information. Our suggested solution is to create another service context for a system exception reason string. When a system exception occurs, on a Java server, the ORB places the reason string into this service context on the reply message. On a Java client, the ORB checks for and extracts this string and uses it when creating the system exception instance which is propagated to the application code. If the service context doesn't exist, the Java ORB just does what it does today. Any other client bindings may ignore this service context. Java bindings do not need to change for this proposal. To be more precise (sorta), we need three things: 1. A new service context ID const ServiceId SystemExceptionReason = TBD; 2. The context data associated with this ID is a CDR encapsulation of a string. 3. Some verbage somewhere describing this. Resolution: closed/resolved Revised Text: 1. In section 13.6.7, add a new IDL ServiceId constant called " ExceptionDetailMessage (value to be allocated). " 2. In section 13.6.7, add a new bullet to the ServiceId list as follows: " • ExceptionDetailMessage identifies a CDR encapsulation of a wstring, encoded using GIOP 1.2 with a TCS-W of UTF-16. This service context may be sent on Reply messages with a reply_status of SYSTEM_EXCEPTION or USER_EXCEPTION. The usage of this service context is defined by language mappings. " 3. In Table 13-1, add an entry for ExceptionDetailMessage showing that it is an optional part of GIOP 1.2. Actions taken: March 21, 2000: received issue October 4, 2000: closed issue Discussion: The specified encoding for the encapsulated wstring is UTF-16. This seems natural since UTF-16 is the GIOP 1.2 fallback encoding for wstring, and so all ORBs must be able to support this encoding for wstring data. The exception detail message should be encoded as a dedicated service context. If further exception diagnostic data is added in the future, additional service contexts can be defined to carry this. The encoding is GIOP 1.2 (which fixed an encoding ambiguity in GIOP 1.1), with TCS-w of UTF-16. End of Annotations:===== From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: interop@omg.org, issues@omg.org cc: java-rtf@omg.org Message-ID: <852568A9.006B2694.00@d54mta08.raleigh.ibm.com> Date: Tue, 21 Mar 2000 13:22:15 -0600 Subject: Transferring Java exception reason string across the wire Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: Q)Pd9a]l!!\,Qd9U_%!! Although this is a Java-specific issue, I suspect it will have to be decided in interop, therefore I'd like this to be an interop issue. I've cc'ed java-rtf since I'm sure they'll be interested. System exceptions only have: minor code, completion status. Java exceptions all have a reason string as well. This is a potentially significant bit of info that is not getting transferred across the wire in Java ORB implementations. Our rmi over iiop customers expect this information. Our suggested solution is to create another service context for a system exception reason string. When a system exception occurs, on a Java server, the ORB places the reason string into this service context on the reply message. On a Java client, the ORB checks for and extracts this string and uses it when creating the system exception instance which is propagated to the application code. If the service context doesn't exist, the Java ORB just does what it does today. Any other client bindings may ignore this service context. Java bindings do not need to change for this proposal. To be more precise (sorta), we need three things: 1. A new service context ID const ServiceId SystemExceptionReason = TBD; 2. The context data associated with this ID is a CDR encapsulation of a string. 3. Some verbage somewhere describing this. Russell Butek butek@us.ibm.com X-Authentication-Warning: corvette.floorboard.com: jbiggar-u10.cisco.com [171.71.228.71] didn't use HELO protocol Sender: jbiggar@corvette.floorboard.com Date: Tue, 21 Mar 2000 12:32:27 -0800 From: Jonathan Biggar <"jon"@jon@biggar.org> X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: butek@us.ibm.com CC: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <852568A9.006B2694.00@d54mta08.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ;OZd90N7!!`a~e90gg!! butek@us.ibm.com wrote: > > Although this is a Java-specific issue, I suspect it will have to be > decided in interop, therefore I'd like this to be an interop issue. > I've > cc'ed java-rtf since I'm sure they'll be interested. > > System exceptions only have: minor code, completion status. Java > exceptions all have a reason string as well. This is a potentially > significant bit of info that is not getting transferred across the > wire in > Java ORB implementations. Our rmi over iiop customers expect this > information. > > Our suggested solution is to create another service context for a > system > exception reason string. When a system exception occurs, on a Java > server, > the ORB places the reason string into this service context on the > reply > message. On a Java client, the ORB checks for and extracts this > string and > uses it when creating the system exception instance which is > propagated to > the application code. If the service context doesn't exist, the > Java ORB > just does what it does today. Any other client bindings may ignore > this > service context. > > Java bindings do not need to change for this proposal. > > To be more precise (sorta), we need three things: > 1. A new service context ID > > const ServiceId SystemExceptionReason = TBD; > > 2. The context data associated with this ID is a CDR encapsulation > of a > string. > 3. Some verbage somewhere describing this. I like this idea a lot. Clients using other language bindings can install a portable interceptor to extract the string information and make it available to the application code, perhaps through thread specific storage. This would also make it possible for other language mappings, like C++, to add a reason string to exceptions in the future and still maintain backwards compatibility with GIOP 1.2. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Bill Binko To: "'Jonathan Biggar'" <"jon"%jon@biggar.org>, butek@us.ibm.com Cc: interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Tue, 21 Mar 2000 15:38:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: &mb!!S>k!!!Fc!!BSQe9 I agree that the Service Context is a better idea. However, we have an additional concern that this may address. In the Java Mapping (99-7-53 is the latest official one I think) section 1.15.1 "User Defined Exceptions", there is the following text: The Java generated exception class has an additional "full" constructor which has an additional initial string reason parameter which is concatenated to the id before calling the base UserException constructor. This seems to be a way of sending the user text of User Exceptions over the wire as well. The problem is that this modifies the 'id' which is supposed to be the repository ID of the Exception type. Existing systems which rely on this being the case will barf when the see an appended reason text. I would bet that this wasn't done in ignorance, but was discussed first. Could someone please point me to the issue # where this change was made or post the rationale for this? It seems that Russell's Service Context could solve this problem as well. Thanks Binko > -----Original Message----- > From: Jonathan Biggar [mailto:"jon"%jon@biggar.org] > Sent: Tuesday, March 21, 2000 3:32 PM > To: butek@us.ibm.com > Cc: interop@omg.org; java-rtf@omg.org > Subject: Re: Transferring Java exception reason string across the > wire > > > butek@us.ibm.com wrote: > > > > Although this is a Java-specific issue, I suspect it will have to > be > > decided in interop, therefore I'd like this to be an > interop issue. I've > > cc'ed java-rtf since I'm sure they'll be interested. > > > > System exceptions only have: minor code, completion status. Java > > exceptions all have a reason string as well. This is a > potentially > > significant bit of info that is not getting transferred > across the wire in > > Java ORB implementations. Our rmi over iiop customers expect this > > information. > > > > Our suggested solution is to create another service context > for a system > > exception reason string. When a system exception occurs, > on a Java server, > > the ORB places the reason string into this service context > on the reply > > message. On a Java client, the ORB checks for and extracts > this string and > > uses it when creating the system exception instance which > is propagated to > > the application code. If the service context doesn't > exist, the Java ORB > > just does what it does today. Any other client bindings > may ignore this > > service context. > > > > Java bindings do not need to change for this proposal. > > > > To be more precise (sorta), we need three things: > > 1. A new service context ID > > > > const ServiceId SystemExceptionReason = TBD; > > > > 2. The context data associated with this ID is a CDR > encapsulation of a > > string. > > 3. Some verbage somewhere describing this. > > I like this idea a lot. Clients using other language bindings can > install a portable interceptor to extract the string information and > make it available to the application code, perhaps through thread > specific storage. This would also make it possible for other > language > mappings, like C++, to add a reason string to exceptions in the > future > and still maintain backwards compatibility with GIOP 1.2. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > Sender: "Vishy Kasar" Message-ID: <38D7F92F.C01BC503@inprise.com> Date: Tue, 21 Mar 2000 14:35:27 -0800 From: Vishy Kasar Organization: Inprise Corporation - Visibroker Development X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: butek@us.ibm.com CC: interop@omg.org, issues@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <852568A9.006B2694.00@d54mta08.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: D"O!!h9D!!,A5e9 Although this is a Java-specific issue, I suspect it will have to be > decided in interop, therefore I'd like this to be an interop issue. > I've > cc'ed java-rtf since I'm sure they'll be interested. > > System exceptions only have: minor code, completion status. Java > exceptions all have a reason string as well. This is a potentially > significant bit of info that is not getting transferred across the > wire in > Java ORB implementations. Our rmi over iiop customers expect this > information. > > Our suggested solution is to create another service context for a > system > exception reason string. When a system exception occurs, on a Java > server, > the ORB places the reason string into this service context on the > reply > message. On a Java client, the ORB checks for and extracts this > string and > uses it when creating the system exception instance which is > propagated to > the application code. If the service context doesn't exist, the > Java ORB > just does what it does today. Any other client bindings may ignore > this > service context. > > Java bindings do not need to change for this proposal. > > To be more precise (sorta), we need three things: > 1. A new service context ID > > const ServiceId SystemExceptionReason = TBD; > > 2. The context data associated with this ID is a CDR encapsulation > of a > string. > 3. Some verbage somewhere describing this. > > Russell Butek > butek@us.ibm.com -- Cheers! Date: Wed, 22 Mar 2000 09:40:19 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: <200003212031.MAA26198@corvette.floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: `<(!!G~X!!l&J!!^~I!! On Tue, 21 Mar 2000, Jonathan Biggar wrote: > butek@us.ibm.com wrote: > > Our suggested solution is to create another service context for a > system > > exception reason string. When a system exception occurs, on a > Java server, > > the ORB places the reason string into this service context on the > reply > > message. On a Java client, the ORB checks for and extracts this > string and > > uses it when creating the system exception instance which is > propagated to > > the application code. If the service context doesn't exist, the > Java ORB > > just does what it does today. Any other client bindings may > ignore this > > service context. > > > > I like this idea a lot. Clients using other language bindings can > install a portable interceptor to extract the string information and > make it available to the application code, perhaps through thread > specific storage. This would also make it possible for other > language > mappings, like C++, to add a reason string to exceptions in the > future > and still maintain backwards compatibility with GIOP 1.2. I think that's about the most filthy hack I've come across in quite some time. We now have a data type that is partly sent in the reply and partly sent in the service context. Moreover, the data that is sent for the type is no longer derived from its IDL definition. Maybe if we think long and hard enough, we can find even more revolting abuses of the service context? For that matter, why don't we just give normal message formats a miss completely and transmit everything as an XML string inside the service context? :-( Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Tue, 21 Mar 2000 18:40:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: [SB!!ffld92B -----Original Message----- > From: Vishy Kasar [mailto:vishy@inprise.com] > Sent: Tuesday, March 21, 2000 5:35 PM > To: butek@us.ibm.com > Cc: interop@omg.org; issues@omg.org; java-rtf@omg.org > Subject: Re: Transferring Java exception reason string across the > wire > > > > This is a good idea and Visibroker is doing something similar > already using vb > specific service context. But I dont think we should be > mandating that this > should be 'reason string'. In java for example, we can send > the whole server > side stack trace using this string. This will be really useful to > the > customers. We can state that this service context contains a > string and > ORB vendors have freedom to put what they want in that string. X-Authentication-Warning: corvette.floorboard.com: jbiggar-u10.cisco.com [171.71.228.71] didn't use HELO protocol Sender: jbiggar@corvette.floorboard.com Date: Tue, 21 Mar 2000 15:53:22 -0800 From: Jonathan Biggar <"jon"@jon@biggar.org> X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Jonathan Biggar , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,N5!!p2g!!O:)!!c!1e9 Michi Henning wrote: > > > Our suggested solution is to create another service context for > a system > > > exception reason string. When a system exception occurs, on a > Java server, > > > the ORB places the reason string into this service context on > the reply > > > message. On a Java client, the ORB checks for and extracts this > string and > > > uses it when creating the system exception instance which is > propagated to > > > the application code. If the service context doesn't exist, the > Java ORB > > > just does what it does today. Any other client bindings may > ignore this > > > service context. > > > > > > > I like this idea a lot. Clients using other language bindings can > > install a portable interceptor to extract the string information > and > > make it available to the application code, perhaps through thread > > specific storage. This would also make it possible for other > language > > mappings, like C++, to add a reason string to exceptions in the > future > > and still maintain backwards compatibility with GIOP 1.2. > > I think that's about the most filthy hack I've come across in quite > some > time. We now have a data type that is partly sent in the reply and > partly > sent in the service context. Moreover, the data that is sent for the > type > is no longer derived from its IDL definition. Maybe if we think long > and > hard enough, we can find even more revolting abuses of the service > context? > For that matter, why don't we just give normal message formats a > miss > completely and transmit everything as an XML string inside the > service > context? :-( Sure it's a hack, but it uses the only extensible part of the GIOP message format--service contexts. Until we take the time to write, issue, develop responses for, vote on responses to an RFP for GIOP 2.0, we aren't going to get anything much than this. The only other choice would be to extend the format of system exceptions in GIOP 1.3 to add a reason string. The advantage of using the service context is that it can be used even with GIOP 1.0. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 22 Mar 2000 10:16:38 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BD1D@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: gfR!!;/j!!^_(e9#JEe9 On Tue, 21 Mar 2000, Paul Kyzivat wrote: > Sending the string as a service context seems like a reasonable idea. But > its value is directly proportional to how specific you are about what it > means. Saying you can put whatever you want into the string means that you > are telling the receiver he can get a string out but can't make any > particular interpretation of it. > > If you have a string in a Java system exception on the client side, and you > want to see *that* string associated with the corresponding exception on the > server side, then you had better say this service context carries *the* > optional string that may be associated with a system exception. > > Otherwise, you are going to get some very strange results when > interoperating with different orbs or different language bindings. Never mind the localization issues too. Since the client may be in a totally different locale than the server, the string may not make any sense to the client at all. Worse, the server cannot know the local of the client, meaning that the server can't localize the string and, conversely, because the client cannot know what messages may be produced by the server, it can't localize the string either. This reeks of bad design all over... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Tue, 21 Mar 2000 19:35:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Q_a!!;AO!!n/Nd9J[B!! OK. Michi has convinced me that it isn't reasonable. Paul > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Tuesday, March 21, 2000 7:17 PM > To: Paul Kyzivat > Cc: interop@omg.org; java-rtf@omg.org > Subject: RE: Transferring Java exception reason string across the > wire > > > On Tue, 21 Mar 2000, Paul Kyzivat wrote: > > > Sending the string as a service context seems like a > reasonable idea. But > > its value is directly proportional to how specific you are > about what it > > means. Saying you can put whatever you want into the string > means that you > > are telling the receiver he can get a string out but can't make > any > > particular interpretation of it. > > > > If you have a string in a Java system exception on the > client side, and you > > want to see *that* string associated with the corresponding > exception on the > > server side, then you had better say this service context > carries *the* > > optional string that may be associated with a system exception. > > > > Otherwise, you are going to get some very strange results when > > interoperating with different orbs or different language bindings. > > Never mind the localization issues too. Since the client may > be in a totally > different locale than the server, the string may not make any sense > to > the client at all. Worse, the server cannot know the local of > the client, > meaning that the server can't localize the string and, > conversely, because > the client cannot know what messages may be produced by the > server, it can't > localize the string either. > > This reeks of bad design all over... > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: Michi Henning cc: interop@omg.org, java-rtf@omg.org Message-ID: <852568AA.004A9334.00@d54mta08.raleigh.ibm.com> Date: Wed, 22 Mar 2000 07:26:24 -0600 Subject: Re: Transferring Java exception reason string across the wire Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: on 03/21/2000 05:40:19 PM To: Jonathan Biggar cc: Russell Butek/Austin/IBM@IBMUS, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire On Tue, 21 Mar 2000, Jonathan Biggar wrote: > butek@us.ibm.com wrote: > > Our suggested solution is to create another service context for a system > > exception reason string. When a system exception occurs, on a > Java server, > > the ORB places the reason string into this service context on the > reply > > message. On a Java client, the ORB checks for and extracts this > string and > > uses it when creating the system exception instance which is > propagated to > > the application code. If the service context doesn't exist, the > Java ORB > > just does what it does today. Any other client bindings may > ignore this > > service context. > > > > I like this idea a lot. Clients using other language bindings can > install a portable interceptor to extract the string information and > make it available to the application code, perhaps through thread > specific storage. This would also make it possible for other > language > mappings, like C++, to add a reason string to exceptions in the > future > and still maintain backwards compatibility with GIOP 1.2. I think that's about the most filthy hack I've come across in quite some time. We now have a data type that is partly sent in the reply and partly sent in the service context. Moreover, the data that is sent for the type is no longer derived from its IDL definition. Maybe if we think long and hard enough, we can find even more revolting abuses of the service context? For that matter, why don't we just give normal message formats a miss completely and transmit everything as an XML string inside the service context? :-( Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 22 Mar 2000 13:24:09 -0330 From: Matthew Newhook To: butek@us.ibm.com Cc: Michi Henning , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire Message-ID: <20000322132409.A26065@ooc.com> References: <852568AA.004A9334.00@d54mta08.raleigh.ibm.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <852568AA.004A9334.00@d54mta08.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii X-UIDL: od9e9Rc~!!Sj"!!8_k!! Hi, On Wed, Mar 22, 2000 at 07:26:24AM -0600, butek@us.ibm.com wrote: > Yes, this is a hack, but so is most of CORBA. It is? Please enumerate the set of nasty hacks that pollute most of CORBA. > The real problem is that exceptions are not first class objects. If they > were, the Java bindings could extend the base SystemException class to add > a reason string and that class could be sent across the wire. If the other > side isn't Java, then it would just see a SystemException and everything > would be peachy. Mmmm... isn't SystemException a struct which isn't extensible? ;) > We do not advocate that all bindings take advantage of this proposal. We > are merely talking about the Java bindings. In the Java world we are > losing a very useful bit of info that is available when a programmer uses > normal rmi. Our customers are puzzled that this info isn't available when > using rmi over iiop. > > We are already using a service context hack for Java - UnknownExceptionInfo > - so this idea is certainly not new. I think this is a total and abolutely disgusting hack. By using ServiceContexts in this way we are inviting more an more hacks on top of an already fragile system. Pretty soon interop will be totally out the window. That is bad for CORBA, and bad for the vendors. > Russell Butek > butek@us.ibm.com Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 22 Mar 2000 12:09:50 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning Cc: Jonathan Biggar , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: @3+!!;V@e9M8Zd9'h~!! Michi Henning wrote: > On Tue, 21 Mar 2000, Jonathan Biggar wrote: > > > butek@us.ibm.com wrote: > > > Our suggested solution is to create another service context for a system > > > exception reason string. When a system exception occurs, on a Java server, > > > the ORB places the reason string into this service context on the reply > > > message. On a Java client, the ORB checks for and extracts this string and > > > uses it when creating the system exception instance which is propagated to > > > the application code. If the service context doesn't exist, the Java ORB > > > just does what it does today. Any other client bindings may ignore this > > > service context. > > > > > > > I like this idea a lot. Clients using other language bindings can > > install a portable interceptor to extract the string information and > > make it available to the application code, perhaps through thread > > specific storage. This would also make it possible for other language > > mappings, like C++, to add a reason string to exceptions in the future > > and still maintain backwards compatibility with GIOP 1.2. > > I think that's about the most filthy hack I've come across in quite some > time. We now have a data type that is partly sent in the reply and partly > sent in the service context. Moreover, the data that is sent for the type > is no longer derived from its IDL definition. Michi, I thought that this is an OK idea because I did not consider the whole ball of wax to be a single data type, precisely because you can't get that info from the IDL definition. The additional info is Java specific and is used only by Java clients when talking to Java servers. Moreover, since it is Java specific, the codeset issue is moot too, since Java is, shall we say somewhat restricted, in the codesets that it can deal with. Clearly the same restrictions shall apply to the string in this proposed service context. So, in spite of my esteemed colleagues displeasure, I think this is a fine idea for the restricted purpose for which it was originally proposed. I am more dubious about its extension for use with other languages. Jishnu. Date: Wed, 22 Mar 2000 14:54:07 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <9B164B713EE9D211B6DC0090273CEEA926BD21@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 1p@e9NE6e9>#0e9n$Ke9 Paul, I still need more convincing. In the worst case, the string will not be intelligible to the receiver, which leaves the receiver no worse off than the current situation (who still has minor code and completion status information). Also, Java exception detail strings are not localized, so if the service context is intended for this purpose then the lack of localization is not an issue. (The reason for this is that these strings are not messages intended for end users but diagnostic information used in problem determination.) If the ability to pass localized exception information strings is also needed, then we should add exchange of locale information to the existing exchange of codeset information (in the next GIOP revision). Simon Paul Kyzivat wrote: > > OK. Michi has convinced me that it isn't reasonable. > > Paul > > > -----Original Message----- > > From: Michi Henning [mailto:michi@ooc.com.au] > > Sent: Tuesday, March 21, 2000 7:17 PM > > To: Paul Kyzivat > > Cc: interop@omg.org; java-rtf@omg.org > > Subject: RE: Transferring Java exception reason string across the > wire > > > > > > On Tue, 21 Mar 2000, Paul Kyzivat wrote: > > > > > Sending the string as a service context seems like a > > reasonable idea. But > > > its value is directly proportional to how specific you are > > about what it > > > means. Saying you can put whatever you want into the string > > means that you > > > are telling the receiver he can get a string out but can't make > any > > > particular interpretation of it. > > > > > > If you have a string in a Java system exception on the > > client side, and you > > > want to see *that* string associated with the corresponding > > exception on the > > > server side, then you had better say this service context > > carries *the* > > > optional string that may be associated with a system exception. > > > > > > Otherwise, you are going to get some very strange results when > > > interoperating with different orbs or different language > bindings. > > > > Never mind the localization issues too. Since the client may > > be in a totally > > different locale than the server, the string may not make any > sense to > > the client at all. Worse, the server cannot know the local of > > the client, > > meaning that the server can't localize the string and, > > conversely, because > > the client cannot know what messages may be produced by the > > server, it can't > > localize the string either. > > > > This reeks of bad design all over... > > > > Cheers, > > > > > Michi. > > -- > > Michi Henning +61 7 3891 5744 > > Object Oriented Concepts +61 4 1118 2700 (mobile) > > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > > East Brisbane 4169 michi@ooc.com.au > > AUSTRALIA > > http://www.ooc.com.au/staff/michi-henning.html > > -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Wed, 22 Mar 2000 14:43:35 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <9B164B713EE9D211B6DC0090273CEEA926BD1D@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: =W!"!$Y_!!UHid99L_d9 Paul, I agree with your sentiments. However, the usage of the string is more a matter for language mappings that the interop RTF. The interop chapter can say something generic like the string contains human-readable text giving additional information about the exception, but it is for the language mapping RTFs to say how the sender marshals the string and how the receiver unmarshals it. I would expect Java to map the on-the-wire string from and to the detail string of the exception object. Even if the string contained a stack trace, there wouldn't be any better way to unmarshal this in Java since there's no way to construct a Java exception with an externally provided stack trace. Simon Paul Kyzivat wrote: > > Sending the string as a service context seems like a reasonable > idea. But > its value is directly proportional to how specific you are about > what it > means. Saying you can put whatever you want into the string means > that you > are telling the receiver he can get a string out but can't make any > particular interpretation of it. > > If you have a string in a Java system exception on the client side, > and you > want to see *that* string associated with the corresponding > exception on the > server side, then you had better say this service context carries > *the* > optional string that may be associated with a system exception. > > Otherwise, you are going to get some very strange results when > interoperating with different orbs or different language bindings. > > Paul > > > -----Original Message----- > > From: Vishy Kasar [mailto:vishy@inprise.com] > > Sent: Tuesday, March 21, 2000 5:35 PM > > To: butek@us.ibm.com > > Cc: interop@omg.org; issues@omg.org; java-rtf@omg.org > > Subject: Re: Transferring Java exception reason string across the > wire > > > > > > > > This is a good idea and Visibroker is doing something similar > > already using vb > > specific service context. But I dont think we should be > > mandating that this > > should be 'reason string'. In java for example, we can send > > the whole server > > side stack trace using this string. This will be really useful to > the > > customers. We can state that this service context contains a > > string and > > ORB vendors have freedom to put what they want in that string. -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Wed, 22 Mar 2000 14:16:30 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Bill Binko CC: "'Jonathan Biggar'" , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: \7h!!'A`!!iF]d92/ > I agree that the Service Context is a better idea. However, we have > an > additional concern that this may address. In the Java Mapping > (99-7-53 is > the latest official one I think) section 1.15.1 "User Defined > Exceptions", > there is the following text: > > The Java generated exception class has an additional "full" > constructor > which has an > additional initial string reason parameter which is concatenated > to the > id before > calling the base UserException constructor. > > This seems to be a way of sending the user text of User Exceptions > over the > wire as well. The problem is that this modifies the 'id' which is > supposed > to be the repository ID of the Exception type. Existing systems > which rely > on this being the case will barf when the see an appended reason > text. > > I would bet that this wasn't done in ignorance, but was discussed > first. > Could someone please point me to the issue # where this change was > made or > post the rationale for this? > > It seems that Russell's Service Context could solve this problem as > well. > > Thanks > Binko > > > -----Original Message----- > > From: Jonathan Biggar [mailto:"jon"%jon@biggar.org] > > Sent: Tuesday, March 21, 2000 3:32 PM > > To: butek@us.ibm.com > > Cc: interop@omg.org; java-rtf@omg.org > > Subject: Re: Transferring Java exception reason string across the > wire > > > > > > butek@us.ibm.com wrote: > > > > > > Although this is a Java-specific issue, I suspect it will have > to be > > > decided in interop, therefore I'd like this to be an > > interop issue. I've > > > cc'ed java-rtf since I'm sure they'll be interested. > > > > > > System exceptions only have: minor code, completion status. > Java > > > exceptions all have a reason string as well. This is a > potentially > > > significant bit of info that is not getting transferred > > across the wire in > > > Java ORB implementations. Our rmi over iiop customers expect > this > > > information. > > > > > > Our suggested solution is to create another service context > > for a system > > > exception reason string. When a system exception occurs, > > on a Java server, > > > the ORB places the reason string into this service context > > on the reply > > > message. On a Java client, the ORB checks for and extracts > > this string and > > > uses it when creating the system exception instance which > > is propagated to > > > the application code. If the service context doesn't > > exist, the Java ORB > > > just does what it does today. Any other client bindings > > may ignore this > > > service context. > > > > > > Java bindings do not need to change for this proposal. > > > > > > To be more precise (sorta), we need three things: > > > 1. A new service context ID > > > > > > const ServiceId SystemExceptionReason = TBD; > > > > > > 2. The context data associated with this ID is a CDR > > encapsulation of a > > > string. > > > 3. Some verbage somewhere describing this. > > > > I like this idea a lot. Clients using other language bindings can > > install a portable interceptor to extract the string information > and > > make it available to the application code, perhaps through thread > > specific storage. This would also make it possible for other > language > > mappings, like C++, to add a reason string to exceptions in the > future > > and still maintain backwards compatibility with GIOP 1.2. > > > > -- > > Jon Biggar > > Floorboard Software > > jon@floorboard.com > > jon@biggar.org > > -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Wed, 22 Mar 2000 14:35:43 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Jonathan Biggar , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ^VVd9E)Z!!&A:!!!W7e9 Michi, It is unfortunate that the original designers of CORBA system exceptions did not allow for the possibility of sending textual diagnostic information as well as the completion status and numeric minor code. But given that 1. they did not 2. their decision is hard coded into every ORB on the planet 3. the only way to add textual information is via a service context 4. real users of CORBA feel this is a serious issue I think you should be willing to consider the merits of this proposal. The continued success of CORBA depends on meeting reasonable user requirements and in the Java world (at least) the inability to pass the detail string is perceived as a usability defect. We can "just say No" and turn all such user requests down on the grounds of architectural purity but this would (IMO) be a self-defeating philosophy. Simon Michi Henning wrote: > > On Tue, 21 Mar 2000, Jonathan Biggar wrote: > > > butek@us.ibm.com wrote: > > > Our suggested solution is to create another service context for > a system > > > exception reason string. When a system exception occurs, on a > Java server, > > > the ORB places the reason string into this service context on > the reply > > > message. On a Java client, the ORB checks for and extracts this > string and > > > uses it when creating the system exception instance which is > propagated to > > > the application code. If the service context doesn't exist, the > Java ORB > > > just does what it does today. Any other client bindings may > ignore this > > > service context. > > > > > > > I like this idea a lot. Clients using other language bindings can > > install a portable interceptor to extract the string information > and > > make it available to the application code, perhaps through thread > > specific storage. This would also make it possible for other > language > > mappings, like C++, to add a reason string to exceptions in the > future > > and still maintain backwards compatibility with GIOP 1.2. > > I think that's about the most filthy hack I've come across in quite > some > time. We now have a data type that is partly sent in the reply and > partly > sent in the service context. Moreover, the data that is sent for the > type > is no longer derived from its IDL definition. Maybe if we think long > and > hard enough, we can find even more revolting abuses of the service > context? > For that matter, why don't we just give normal message formats a > miss > completely and transmit everything as an XML string inside the > service > context? :-( > > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Thu, 23 Mar 2000 07:57:26 +1000 (EST) From: Michi Henning To: butek@us.ibm.com cc: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: <852568AA.004A9334.00@d54mta08.raleigh.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: X]#e9:RTd960G!!PD%e9 On Wed, 22 Mar 2000 butek@us.ibm.com wrote: > Yes, this is a hack, but so is most of CORBA. So, it's OK to add more hacks? > The real problem is that exceptions are not first class objects. If they > were, the Java bindings could extend the base SystemException class to add > a reason string and that class could be sent across the wire. If the other > side isn't Java, then it would just see a SystemException and everything > would be peachy. Well, not all the world is Java, and CORBA isn't there just to satisfy Java. > We do not advocate that all bindings take advantage of this proposal. We > are merely talking about the Java bindings. In the Java world we are > losing a very useful bit of info that is available when a programmer uses > normal rmi. Our customers are puzzled that this info isn't available when > using rmi over iiop. Tough. They can use some other mechanism then. I will continue to refuse to add language-specific hacks to the protocol level, just as I will refuse to add language-specific things to IDL. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Wed, 22 Mar 2000 17:09:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 5kcd9'5'e9hKk!!4g~!! If this is defined as a Java specific thing, then following Jishnu's logic, I don't have any major objection. If this is abstracted as a general feature then I object. On the other hand, features that only work when the two ends are both Java seriously break CORBA language independence, and should be discouraged. (Those who believe the only language is Java will disagree.) So a better solution would be to agree that a string is a useful component of SystemException, and then add that feature in a way that makes sense in a language independent way. Paul > -----Original Message----- > From: Simon Nash [mailto:nash@hursley.ibm.com] > Sent: Wednesday, March 22, 2000 9:54 AM > To: Paul Kyzivat > Cc: interop@omg.org; java-rtf@omg.org > Subject: Re: Transferring Java exception reason string across the > wire > > > Paul, > I still need more convincing. > > In the worst case, the string will not be intelligible to the > receiver, > which leaves the receiver no worse off than the current situation > (who > still has minor code and completion status information). > > Also, Java exception detail strings are not localized, so if > the service > context is intended for this purpose then the lack of > localization is not > an issue. (The reason for this is that these strings are not > messages > intended for end users but diagnostic information used in problem > determination.) > > If the ability to pass localized exception information strings is > also > needed, then we should add exchange of locale information to > the existing > exchange of codeset information (in the next GIOP revision). > > Simon > > Paul Kyzivat wrote: > > > > OK. Michi has convinced me that it isn't reasonable. > > > > Paul Sender: Peter.Walker@eng.sun.com Message-ID: <38D943A0.3764174C@eng.Sun.COM> Date: Wed, 22 Mar 2000 14:05:20 -0800 From: Peter Walker Organization: Sun Microsystems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: n5Ae92M7e9(Qc!!Z?`d9 Michi Henning wrote: > > I will continue to refuse to add > language-specific hacks to the protocol level, just as I will refuse > to > add language-specific things to IDL. > Michi, We already did this with a bunch of types from the COBOL world and where did the "look and feel" of IDL come from in the first place? Pj. From: Paul Kyzivat To: interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Wed, 22 Mar 2000 17:24:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: [HVd9I:C!!ip^d9JaL!! > From: Simon Nash [mailto:nash@hursley.ibm.com] > We can "just say No" and turn all such user requests down on > the grounds of architectural purity but this would (IMO) > be a self-defeating philosophy. > > Simon Simon, you are one of the last people I would expect to get such an argument from! But I will be even more surprised if I hear that from Bill J :-) From: Bill Binko To: "'Simon Nash'" , Bill Binko Cc: "'Jonathan Biggar'" , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Wed, 22 Mar 2000 17:51:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 9iXd9Y[c!![D@!!Qj2!! My apologies.. I took the phrase "concatenated to the id" to mean modification of the id (which is marshalled with the Exception). -- My Bad That being said, I have a suggestion to make on this subject. Flame away, but it may make Michi feel better. I think that _in_general_ and in _most_ languages, there can be a need for diagnostic information after a call has completed. This is true regardless of the outcome (reply or exception in our case) and has nothing to do with the language being used. I don't think it would be a bad idea to define a standard service context that held this type of diagnostic information. Much like the old 'errno" of C, there is no guarantee that the callee will set this correctly, but it doesn't hurt to check. With PI allowing us to place service contexts easily on the reply, and read them easily, I don't see why making an _optional_ _standard_ service context for this type of data would be quite the hack Michi says. Now. Requiring ORBs to populate the service context is another matter. And even _requiring_ them through the Java language mapping to check for them could be objectionable. However, I think the proposal has merit if people would quit stating it in a Java-only way. If Java vendors agree among themselve to populate it, that's great. Binko > -----Original Message----- > From: Simon Nash [mailto:nash@hursley.ibm.com] > Sent: Wednesday, March 22, 2000 9:17 AM > To: Bill Binko > Cc: 'Jonathan Biggar'; butek@us.ibm.com; interop@omg.org; > java-rtf@omg.org > Subject: Re: Transferring Java exception reason string across the > wire > > > Bill, > Russell's proposal is for system exceptions, not user exceptions. > > The Java mapping for user exceptions includes a constructor > that allows > a detail string to be appended, as you say. However, this > string is not > sent on the wire and therefore cannot cause any receiver to > barf. It is > a purely local information-only user diagnostic aid and does > not modify > the id of the exception, since the detail string is derived > from the id > of the exception, not vice versa. > > Simon > > Bill Binko wrote: > > > > I agree that the Service Context is a better idea. > However, we have an > > additional concern that this may address. In the Java > Mapping (99-7-53 is > > the latest official one I think) section 1.15.1 "User > Defined Exceptions", > > there is the following text: > > > > The Java generated exception class has an additional > "full" constructor > > which has an > > additional initial string reason parameter which is > concatenated to the > > id before > > calling the base UserException constructor. > > > > This seems to be a way of sending the user text of User > Exceptions over the > > wire as well. The problem is that this modifies the 'id' > which is supposed > > to be the repository ID of the Exception type. Existing > systems which rely > > on this being the case will barf when the see an appended > reason text. > > > > I would bet that this wasn't done in ignorance, but was > discussed first. > > Could someone please point me to the issue # where this > change was made or > > post the rationale for this? > > > > It seems that Russell's Service Context could solve this > problem as well. > > > > Thanks > > Binko > > > > > -----Original Message----- > > > From: Jonathan Biggar [mailto:"jon"%jon@biggar.org] > > > Sent: Tuesday, March 21, 2000 3:32 PM > > > To: butek@us.ibm.com > > > Cc: interop@omg.org; java-rtf@omg.org > > > Subject: Re: Transferring Java exception reason string > across the wire > > > > > > > > > butek@us.ibm.com wrote: > > > > > > > > Although this is a Java-specific issue, I suspect it > will have to be > > > > decided in interop, therefore I'd like this to be an > > > interop issue. I've > > > > cc'ed java-rtf since I'm sure they'll be interested. > > > > > > > > System exceptions only have: minor code, completion > status. Java > > > > exceptions all have a reason string as well. This is a > potentially > > > > significant bit of info that is not getting transferred > > > across the wire in > > > > Java ORB implementations. Our rmi over iiop customers > expect this > > > > information. > > > > > > > > Our suggested solution is to create another service context > > > for a system > > > > exception reason string. When a system exception occurs, > > > on a Java server, > > > > the ORB places the reason string into this service context > > > on the reply > > > > message. On a Java client, the ORB checks for and extracts > > > this string and > > > > uses it when creating the system exception instance which > > > is propagated to > > > > the application code. If the service context doesn't > > > exist, the Java ORB > > > > just does what it does today. Any other client bindings > > > may ignore this > > > > service context. > > > > > > > > Java bindings do not need to change for this proposal. > > > > > > > > To be more precise (sorta), we need three things: > > > > 1. A new service context ID > > > > > > > > const ServiceId SystemExceptionReason = TBD; > > > > > > > > 2. The context data associated with this ID is a CDR > > > encapsulation of a > > > > string. > > > > 3. Some verbage somewhere describing this. > > > > > > I like this idea a lot. Clients using other language bindings > can > > > install a portable interceptor to extract the string > information and > > > make it available to the application code, perhaps through > thread > > > specific storage. This would also make it possible for > other language > > > mappings, like C++, to add a reason string to exceptions > in the future > > > and still maintain backwards compatibility with GIOP 1.2. > > > > > > -- > > > Jon Biggar > > > Floorboard Software > > > jon@floorboard.com > > > jon@biggar.org > > > > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > Date: Wed, 22 Mar 2000 22:48:58 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: butek@us.ibm.com, Michi Henning , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <852568AA.004A9334.00@d54mta08.raleigh.ibm.com> <20000322132409.A26065@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: US^!!6@0e9$Eid9o&1e9 Matthew, Matthew Newhook wrote: > > Hi, > > On Wed, Mar 22, 2000 at 07:26:24AM -0600, butek@us.ibm.com wrote: > > Yes, this is a hack, but so is most of CORBA. > > It is? Please enumerate the set of nasty hacks that pollute most of > CORBA. > > > The real problem is that exceptions are not first class objects. > If they > > were, the Java bindings could extend the base SystemException > class to add > > a reason string and that class could be sent across the wire. If > the other > > side isn't Java, then it would just see a SystemException and > everything > > would be peachy. > > Mmmm... isn't SystemException a struct which isn't extensible? ;) > In Java, it's a non-final abstract class. But this is getting > somewhat away from the main point. This issue is not about redoing CORBA > exceptions. We debated that one recently and the decision was clear-cut. I think Russell's point is that given that we decided not to redesign the > CORBA exception model, the only way we can we can satisfy user requests like > this is to use some kind of "bolt on" approach. We can't have this both > ways! And I don't see why this is worse than all the other existing uses of service contexts. > > We do not advocate that all bindings take advantage of this proposal. We > > are merely talking about the Java bindings. In the Java world we are > > losing a very useful bit of info that is available when a programmer uses > > normal rmi. Our customers are puzzled that this info isn't available when > > using rmi over iiop. > > > > We are already using a service context hack for Java - UnknownExceptionInfo > > - so this idea is certainly not new. > > I think this is a total and abolutely disgusting hack. By using > ServiceContexts in this way we are inviting more an more hacks on top > of an already fragile system. Pretty soon interop will be totally out > the window. That is bad for CORBA, and bad for the vendors. > Whatever your opinion on whether this is a hack, it is not accurate to claim that it damages interoperability. ORBs that do not recognize the service context would just ignore it. Interoperability at the current level of functionality (losing the Java detail string) is unaffected by this change. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: Jeffrey Mischkinsky Message-Id: <200003230636.WAA20918@wheel.dcn.davis.ca.us> Subject: Re: Transferring Java exception reason string across the wire To: jon@floorboard.com (Jonathan Biggar) Date: Wed, 22 Mar 2000 22:36:17 -0800 (PST) Cc: michi@ooc.com.au (Michi Henning), interop@omg.org, java-rtf@omg.org In-Reply-To: <38D9A09C.94180D74@floorboard.com> from "Jonathan Biggar" at Mar 22, 2000 08:42:04 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: ]84e9>l3e9I4#!!>k(!! 'Jonathan Biggar' writes: > > Michi Henning wrote: > > > > The suggestion that is being made means to marshal an > exception in conflict > > > > with its IDL definition. In other words, the data being > marshaled is no > > > > longer in agreement with the IDL definition of a type. > > > > > > I disagree. This proposal allows additional *optional* > information to > > > be passed. Since a receiver that has no knowledge of the > service > > > context can still unmarshal the exception, your claim that there > is a > > > conflict is simply not true. > > > > Well, I certainly think that this sets a very dangerous > precedent. I can > > just see the next change coming up: we decide that we'd like to > add an > > extra field to some IDL struct. Because we don't want to touch the > IDL, > > we just add another service context to carry the extra field... > > I most definitely don't want to set that precedent. > > > > And, given that there is no guarantee that the string will be > present, > > because it's optional, I seriously wonder what it's going to be > good for, > > given that I can't rely on it being there anyway. What's being > suggested > > here is useful only for Java clients talking to Java servers via > RMI over > > IIOP -- and for that, we are going to make additions to GIOP? > > Michi, Michi. This is *NOT* a change to GIOP! The only service > context > that is really a part of GIOP is the codeset context, since it > affects > the interpretation of marshalled data. (And for this reason, the > codeset info really should have been part of the GIOP message format > directly, which would resolve the other thread we have going on on > this > list.) (ok you've sucked me in now! :-( Not true, the set of valid service context id's is part of the definition of a particular version of giop. ORBs that implement verision n.m can only be expected to understand service contexts that were defined for versions n.m and below. > > ALL of the other service contexts are simply using GIOP as a transport > mechanism, this proposed one as well. And they may or may not modify the meaning and interpretation of the GIOP message, depending upon the semantics of the data they carry.. jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Sender: jon@corvette.floorboard.com Message-ID: <38D9C8C5.4C088DE5@floorboard.com> Date: Wed, 22 Mar 2000 23:33:25 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 4i~e9&*h!!"F9e9+oI!! Michi Henning wrote: > As I said, the OTS context isn't just for one language, it's present > only > when needed, and it's the only way to permit both transactional and > non-transactional implementations to use the same IDL. So, this allows Java and non Java applications to use the same IDL definition of SystemException. :-) > > > It's a *service* context, not an application or language context. > > > > Fine, so we reword this proposal to call it the "reason string service" > > which just happens to work the same way. Arguing based on the fact that > > we call it a "service context" that you can't use if for application or > > language dependent purposes is incredibly weak. > > I find it incredibly weak that system exceptions in Java suddenly would have > preferred status, that a change at the protocol level is required to make > it possible, that the information isn't guaranteed to be there at all, and > that I can't access it anywhere except with RMI over IIOP (because the > language mappings are missing, if nothing else). This isn't a change at the protocol level. GIOP was designed from the beginning to have the service context field to carry arbitrary blobs that are created and consumed by other parts of the ORB architecture. Your argument that this somehow "contaminates GIOP" is not valid. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 22 Mar 2000 17:18:46 -0800 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar <"jon"@jon@biggar.org> CC: Michi Henning , Jonathan Biggar , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <200003212352.PAA26486@corvette.floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: !^Q!!a$W!!)BKe9-^9!! Jonathan Biggar wrote: > Michi Henning wrote: > > > > Our suggested solution is to create another service context > for a system > > > > exception reason string. When a system exception occurs, on a > Java server, > > > > the ORB places the reason string into this service context on > the reply > > > > message. On a Java client, the ORB checks for and extracts > this string and > > > > uses it when creating the system exception instance which is > propagated to > > > > the application code. If the service context doesn't exist, > the Java ORB > > > > just does what it does today. Any other client bindings may > ignore this > > > > service context. > > > > > > > > > > I like this idea a lot. Clients using other language bindings > can > > > install a portable interceptor to extract the string information > and > > > make it available to the application code, perhaps through > thread > > > specific storage. This would also make it possible for other > language > > > mappings, like C++, to add a reason string to exceptions in the > future > > > and still maintain backwards compatibility with GIOP 1.2. > > > > I think that's about the most filthy hack I've come across in > quite some > > time. We now have a data type that is partly sent in the reply and > partly > > sent in the service context. Moreover, the data that is sent for > the type > > is no longer derived from its IDL definition. Maybe if we think > long and > > hard enough, we can find even more revolting abuses of the service > context? > > For that matter, why don't we just give normal message formats a > miss > > completely and transmit everything as an XML string inside the > service > > context? :-( > > Sure it's a hack, but it uses the only extensible part of the GIOP > message format--service contexts. Not ture. As far as the adjective "extensible" is concerned. It might be the back door left open for various hacks, though. I can still remember the crazy days when a colleague and I developed a whole replication system based on this. > Until we take the time to write, > issue, develop responses for, vote on responses to an RFP for GIOP > 2.0, > we aren't going to get anything much than this. I find no compeling reason to write a exception "reason" service context into the spec. > The only other choice would be to extend the format of system exceptions > in GIOP 1.3 to add a reason string. That's not even a choice. IIOP loses its worth when it becomes language or os dependent. Minor codes are sufficient, when properly used. Note that it's not always possible to provide, even in Java, a stack trace of "actual" reason that a CORBA exception was raised. CORBA exceptions can be raised in non-exceptional Java cases. And for the other cases, even if that stack trace is provided, it does not guarantee any usefulness to the application programmer. The ORB developer has technology of his/her own to deal with the situation. So, I don't see any use to this. > The advantage of using the service context is that it can be used even > with GIOP 1.0. If you'd like to use your own service context through your own interceptor provider, by all means!!! Max Sender: jon@corvette.floorboard.com Message-ID: <38D9C925.54DF81EB@floorboard.com> Date: Wed, 22 Mar 2000 23:35:01 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: "M. Mortazavi" , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: "T,!!-dI!!jRn!!0MW!! Michi Henning wrote: > Arguments about the Java to IDL mapping being incomplete don't count > to me > either. First, I'd have to ask why a Java to IDL mapping was > designed and > approved that didn't take this issue into account from day > one. Second, > I'd have to ask why the feature wasn't addressed the way it should > have been, > that is, either as a language specific issue (which is > architecturally > clean) or as an IDL issue by adding the string to system exceptions > (which > would be clean too). Michi, you know how much work it is to get a language mapping complete and right. The C++ mapping, which is certainly the most mature one, is still incomplete in a few areas, given that there are still outstanding issues. People miss needed features the first time around all the time--witness the number of RTFs still going on. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@corvette.floorboard.com Message-ID: <38D9CBE2.E641DBBC@floorboard.com> Date: Wed, 22 Mar 2000 23:46:42 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey Mischkinsky CC: Michi Henning , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <200003230636.WAA20918@wheel.dcn.davis.ca.us> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 0lJe9L9;!!JS)!![Ldd9 Jeffrey Mischkinsky wrote: > Not true, the set of valid service context id's is part of the > definition > of a particular version of giop. ORBs that implement verision n.m > can only > be expected to understand service contexts that were defined for > versions > n.m and below. The requirements in 13.6.7 for recognizing and processing service context ids is going to need to be reworked in the face of portable interceptors anyway. Right now, it allows ORB implementations to reject non-OMG service contexts. It is impossible to do this and still allow a meaningful implementation of interceptors. This requirement should be change to simply say that a service context id not recognized by the ORB or an interceptor should simply cause the context to be ignored (or passed through for a bridge.) > > ALL of the other service contexts are simply using GIOP as a transport > > mechanism, this proposed one as well. > > And they may or may not modify the meaning and interpretation of the GIOP > message, depending upon the semantics of the data they carry.. They may modify the meaning of the data, but generally not the actual operation of the GIOP protocol itself. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 23 Mar 2000 09:14:36 +1000 (EST) From: Michi Henning To: Simon Nash cc: Jonathan Biggar , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: <38D8DA3F.7C2CF0D2@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: US?e9^80!!jM4!!&X"!! On Wed, 22 Mar 2000, Simon Nash wrote: > Michi, > It is unfortunate that the original designers of CORBA system > exceptions did > not allow for the possibility of sending textual diagnostic > information as well > as the completion status and numeric minor code. But given that > 1. they did not > 2. their decision is hard coded into every ORB on the planet > 3. the only way to add textual information is via a service context > 4. real users of CORBA feel this is a serious issue > > I think you should be willing to consider the merits of this > proposal. I have considered the merits of this proposal and I am of the opinion that the merits don't outweigh the disadvantages: - There is no way to localize the returned string, which makes it highly doubtful as to whether it should be returned at all, given that CORBA is supposed to be suitable across different locales. - Adding language-specific things to the protocol level breaks abstraction and layering in a big way and is architecturally wrong. - The minor code was added to system exceptions precisely so that more detail about the reason for the exception could be communicated. - Adding the service context for the reason string breaks language transparency because, presumably, only Java servers will produce that string. If a Java client talks to a Smalltalk server, presumably the string won't be present. In turn, this means that the client cannot rely on the string being present anyway. Instead of hacking around with transmission of data via Java-specific service contexts, I would suggest to use the minor code in exceptions for what it was meant to be used for, namely, to provide a more precise indication of the reason for the exception. This avoids the hackery at the protocol level, solves the localization problem, and doesn't break language transparency. > The > continued success of CORBA depends on meeting reasonable user > requirements > and in the Java world (at least) the inability to pass the detail > string is > perceived as a usability defect. The continued success of CORBA depends on keeping the platform and protocols language independent. > We can "just say No" and turn all such user requests down on the grounds of > architectural purity but this would (IMO) be a self-defeating philosophy. I guess that makes me a purist then. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 23 Mar 2000 09:19:30 +1000 (EST) From: Michi Henning To: Peter Walker cc: butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: <38D943A0.3764174C@eng.Sun.COM> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: jA/e9UR6!!M*/!!D<&e9 On Wed, 22 Mar 2000, Peter Walker wrote: > Michi Henning wrote: > > > > I will continue to refuse to add > > language-specific hacks to the protocol level, just as I will > refuse to > > add language-specific things to IDL. > > > > Michi, > > We already did this with a bunch of types from the COBOL world and > where > did the "look and feel" of IDL come from in the first place? What hacks are currently in the protocol for COBOL types? The look and feel clearly came from the C/C++ world. Tough. That's the look and feel we have. If you don't like that, don't use CORBA. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 23 Mar 2000 09:20:52 +1000 (EST) From: Michi Henning To: Simon Nash cc: Paul Kyzivat , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: <38D8DE8F.44DC933B@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Wd~!!PIMe9NZhd9K^Je9 On Wed, 22 Mar 2000, Simon Nash wrote: > Paul, > I still need more convincing. > > In the worst case, the string will not be intelligible to the > receiver, > which leaves the receiver no worse off than the current situation > (who > still has minor code and completion status information). > > Also, Java exception detail strings are not localized, so if the > service > context is intended for this purpose then the lack of localization > is not > an issue. (The reason for this is that these strings are not > messages > intended for end users but diagnostic information used in problem > determination.) So, use the minor code and translate that at the receiving end into a messsage. No need to transmit a string at all. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 23 Mar 2000 09:30:21 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BD32@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 384e9"_cd9H1Sd9g<[d9 On Wed, 22 Mar 2000, Paul Kyzivat wrote: > On the other hand, features that only work when the two ends are both Java > seriously break CORBA language independence, and should be discouraged. > (Those who believe the only language is Java will disagree.) So a better > solution would be to agree that a string is a useful component of > SystemException, and then add that feature in a way that makes sense in a > language independent way. I could live with that, if we are prepared to rev GIOP for it, and figure out how we avoid breaking existing marshaling code with that change. But, even assuming that we can sort this out, I am still doubtful about the utility of sending a string that can't be localized. We could, of course, simply agree that the string is always in ASCII, using English. However, that then is only marginally better than using more precise minor codes, so it begs the question whether all the minor improvement is worth all the disruption. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 22 Mar 2000 23:28:33 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <9B164B713EE9D211B6DC0090273CEEA926BD32@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: j9f!!U~&!!,]+!!bVbd9 Paul, At first sight your second and third paragraphs appear to be contradictory :-) I have no strong opinion on whether it should just be for Java or for other languages as well. The requirement came from Java since the Java language includes a detail string in all exceptions. Other languages don't do this. This seems to suggest that it might be reasonable to make CORBA's Java mapping sync up with the Java language as well as possible. But I could happily go with a more general solution if consensus on this is achievable. This isn't only needed for RMI over IIOP. Even in the IDL to Java world a CORBA system exception like NO_IMPLEMENT can be constructed as a Java exception object with a detail message, which is lost when it is marshaled on the wire. If making CORBA cross-language means taking the lowest common denominator so that only those things that exist in all languages (or none) can be part of the protocol, then I think we're failing to understand and respond to our customers' needs. If something like this makes things work better in the Java to Java case and no worse (at least) in all the other combinations, then I don't understand why we would reject it. I'll get off my soap box now. Simon Paul Kyzivat wrote: > > If this is defined as a Java specific thing, then following Jishnu's > logic, > I don't have any major objection. > > If this is abstracted as a general feature then I object. > > On the other hand, features that only work when the two ends are > both Java > seriously break CORBA language independence, and should be > discouraged. > (Those who believe the only language is Java will disagree.) So a > better > solution would be to agree that a string is a useful component of > SystemException, and then add that feature in a way that makes sense > in a > language independent way. > > Paul > > > -----Original Message----- > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > Sent: Wednesday, March 22, 2000 9:54 AM > > To: Paul Kyzivat > > Cc: interop@omg.org; java-rtf@omg.org > > Subject: Re: Transferring Java exception reason string across the > wire > > > > > > Paul, > > I still need more convincing. > > > > In the worst case, the string will not be intelligible to the > > receiver, > > which leaves the receiver no worse off than the current situation > (who > > still has minor code and completion status information). > > > > Also, Java exception detail strings are not localized, so if > > the service > > context is intended for this purpose then the lack of > > localization is not > > an issue. (The reason for this is that these strings are not > messages > > intended for end users but diagnostic information used in problem > > determination.) > > > > If the ability to pass localized exception information strings is > also > > needed, then we should add exchange of locale information to > > the existing > > exchange of codeset information (in the next GIOP revision). > > > > Simon > > > > Paul Kyzivat wrote: > > > > > > OK. Michi has convinced me that it isn't reasonable. > > > > > > Paul -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Wed, 22 Mar 2000 23:35:02 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <9B164B713EE9D211B6DC0090273CEEA926BD34@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: FI'!!O:9e9Kd2e99jm!! Paul, I believe we have to be responsive to reasonable requests made by our users. Of course I would like to do them all in an architecturally pure way as far as possible. But if it's a choice between doing something a little less pure and turning down a reasonable user request for no reason that the users can understand, I'd rather have a better (in the functional sense) product and delighted customers. Simon Paul Kyzivat wrote: > > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > > We can "just say No" and turn all such user requests down on > > the grounds of architectural purity but this would (IMO) > > be a self-defeating philosophy. > > > > Simon > > Simon, you are one of the last people I would expect to get such an > argument > from! > > But I will be even more surprised if I hear that from Bill J :-) -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Thu, 23 Mar 2000 09:45:05 +1000 (EST) From: Michi Henning To: Simon Nash cc: Matthew Newhook , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: <38D94DDA.FC48F28F@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: \ > Mmmm... isn't SystemException a struct which isn't extensible? ;) > > > In Java, it's a non-final abstract class. But this is getting > somewhat away > from the main point. This issue is not about redoing CORBA > exceptions. > We debated that one recently and the decision was clear-cut. I > think > Russell's point is that given that we decided not to redesign the > CORBA > exception model, the only way we can we can satisfy user requests > like this > is to use some kind of "bolt on" approach. We can also choose to not satisfy the user request. Users ask for all sorts of impossible things all the time, including solutions to the halting problem. I have no problem with saying no if that makes sense architecturally. In this case, I think it does not make sense. > And I don't see why this is worse than all the other existing uses of > service contexts. I think I've enumerated the disadvantages in previous e-mails, so I won't repeat myself. > Whatever your opinion on whether this is a hack, it is not accurate to claim > that it damages interoperability. ORBs that do not recognize the service > context would just ignore it. Interoperability at the current level of > functionality (losing the Java detail string) is unaffected by this change. So, what's the use of a feature that the client cannot rely on being present anyway? Let's face it: CORBA is, to some extent, about using the lowest common denominator: we don't have exception inheritance; we don't have multiple inheritance if more than one base interface uses the same operation name; we don't have pointers; we don't have templates... All of these are supported by C++, yet, I can't use them if I use CORBA with C++. I can live with that, even though our users keep asking for exception inheritance or ambiguous multiple inheritance. Does this mean that I rush and hack it into CORBA? No. It means that I tell my users that they can't have it. I seriously cannot accept that the user requirement is of such importance that it warrants adding a "feature" in a way that does serious damage to the architecture. Tell your users no and they will learn to live with the limitation. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 23 Mar 2000 09:54:48 +1000 (EST) From: Michi Henning To: Bill Binko cc: "'Simon Nash'" , "'Jonathan Biggar'" , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: pUNd9p-Od9$L7!!B`"!! On Wed, 22 Mar 2000, Bill Binko wrote: > I don't think it would be a bad idea to define a standard service context > that held this type of diagnostic information. Much like the old 'errno" of > C, there is no guarantee that the callee will set this correctly, but it > doesn't hurt to check. With PI allowing us to place service contexts easily > on the reply, and read them easily, I don't see why making an _optional_ > _standard_ service context for this type of data would be quite the hack > Michi says. > > Now. Requiring ORBs to populate the service context is another matter. And > even _requiring_ them through the Java language mapping to check for them > could be objectionable. However, I think the proposal has merit if people > would quit stating it in a Java-only way. If Java vendors agree among > themselve to populate it, that's great. I would like to hear a compelling argument for why a string is better than a minor code. I would also like to hear a compelling argument for how we could ensure that: - the minor code and the string don't disagree with each other - developers know whether to look at the minor code or the string In addition, I would like to know why a string would be preferred over a minor code when I can react programmatically to a minor code for error handling, but I can't react programmatically to a string for error handling. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: Peter.Walker@eng.sun.com Message-ID: <38D95F01.9B880144@eng.Sun.COM> Date: Wed, 22 Mar 2000 16:02:09 -0800 From: Peter Walker Organization: Sun Microsystems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: YO4!!j@7e9Xnk!!%AC!! Michi Henning wrote: > > The look and feel clearly came from the C/C++ world. Tough. That's > the look > and feel we have. If you don't like that, don't use CORBA. > ;-) Darn I can't get an emoticon to fit the mood :-) Pj. From: Paul Kyzivat To: interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Wed, 22 Mar 2000 19:23:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: <8ld9"TO!!I>D!!`7g!! > From: Simon Nash [mailto:nash@hursley.ibm.com] > Paul, > I believe we have to be responsive to reasonable requests > made by our users. > Of course I would like to do them all in an architecturally > pure way as far > as possible. But if it's a choice between doing something a > little less pure > and turning down a reasonable user request for no reason that > the users can > understand, I'd rather have a better (in the functional > sense) product and > delighted customers. OK, but I would please ask you to remember that when others have their own pragmatic concerns. Paul From: Bill Binko To: "'Michi Henning'" , Bill Binko Cc: "'Simon Nash'" , "'Jonathan Biggar'" , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Wed, 22 Mar 2000 19:20:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: na]d9KT#!!^~/!!F#2e9 Michi Henning wrote: >On Wed, 22 Mar 2000, Bill Binko wrote: > >> I don't think it would be a bad idea to define a standard >service context >> that held this type of diagnostic information. Much like >the old 'errno" of >> C, there is no guarantee that the callee will set this >correctly, but it >> doesn't hurt to check. With PI allowing us to place service >contexts easily >> on the reply, and read them easily, I don't see why making >an _optional_ >> _standard_ service context for this type of data would be >quite the hack >> Michi says. >> >> Now. Requiring ORBs to populate the service context is >another matter. And >> even _requiring_ them through the Java language mapping to >check for them >> could be objectionable. However, I think the proposal has >merit if people >> would quit stating it in a Java-only way. If Java vendors >agree among >> themselve to populate it, that's great. > >I would like to hear a compelling argument for why a string is better >than a minor code. Michi, I don't think it's better, it is different. Consider the following non-Java scenario for a second: I have a COBOL server that is consistently throwing an exception. Regardless of the language my client is in (let's make it C++ for argument's sake), the minor code is not giving me enough information to track down the issue. However, I have an interceptor that I can install on the server whose job is to gather as much additional information as possible when its send_exception() method is called. This information includes the memory usage, io stats, load, database connection status, and any other internal information that I can gather. I put that information in a standard service context (we can argue about its format later) and fire off the reply. This is valuable because the additional information is not something that can be predicted by a standards body. It is flexible enough that I can modify the information put in that context if I need to. It is also for _human_ interrogation at the client: not just some big switch statement. I think this is the dilemma the Java people are in: they HAVE that additional information -- the reason text/stack trace. They need it because (more often than not), they have received a CORBA::UNKNOWN exception due to a Java exception such as a NullPointerException. However, CORBA doesn't give them a mechansim to get this information over the wire. >I would also like to hear a compelling argument for >how we could ensure that: > > - the minor code and the string don't disagree with each other > You can't: they are intended for different things: one for machines, one for people. > - developers know whether to look at the minor code or >the string > Again, the string is there for when the minor code is inadequate. >In addition, I would like to know why a string would be >preferred over a >minor code when I can react programmatically to a minor code for error >handling, but I can't react programmatically to a string for >error handling. See above. Binko From: Paul Kyzivat To: interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Wed, 22 Mar 2000 19:30:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: C:Be9DiB!!G$pd9S7R!! The point that I was trying to make is I can better accept the hack if it is only a hack for Java. The limitations about no localization, etc. are of less consequence in that case. If it is intended to make sense in all languages then we need to be much more specific about what it means, encoding, etc. so that interoperation between different language bindings makes sense. So in that case I can't accept the kludge and want to make a more "architecturally pure" change. Paul > -----Original Message----- > From: Simon Nash [mailto:nash@hursley.ibm.com] > Sent: Wednesday, March 22, 2000 6:29 PM > To: Paul Kyzivat > Cc: interop@omg.org; java-rtf@omg.org > Subject: Re: Transferring Java exception reason string across the > wire > > > Paul, > At first sight your second and third paragraphs appear to be > contradictory :-) > > I have no strong opinion on whether it should just be for Java or > for > other languages as well. The requirement came from Java > since the Java language > includes a detail string in all exceptions. Other languages > don't do this. > This seems to suggest that it might be reasonable to make > CORBA's Java mapping > sync up with the Java language as well as possible. But I > could happily go > with a more general solution if consensus on this is achievable. > > This isn't only needed for RMI over IIOP. Even in the IDL to > Java world a CORBA > system exception like NO_IMPLEMENT can be constructed as a > Java exception object > with a detail message, which is lost when it is marshaled on the > wire. > > If making CORBA cross-language means taking the lowest common > denominator so that > only those things that exist in all languages (or none) can > be part of the protocol, > then I think we're failing to understand and respond to our > customers' needs. > If something like this makes things work better in the Java > to Java case and no > worse (at least) in all the other combinations, then I don't > understand why we > would reject it. > > I'll get off my soap box now. > > Simon > > Paul Kyzivat wrote: > > > > If this is defined as a Java specific thing, then following > Jishnu's logic, > > I don't have any major objection. > > > > If this is abstracted as a general feature then I object. > > > > On the other hand, features that only work when the two > ends are both Java > > seriously break CORBA language independence, and should be > discouraged. > > (Those who believe the only language is Java will > disagree.) So a better > > solution would be to agree that a string is a useful component of > > SystemException, and then add that feature in a way that > makes sense in a > > language independent way. > > > > Paul > > > > > -----Original Message----- > > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > > Sent: Wednesday, March 22, 2000 9:54 AM > > > To: Paul Kyzivat > > > Cc: interop@omg.org; java-rtf@omg.org > > > Subject: Re: Transferring Java exception reason string > across the wire > > > > > > > > > Paul, > > > I still need more convincing. > > > > > > In the worst case, the string will not be intelligible to the > > > receiver, > > > which leaves the receiver no worse off than the current > situation (who > > > still has minor code and completion status information). > > > > > > Also, Java exception detail strings are not localized, so if > > > the service > > > context is intended for this purpose then the lack of > > > localization is not > > > an issue. (The reason for this is that these strings are > not messages > > > intended for end users but diagnostic information used in > problem > > > determination.) > > > > > > If the ability to pass localized exception information > strings is also > > > needed, then we should add exchange of locale information to > > > the existing > > > exchange of codeset information (in the next GIOP revision). > > > > > > Simon > > > > > > Paul Kyzivat wrote: > > > > > > > > OK. Michi has convinced me that it isn't reasonable. > > > > > > > > Paul > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > Date: Wed, 22 Mar 2000 16:32:38 -0800 (PST) From: Hemanth Puttaswamy Reply-To: Hemanth Puttaswamy Subject: Re: Transferring Java exception reason string across the wire To: interop@omg.org, java-rtf@omg.org Cc: rip-dev@eng.com MIME-Version: 1.0 Content-MD5: HIougmMYrHHN0RbKanF6Mg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: '+n!!`~He99<"e9^^gd9 Hi, Please pardon me for entering the discussion this late. I was reading the Java Idl spec ptc/99-03-09.pdf Section 28.4.8.1 which does talk about mapping Java runtime exceptions into System Exception. Isn't this what we are discussing about ? Thx, \Hemanth CORBA Technology Team Date: Thu, 23 Mar 2000 10:38:44 +1000 (EST) From: Michi Henning To: Simon Nash cc: Paul Kyzivat , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: <38D958A6.79195D41@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: El Paul, > I believe we have to be responsive to reasonable requests made by > our users. > Of course I would like to do them all in an architecturally pure way > as far > as possible. But if it's a choice between doing something a little > less pure > and turning down a reasonable user request for no reason that the > users can > understand, I'd rather have a better (in the functional sense) > product and > delighted customers. You keep assuming that request is reasonable. My assertion is that it is not. Your customers don't have to use CORBA, after all. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 22 Mar 2000 17:20:13 -0800 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <9B164B713EE9D211B6DC0090273CEEA926BD1D@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: G-8!!0h5e9-"*!!6b9e9 Paul - Paul Kyzivat wrote: > Sending the string as a service context seems like a reasonable idea. But > its value is directly proportional to how specific you are about what it > means. Saying you can put whatever you want into the string means that you > are telling the receiver he can get a string out but can't make any > particular interpretation of it. > > If you have a string in a Java system exception on the client side, and you > want to see *that* string associated with the corresponding exception on the > server side, then you had better say this service context carries *the* > optional string that may be associated with a system exception. > > Otherwise, you are going to get some very strange results when > interoperating with different orbs or different language bindings. Unless a whole new chapter of tha architecture defined a syntax for the exception reason "language" Would it define a native mapping for each language? The idea, as you seem to agree in your other e-mails, does not have any merit. Max > > > Paul > > > -----Original Message----- > > From: Vishy Kasar [mailto:vishy@inprise.com] > > Sent: Tuesday, March 21, 2000 5:35 PM > > To: butek@us.ibm.com > > Cc: interop@omg.org; issues@omg.org; java-rtf@omg.org > > Subject: Re: Transferring Java exception reason string across the wire > > > > > > > > This is a good idea and Visibroker is doing something similar > > already using vb > > specific service context. But I dont think we should be > > mandating that this > > should be 'reason string'. In java for example, we can send > > the whole server > > side stack trace using this string. This will be really useful to the > > customers. We can state that this service context contains a > > string and > > ORB vendors have freedom to put what they want in that string. Date: Wed, 22 Mar 2000 17:26:53 -0800 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: butek@us.ibm.com CC: Michi Henning , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <852568AA.004A9334.00@d54mta08.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: _*fd9Fg>!!77Vd9^GLe9 Russell - butek@us.ibm.com wrote: > Yes, this is a hack, but so is most of CORBA. > > The real problem is that exceptions are not first class objects. If they > were, the Java bindings could extend the base SystemException class to add > a reason string and that class could be sent across the wire. If the other > side isn't Java, then it would just see a SystemException and everything > would be peachy. > > We do not advocate that all bindings take advantage of this proposal. We > are merely talking about the Java bindings. As I noted earlier, it is not clear that this is even good for the Java binding. There are CORBA exceptions raised that need not have a Java exception anywhere in sight. If such CORBA exceptions are to be given a reason of their own, what's achieved that cannot be achieved with assigning a Minor code of their own. If not more can be achieved, Minor codes are sufficient. Max > In the Java world we are > losing a very useful bit of info that is available when a programmer > uses > normal rmi. Our customers are puzzled that this info isn't > available when > using rmi over iiop. > > We are already using a service context hack for Java - > UnknownExceptionInfo > - so this idea is certainly not new. > > Russell Butek > butek@us.ibm.com > > Michi Henning on 03/21/2000 05:40:19 PM > > To: Jonathan Biggar > cc: Russell Butek/Austin/IBM@IBMUS, interop@omg.org, > java-rtf@omg.org > Subject: Re: Transferring Java exception reason string across the > wire > > On Tue, 21 Mar 2000, Jonathan Biggar wrote: > > > butek@us.ibm.com wrote: > > > Our suggested solution is to create another service context for > a > system > > > exception reason string. When a system exception occurs, on a > Java > server, > > > the ORB places the reason string into this service context on > the reply > > > message. On a Java client, the ORB checks for and extracts this > string > and > > > uses it when creating the system exception instance which is > propagated > to > > > the application code. If the service context doesn't exist, the > Java > ORB > > > just does what it does today. Any other client bindings may > ignore > this > > > service context. > > > > > > > I like this idea a lot. Clients using other language bindings can > > install a portable interceptor to extract the string information > and > > make it available to the application code, perhaps through thread > > specific storage. This would also make it possible for other > language > > mappings, like C++, to add a reason string to exceptions in the > future > > and still maintain backwards compatibility with GIOP 1.2. > > I think that's about the most filthy hack I've come across in quite > some > time. We now have a data type that is partly sent in the reply and > partly > sent in the service context. Moreover, the data that is sent for the > type > is no longer derived from its IDL definition. Maybe if we think long > and > hard enough, we can find even more revolting abuses of the service > context? > For that matter, why don't we just give normal message formats a > miss > completely and transmit everything as an XML string inside the > service > context? :-( > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 22 Mar 2000 17:28:47 -0800 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: butek@us.ibm.com, Michi Henning , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <852568AA.004A9334.00@d54mta08.raleigh.ibm.com> <20000322132409.A26065@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: #4?!!VI3e98)8e9D_L!! Matthew - Matthew Newhook wrote: > Hi, > > On Wed, Mar 22, 2000 at 07:26:24AM -0600, butek@us.ibm.com wrote: > > Yes, this is a hack, but so is most of CORBA. > > It is? Please enumerate the set of nasty hacks that pollute most of CORBA. > > > The real problem is that exceptions are not first class objects. If they > > were, the Java bindings could extend the base SystemException class to add > > a reason string and that class could be sent across the wire. If the other > > side isn't Java, then it would just see a SystemException and everything > > would be peachy. > > Mmmm... isn't SystemException a struct which isn't extensible? ;) But the extensibility is not of much use in the way you're thinking of. An orb vendor can always do what they want, including such extensions, but it does non mean they'll be acceptable for inclusion in the spec. Max > > We do not advocate that all bindings take advantage of this proposal. We > > are merely talking about the Java bindings. In the Java world we are > > losing a very useful bit of info that is available when a programmer uses > > normal rmi. Our customers are puzzled that this info isn't available when > > using rmi over iiop. > > > > We are already using a service context hack for Java - UnknownExceptionInfo > > - so this idea is certainly not new. > > I think this is a total and abolutely disgusting hack. By using > ServiceContexts in this way we are inviting more an more hacks on top > of an already fragile system. Pretty soon interop will be totally out > the window. That is bad for CORBA, and bad for the vendors. > > > Russell Butek > > butek@us.ibm.com > > Regards, Matthew > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 22 Mar 2000 17:24:37 -0800 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: butek@us.ibm.com CC: interop@omg.org, issues@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <852568A9.006B2694.00@d54mta08.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: C9%e9Oi8e92$,e9WeO!! Russell - I don't see why this is necessary. I've been reading half of the messages so far and haven't found a good reason yet. Proper use of minor codes w/ each CORBA exception type assigned to each vendor should be sufficient. Vendors might want to provide some assistance for users to interpret these minor codes but the Exception reason, like the one in Java, is not always useful since it is possible for CORBA exceptions to be raised w/ no relevant Java exception in sight. If the service context proposed cannot be used for all CORBA exception types, then its usability is suspect. Stack trace can be passed in vendor specific contexts as well, and it is not always useful as I noted elsewhere. Writing this to a spec does not seem like a good idea bo me. Too much, and possibly redundant, information can be bad for one's health. Regards, Max butek@us.ibm.com wrote: > Although this is a Java-specific issue, I suspect it will have to be > decided in interop, therefore I'd like this to be an interop issue. > I've > cc'ed java-rtf since I'm sure they'll be interested. > > System exceptions only have: minor code, completion status. Java > exceptions all have a reason string as well. This is a potentially > significant bit of info that is not getting transferred across the > wire in > Java ORB implementations. Our rmi over iiop customers expect this > information. > > Our suggested solution is to create another service context for a > system > exception reason string. When a system exception occurs, on a Java > server, > the ORB places the reason string into this service context on the > reply > message. On a Java client, the ORB checks for and extracts this > string and > uses it when creating the system exception instance which is > propagated to > the application code. If the service context doesn't exist, the > Java ORB > just does what it does today. Any other client bindings may ignore > this > service context. > > Java bindings do not need to change for this proposal. > > To be more precise (sorta), we need three things: > 1. A new service context ID > > const ServiceId SystemExceptionReason = TBD; > > 2. The context data associated with this ID is a CDR encapsulation > of a > string. > 3. Some verbage somewhere describing this. > > Russell Butek > butek@us.ibm.com To: Paul Kyzivat cc: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: Your message of "Wed, 22 Mar 2000 14:20:47 PST." <9B164B713EE9D211B6DC0090273CEEA926BD34@bos1.noblenet.com> From: Bill Janssen Message-Id: <00Mar22.172915pst."3686"@watson.parc.xerox.com> Date: Wed, 22 Mar 2000 17:29:23 PST Content-Type: text X-UIDL: 1:ad9A=!!!6`2e9V@Le9 > But I will be even more surprised if I hear that from Bill J :-) It's amazing how often sticking to architectural purity makes the most usable specs! The problem in the OMG, of course, is that weaseling such as, ``well, it's just for Java'', is psychotic; that is, this excuse exists in a world of the utterer's imagining, not in the world of the OMG as it is. Over and over, we've seen that any specification precedent is seized upon later as a reason for doing tasteless things tastelessly; the original *reason* for the precedent's occurrence is never heard again. I'm with Michi on this one. Bill To: Bill Binko cc: "'Michi Henning'" , "'Simon Nash'" , "'Jonathan Biggar'" , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: Your message of "Wed, 22 Mar 2000 16:23:53 PST." From: Bill Janssen Message-Id: <00Mar22.173925pst."3686"@watson.parc.xerox.com> Date: Wed, 22 Mar 2000 17:39:43 PST Content-Type: text X-UIDL: ^;E!!;F`d9)%h!!&22!! Bill, I've heard this request a number of times from various quarters. My response has always been twofold: 1) If you throw a User exception, you can put anything you want in it (such as stack traces). If it's appropriate to send to the client, of course. 2) Debugging servers is an interesting art in and of itself. Typically, the debugging interface is not something that's well suited to sharing the channel a client may be using to call methods on the server. There are issues of domain knowledge, security, etc., that separate the client from the server. A well-engineered ORB should have debugging interfaces available for server maintenance that allow these un-track-down-able errors to be reported and analyzed -- without disturbing the clients, if possible. ILU, for instance, has the ability to ``log'' every system exception in an implementor-specified way. Bill Sender: jon@corvette.floorboard.com Message-ID: <38D97C67.81E93F07@floorboard.com> Date: Wed, 22 Mar 2000 18:07:35 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: "M. Mortazavi" CC: Jonathan Biggar <"jon"@jon@biggar.org>, Michi Henning , Jonathan Biggar , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <200003212352.PAA26486@corvette.floorboard.com> <38D970F6.957DC362@eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,f*e9;\[d9$38!!JE8!! "M. Mortazavi" wrote: > > The only other choice would be to extend the format of system exceptions > > in GIOP 1.3 to add a reason string. > > That's not even a choice. IIOP loses its worth when it becomes language or os > dependent. Minor codes are sufficient, when properly used. Note that it's not > always possible to provide, even in Java, a stack trace of "actual" reason that a > CORBA exception was raised. CORBA exceptions can be raised in non-exceptional > Java cases. And for the other cases, even if that stack trace is provided, it > does not guarantee any usefulness to the application programmer. The ORB > developer has technology of his/her own to deal with the situation. So, I don't > see any use to this. This is irrelevant, since the proposal does not make IIOP in any wah language dependent. It just happens to make IIOP work better for Java applications when JAVA is on both sides of the pipe. I just don't understand why some people are getting their knickers tied up in a knot over this one. The information to be transmitted in the proposed service context is a diagnostic, most likely debugging information. I don't see applications algorithmically depending on the contents of the string, and if you are worried about that, we can put a caution in the definition of the service context to that effect. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 22 Mar 2000 18:18:44 -0800 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bill Binko CC: "'Simon Nash'" , "'Jonathan Biggar'" , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Type: multipart/alternative; boundary="------------AA0879126909EE3C2F6CDA11" X-UIDL: 5Scd9]NL!!B%Vd9$I*!! Bill - Bill Binko wrote: My apologies.. I took the phrase "concatenated to the id" to mean modification of the id (which is marshalled with the Exception). -- My Bad That being said, I have a suggestion to make on this subject. Flame away, but it may make Michi feel better. I think that _in_general_ and in _most_ languages, there can be a need for diagnostic information after a call has completed. This is true regardless of the outcome (reply or exception in our case) and has nothing to do with the language being used. I don't think it would be a bad idea to define a standard service context that held this type of diagnostic information. Much like the old 'errno" of C, there is no guarantee that the callee will set this correctly, but it doesn't hurt to check. With PI allowing us to place service contexts easily on the reply, and read them easily, I don't see why making an _optional_ _standard_ service context for this type of data would be quite the hack Michi says. Now. Requiring ORBs to populate the service context is another matter. And even _requiring_ them through the Java language mapping to check for them could be objectionable. However, I think the proposal has merit if people would quit stating it in a Java-only way. If Java vendors agree among themselve to populate it, that's great. Thanks for stating this important fact. It has nothing to do with Java. As a Java fanatic, if there ever was such a thing, I couldn't agree more that it has nothing to do with Java. We can blame Russell for having provided ammunition for the anti-Java sentiment. (Can we?) Still, I don't think it is a terribly good idea as I do not find any real usefulness for it within or without Java. If a Java or C++ or .... or ... ORB (system or application) programmer/expert could convince me otherwise, I'll have second thought. (Note that the "or"s are not exclusive.) I believe that carrying of dubious "reasons" across the wire is a case where too much, unnecessary and redundant information can cause a terrible confusion, both for the programmer, and even more, for the system developer, and I also believe that to get it right and well (if we ever earned such an unappealing solution) we'll need more than simply a service context. Information encoded in the string should be minimally meaningful across systems. It cannot find meaning without a proper, however minimal, syntax or semantics. In place of that syntax and semantics, minor codes can be used for particular orbs to provide useful information. Furthermore, as one moves from ORB to ORB, the reason loses more of its meaning and usefulness if it has its roots in the system code. If we plan to through in reason that might turn into gibberish and a meaningless mount of nonsense on the other side, how could it make things any more reason-ful? Max Binko > -----Original Message----- > From: Simon Nash [mailto:nash@hursley.ibm.com] > Sent: Wednesday, March 22, 2000 9:17 AM > To: Bill Binko > Cc: 'Jonathan Biggar'; butek@us.ibm.com; interop@omg.org; > java-rtf@omg.org > Subject: Re: Transferring Java exception reason string across the > wire > > > Bill, > Russell's proposal is for system exceptions, not user exceptions. > > The Java mapping for user exceptions includes a constructor > that allows > a detail string to be appended, as you say. However, this > string is not > sent on the wire and therefore cannot cause any receiver to > barf. It is > a purely local information-only user diagnostic aid and does > not modify > the id of the exception, since the detail string is derived > from the id > of the exception, not vice versa. > > Simon > > Bill Binko wrote: > > > > I agree that the Service Context is a better idea. > However, we have an > > additional concern that this may address. In the Java > Mapping (99-7-53 is > > the latest official one I think) section 1.15.1 "User > Defined Exceptions", > > there is the following text: > > > > The Java generated exception class has an additional > "full" constructor > > which has an > > additional initial string reason parameter which is > concatenated to the > > id before > > calling the base UserException constructor. > > > > This seems to be a way of sending the user text of User > Exceptions over the > > wire as well. The problem is that this modifies the 'id' > which is supposed > > to be the repository ID of the Exception type. Existing > systems which rely > > on this being the case will barf when the see an appended > reason text. > > > > I would bet that this wasn't done in ignorance, but was > discussed first. > > Could someone please point me to the issue # where this > change was made or > > post the rationale for this? > > > > It seems that Russell's Service Context could solve this > problem as well. > > > > Thanks > > Binko > > > > > -----Original Message----- > > > From: Jonathan Biggar [mailto:"jon"%jon@biggar.org] > > > Sent: Tuesday, March 21, 2000 3:32 PM > > > To: butek@us.ibm.com > > > Cc: interop@omg.org; java-rtf@omg.org > > > Subject: Re: Transferring Java exception reason string > across the wire > > > > > > > > > butek@us.ibm.com wrote: > > > > > > > > Although this is a Java-specific issue, I suspect it > will have to be > > > > decided in interop, therefore I'd like this to be an > > > interop issue. I've > > > > cc'ed java-rtf since I'm sure they'll be interested. > > > > > > > > System exceptions only have: minor code, completion > status. Java > > > > exceptions all have a reason string as well. This is a > potentially > > > > significant bit of info that is not getting transferred > > > across the wire in > > > > Java ORB implementations. Our rmi over iiop customers > expect this > > > > information. > > > > > > > > Our suggested solution is to create another service context > > > for a system > > > > exception reason string. When a system exception occurs, > > > on a Java server, > > > > the ORB places the reason string into this service context > > > on the reply > > > > message. On a Java client, the ORB checks for and extracts > > > this string and > > > > uses it when creating the system exception instance which > > > is propagated to > > > > the application code. If the service context doesn't > > > exist, the Java ORB > > > > just does what it does today. Any other client bindings > > > may ignore this > > > > service context. > > > > > > > > Java bindings do not need to change for this proposal. > > > > > > > > To be more precise (sorta), we need three things: > > > > 1. A new service context ID > > > > > > > > const ServiceId SystemExceptionReason = TBD; > > > > > > > > 2. The context data associated with this ID is a CDR > > > encapsulation of a > > > > string. > > > > 3. Some verbage somewhere describing this. > > > > > > I like this idea a lot. Clients using other language bindings > can > > > install a portable interceptor to extract the string > information and > > > make it available to the application code, perhaps through > thread > > > specific storage. This would also make it possible for > other language > > > mappings, like C++, to add a reason string to exceptions > in the future > > > and still maintain backwards compatibility with GIOP 1.2. > > > > > > -- > > > Jon Biggar > > > Floorboard Software > > > jon@floorboard.com > > > jon@biggar.org > > > > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > Date: Thu, 23 Mar 2000 12:18:21 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: <38D97C67.81E93F07@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: BJ"!!pEOe9nbcd9l/;!! On Wed, 22 Mar 2000, Jonathan Biggar wrote: > This is irrelevant, since the proposal does not make IIOP in any wah > language dependent. It just happens to make IIOP work better for > Java > applications when JAVA is on both sides of the pipe. > > I just don't understand why some people are getting their knickers > tied > up in a knot over this one. The information to be transmitted in > the > proposed service context is a diagnostic, most likely debugging > information. I don't see applications algorithmically depending on > the > contents of the string, and if you are worried about that, we can > put a > caution in the definition of the service context to that effect. What use is the diagnostic on the client side? The client doesn't even know where the server is, or in what language it's implemented. It would make a lot more sense for the server to log this info instead of returning it to the client. In addition, if it's OK to add extra optional stuff to the service context, then I assume that it would be OK to do that for C++, and COBOL, and SmallTalk, and C, and Ada too? If so, I don't think it would take me long to think up about half a dozen things that I think might be useful for C++ implementations. Shall I really go and raise all of these as issues so we can debate them at our leasure? And, of course, I will be stridently insisting on adoption of these C++-specific features. After all, what is fair for Java is fair for C++... And, I'm sure, I can think of a few more for COBOL too. I think it's about time that we added lots of optional tags to the service context for all those COBOL servers out there... :-( Needless to say, in the absence of stronger arguments as to why this change is necessary, I will continue to oppose it. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 22 Mar 2000 18:33:10 -0800 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Simon Nash , Jonathan Biggar , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 1=-e93Y?!!U!p!!@??!! Michi - Michi Henning wrote: > On Wed, 22 Mar 2000, Simon Nash wrote: > > > Michi, > > It is unfortunate that the original designers of CORBA system exceptions did > > not allow for the possibility of sending textual diagnostic information as well > > as the completion status and numeric minor code. But given that > > 1. they did not > > 2. their decision is hard coded into every ORB on the planet > > 3. the only way to add textual information is via a service context > > 4. real users of CORBA feel this is a serious issue > > > > I think you should be willing to consider the merits of this proposal. > > I have considered the merits of this proposal and I am of the opinion that > the merits don't outweigh the disadvantages: > > - There is no way to localize the returned string, which makes > it highly doubtful as to whether it should be returned at all, > given that CORBA is supposed to be suitable across different > locales. > > - Adding language-specific things to the protocol level breaks > abstraction and layering in a big way and is architecturally > wrong. > > - The minor code was added to system exceptions precisely so that > more detail about the reason for the exception could be > communicated. My previous postings echoes your reasoning here. > > > - Adding the service context for the reason string breaks > language transparency because, presumably, only Java servers > will produce that string. This is not a Java issue. Many CORBA exceptions might have no Java exception in their "view" or as their cause, and yet some system programmers might like to have the versatility to tell their inquiring users why their ORB is throwing the CORBA exception it has thrown. If the proposal has merit, it will have merit for all languages. And if it does not, it will most probably not for all languages. > If a Java client talks to a Smalltalk > server, presumably the string won't be present. In turn, > this > means that the client cannot rely on the string being > present > anyway. > > Instead of hacking around with transmission of data via > Java-specific service > contexts, Again, this is not a Java vs. other languages issue. > I would suggest to use the minor code in exceptions for what > it was meant to be used for, namely, to provide a more precise > indication > of the reason for the exception. This avoids the hackery at the > protocol > level, solves the localization problem, and doesn't break language > transparency. What are the objections to this approach? > > The > > continued success of CORBA depends on meeting reasonable user > requirements > > and in the Java world (at least) the inability to pass the detail > string is > > perceived as a usability defect. > > The continued success of CORBA depends on keeping the platform and > protocols > language independent. Will it be necessary to provide users more than the Minor code? Do ORB vendors provide tools to convert their Minor Codes to something more useful for the user? Regards, Max > > We can "just say No" and turn all such user requests down on the grounds of > > architectural purity but this would (IMO) be a self-defeating philosophy. > > I guess that makes me a purist then. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 23 Mar 2000 12:41:17 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: <38D98125.D3755A33@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: eDdd9[5Y!! > Needless to say, in the absence of stronger arguments as to why this change > > is necessary, I will continue to oppose it. > > The argument for the change is simple: to allow Java programs that used > RMI to use IIOP transparently. This is a quite reasonable request, and > given that anyone who doesn't implement a Java ORB can completely forget > that the service context even exists, the request has extremely minimal > impact. > > I really think you are erring towards pedagogy here. No, I don't think so. I am watching the service context being abused to pile more and more things into the platform in a way subverts (perverts?) GIOP itself. The suggestion that is being made means to marshal an exception in conflict with its IDL definition. In other words, the data being marshaled is no longer in agreement with the IDL definition of a type. That in itself raises serious concerns. Second, the change is being proposed to make things easier for only one specific language, and is being proposed at a level that is supposedly language independent. That raises more concerns. Finally, I have yet to hear someone explain to me why minor codes are insufficient. In particular, I don't see why the minor code couldn't be translated into the reason string on the receiving end, so the entire issue would go back where it belongs, namely, in the domain of the Java language mapping. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@corvette.floorboard.com Message-ID: <38D98125.D3755A33@floorboard.com> Date: Wed, 22 Mar 2000 18:27:49 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: hZ$!!GpL!!Z;I!!VpMd9 Michi Henning wrote: > > This is irrelevant, since the proposal does not make IIOP in any > wah > > language dependent. It just happens to make IIOP work better for > Java > > applications when JAVA is on both sides of the pipe. > > > > I just don't understand why some people are getting their knickers > tied > > up in a knot over this one. The information to be transmitted in > the > > proposed service context is a diagnostic, most likely debugging > > information. I don't see applications algorithmically depending > on the > > contents of the string, and if you are worried about that, we can > put a > > caution in the definition of the service context to that effect. > > What use is the diagnostic on the client side? The client doesn't > even > know where the server is, or in what language it's implemented. > It would make a lot more sense for the server to log this info > instead > of returning it to the client. > > In addition, if it's OK to add extra optional stuff to the service > context, > then I assume that it would be OK to do that for C++, and COBOL, and > SmallTalk, and C, and Ada too? If so, I don't think it would take me > long > to think up about half a dozen things that I think might be useful > for > C++ implementations. > > Shall I really go and raise all of these as issues so we can debate > them at our leasure? > > And, of course, I will be stridently insisting on adoption of these > C++-specific features. After all, what is fair for Java is fair for > C++... > > And, I'm sure, I can think of a few more for COBOL too. I think it's > about > time that we added lots of optional tags to the service context for > all > those COBOL servers out there... :-( > > Needless to say, in the absence of stronger arguments as to why this > change > is necessary, I will continue to oppose it. The argument for the change is simple: to allow Java programs that used RMI to use IIOP transparently. This is a quite reasonable request, and given that anyone who doesn't implement a Java ORB can completely forget that the service context even exists, the request has extremely minimal impact. I really think you are erring towards pedagogy here. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Bill Binko To: "'Bill Janssen'" , Bill Binko Cc: "'Michi Henning'" , "'Simon Nash'" , "'Jonathan Biggar'" , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Wed, 22 Mar 2000 21:48:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: K4Je9/n&!!=V8!!#TBe9 Bill J wrote: > > >Bill, > >I've heard this request a number of times from various quarters. My >response has always been twofold: > >1) If you throw a User exception, you can put anything you want in it >(such as stack traces). If it's appropriate to send to the client, of >course. > >2) Debugging servers is an interesting art in and of itself. >Typically, the debugging interface is not something that's well suited >to sharing the channel a client may be using to call methods on the >server. There are issues of domain knowledge, security, etc., that >separate the client from the server. A well-engineered ORB should >have debugging interfaces available for server maintenance that allow >these un-track-down-able errors to be reported and analyzed -- without >disturbing the clients, if possible. ILU, for instance, has >the ability >to ``log'' every system exception in an implementor-specified way. > Bill, With the advent of Portable Interceptors, I'm not sure these arguments hold water. Yes, you can send anything you _forsee_ in a UserException. And yes, you can argue that this is a differentiating point for ORB as to how good their debugging support is. However, the scenario I pointed out to Michi is very real: there are times when additional information is needed and IDL interfaces etc. cannot be modified. I don't see a good reason for objecting to making that possible in a standard way (via a service context). I do think that those arguing from a Java-only point of view will lose this fight. I agree that to let a single language dictate the protocol is a lousy precedent to set. However, this seems to be something that can be "couched" in a way that is both language-neutral and useful to all concerned. However, I will make a prediction at this point: we will NOT have a standard context, and most of the Java vendors will get together and define one among themselves. It _will_ then be Java-only and will have all of the "bad things" that Michi hates (no Locale, lack of semantics, etc.). So I'd hope that the proponents of this please consider the approach I suggested: this IS something that can be made language neutral. It may NOT be something for an RTF. I don't know. I just think it is something that Java ORB vendors (particularly those running RMI over IIOP) will _need_. Can they do it in a proprietary manner? Yes. Can they agree among themselves to interoperate? Yes. I just don't want it to go that route: those of us who aren't big ORB vendors will have a closed standard to try to talk to. Binko Date: Wed, 22 Mar 2000 19:01:20 -0800 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: Jonathan Biggar <"jon"@jon@biggar.org>, Michi Henning , Jonathan Biggar , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <200003212352.PAA26486@corvette.floorboard.com> <38D970F6.957DC362@eng.sun.com> <38D97C67.81E93F07@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 8,Qe94>I!!,d_d9RS'e9 Jonathan - Jonathan Biggar wrote: > "M. Mortazavi" wrote: > > > > The only other choice would be to extend the format of system exceptions > > > in GIOP 1.3 to add a reason string. > > > > That's not even a choice. IIOP loses its worth when it becomes language or os > > dependent. Minor codes are sufficient, when properly used. Note that it's not > > always possible to provide, even in Java, a stack trace of "actual" reason that a > > CORBA exception was raised. CORBA exceptions can be raised in non-exceptional > > Java cases. You seem to have glossed over the point I made in the sentence above. "CORBA exceptions can be raised in non-exceptional Java cases. " Are we sure that all CORBA exceptions are raised when there's an exceptional Java situation. I'm not sure about that. If someone can prove that most of them are, then I'll start thinking about this in a different light. But then, I'll still have to be convinced why redundant information is to be provided according to a pre-specified manner. Furthermore, what's the use of specifying a way of passing this information if it cannot always be interpreted to the extent it promises to inform. The Minor Code mechanism already exists and can be used quite well to separate one class of exceptional cases from the next. Vendors can provide tools/tables/etc. to interpret their MinorCodes. > And for the other cases, even if that stack trace is provided, it > > does not guarantee any usefulness to the application > programmer. The ORB > > developer has technology of his/her own to deal with the > situation. So, I don't > > see any use to this. > > This is irrelevant, since the proposal does not make IIOP in any wah > language dependent. You're preaching to the Pope in this regard, and yes, it has nothing to do with language dependence but you don't seem to have taken a note of what I was saying. Please get out of the language dependence mode. Please see my note above. > It just happens to make IIOP work better for Java > applications when JAVA is on both sides of the pipe. I'm not sure about this. Couldn't any CORBA exceptions be raised during an excution with no Java exception (or other language entity) in "view" to provide a *textual* "reason" that cannot be provided in a Minor Code? > I just don't understand why some people are getting their knickers tied > up in a knot over this one. The information to be transmitted in the > proposed service context is a diagnostic, most likely debugging > information. If so, it can be a vendor specific service context. Right? Or are you debugging across ORBs? In other words, are you debugging ORB interoperability or application code? > I don't see applications algorithmically depending on the > contents of the string, and if you are worried about that, Absolutely. > we can put a > caution in the definition of the service context to that effect. A caution never worked with me. I'm *also* worried about interpretability and usefulness of any such *textual* information. I think, while satisfying some curious developers, it will certainly muddy the waters for them or others. Regards, Max Date: Thu, 23 Mar 2000 13:02:25 +1000 (EST) From: Michi Henning To: Bill Binko cc: "'Bill Janssen'" , "'Simon Nash'" , "'Jonathan Biggar'" , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: *5Je9-N5!!Fke!!`S`d9 On Wed, 22 Mar 2000, Bill Binko wrote: > I just think it is something > that Java ORB vendors (particularly those running RMI over IIOP) > will > _need_. Hmmm... Considering that the Java mapping and RMI over IIOP have been around for quite some time, I'm having problems accepting the supposed urgency of this change. After all, if it really is that pressing, then, by implication, Java and RMI/IIOP are unusable in their current state, no? I still keep hearing arguments that repeat that the reason string is incredibly important. I still don't hear arguments to explain why minor codes are insufficient, nor do I hear arguments to explain why this can't be dealt with as Java language mapping issue, by translating the minor code into a string at the receiving end. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@corvette.floorboard.com Message-ID: <38D9911E.570EC9B0@floorboard.com> Date: Wed, 22 Mar 2000 19:35:58 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Bill Binko CC: "'Bill Janssen'" , "'Michi Henning'" , "'Simon Nash'" , "'Jonathan Biggar'" , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: /4h!!:@ad9n-Zd9*mHe9 Bill Binko wrote: > However, I will make a prediction at this point: we will NOT > have a > standard context, and most of the Java vendors will get together and > define > one among themselves. It _will_ then be Java-only and will have all > of the > "bad things" that Michi hates (no Locale, lack of semantics, etc.). Speaking from a jursidictional point of view, if the Java RTF decides to go ahead with this proposal and allocate a service context, I don't think there is anything the Interop RTF can or should do about it. I don't see anywhere in the P&P that the Interop RTF gets a veto on all service context definitions, in particular since this particular proposal as absolutely ZERO impact on non-Java ORBs. > So I'd hope that the proponents of this please consider the approach > I suggested: this IS something that can be made language neutral. It may > NOT be something for an RTF. I don't know. I just think it is something > that Java ORB vendors (particularly those running RMI over IIOP) will > _need_. Can they do it in a proprietary manner? Yes. Can they agree among > themselves to interoperate? Yes. It certainly would look pretty stupid for the OMG to refuse to standardize this if the OMG Java sub-community wants it. In hindsight I think it will look very petty. It would not be wise to force a significant subset of the OMG community to have to start developing standards outside of the OMG aegis. > I just don't want it to go that route: those of us who aren't big > ORB vendors will have a closed standard to try to talk to. I'd like to see some language neutral proposal as well, but I wouldn't feel bad at all if it was only Java specific. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@corvette.floorboard.com Message-ID: <38D99376.DCA56FE2@floorboard.com> Date: Wed, 22 Mar 2000 19:45:58 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 'Hpd9%40!!7J#!!1aN!! Michi Henning wrote: > > I really think you are erring towards pedagogy here. > > No, I don't think so. I am watching the service context being abused > to pile more and more things into the platform in a way subverts > (perverts?) > GIOP itself. If an ORB vendor decided to do this exact proposal using a proprietary service context, what would it be to you? Why is it any different when it is more than one ORB vendor doing the same? > The suggestion that is being made means to marshal an exception in conflict > with its IDL definition. In other words, the data being marshaled is no > longer in agreement with the IDL definition of a type. I disagree. This proposal allows additional *optional* information to be passed. Since a receiver that has no knowledge of the service context can still unmarshal the exception, your claim that there is a conflict is simply not true. > That in itself > raises serious concerns. Second, the change is being proposed to > make > things easier for only one specific language, and is being proposed > at a level that is supposedly language independent. That raises more > concerns. This argument doesn't fly. With this argument, you must also reject the OTS service contexts because they put information into GIOP messages that only have to do with transactions and not all ORBs or applications use transactions. The GIOP service context is there *precisely* to carry things that are application, language, or service dependant, and are properly not part of the GIOP protocol. > Finally, I have yet to hear someone explain to me why minor codes are > insufficient. In particular, I don't see why the minor code couldn't be > translated into the reason string on the receiving end, so the entire > issue would go back where it belongs, namely, in the domain of the > Java language mapping. You are ignoring the original reason for the proposal. The Java to IDL mapping maps some Java exceptions (which have a reason string and NO minor code) to CORBA system exceptions. Without this added context, some information is thrown away and the Java to IDL mapping is less than complete. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 22 Mar 2000 20:10:07 -0800 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Paul Kyzivat , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <9B164B713EE9D211B6DC0090273CEEA926BD32@bos1.noblenet.com> <38D95721.FA716160@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ;(6!!5(D!!oC3!!$P>!! Simon - You have given a very good analysis of the language issue. Thanks for clearing the air to talk about substantive matters. If the argument can be further advanced that this is good for language X without making things worse for language Y, it certainly becomes less reasonable to resist Russell's original suggestion. If there was a standard way of passing the Java-language exception "reason" on the wire, it will certainly improve exception reporting among distinct Java orbs without taking a toll on interoperability or exception reporting among all other orb pairs. (For some reason, I had imagined some advocates finding it necessary for Java stack traces to be passed. That seemed like overkill and impossible to interpret properly accross the wire except for system programmers.) Factoring out all the language-chauvenism of one kind or another that I've seen in this thread of discussion, it is now becoming clear to me that it could be a *bad* idea for this not to be standardized. Regards, Max Simon Nash wrote: > Paul, > At first sight your second and third paragraphs appear to be > contradictory :-) > > I have no strong opinion on whether it should just be for Java or > for > other languages as well. The requirement came from Java since the > Java language > includes a detail string in all exceptions. Other languages don't > do this. > This seems to suggest that it might be reasonable to make CORBA's > Java mapping > sync up with the Java language as well as possible. But I could > happily go > with a more general solution if consensus on this is achievable. > > This isn't only needed for RMI over IIOP. Even in the IDL to Java > world a CORBA > system exception like NO_IMPLEMENT can be constructed as a Java > exception object > with a detail message, which is lost when it is marshaled on the > wire. > > If making CORBA cross-language means taking the lowest common > denominator so that > only those things that exist in all languages (or none) can be part > of the protocol, > then I think we're failing to understand and respond to our > customers' needs. > If something like this makes things work better in the Java to Java > case and no > worse (at least) in all the other combinations, then I don't > understand why we > would reject it. > > I'll get off my soap box now. > > Simon > > Paul Kyzivat wrote: > > > > If this is defined as a Java specific thing, then following > Jishnu's logic, > > I don't have any major objection. > > > > If this is abstracted as a general feature then I object. > > > > On the other hand, features that only work when the two ends are > both Java > > seriously break CORBA language independence, and should be > discouraged. > > (Those who believe the only language is Java will disagree.) So a > better > > solution would be to agree that a string is a useful component of > > SystemException, and then add that feature in a way that makes > sense in a > > language independent way. > > > > Paul > > > > > -----Original Message----- > > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > > Sent: Wednesday, March 22, 2000 9:54 AM > > > To: Paul Kyzivat > > > Cc: interop@omg.org; java-rtf@omg.org > > > Subject: Re: Transferring Java exception reason string across > the wire > > > > > > > > > Paul, > > > I still need more convincing. > > > > > > In the worst case, the string will not be intelligible to the > > > receiver, > > > which leaves the receiver no worse off than the current > situation (who > > > still has minor code and completion status information). > > > > > > Also, Java exception detail strings are not localized, so if > > > the service > > > context is intended for this purpose then the lack of > > > localization is not > > > an issue. (The reason for this is that these strings are not > messages > > > intended for end users but diagnostic information used in > problem > > > determination.) > > > > > > If the ability to pass localized exception information strings > is also > > > needed, then we should add exchange of locale information to > > > the existing > > > exchange of codeset information (in the next GIOP revision). > > > > > > Simon > > > > > > Paul Kyzivat wrote: > > > > > > > > OK. Michi has convinced me that it isn't reasonable. > > > > > > > > Paul > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Thu, 23 Mar 2000 14:04:10 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: <38D99376.DCA56FE2@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: >%G!!FG;!!+ak!!Jh,!! On Wed, 22 Mar 2000, Jonathan Biggar wrote: > > No, I don't think so. I am watching the service context being abused > > to pile more and more things into the platform in a way subverts (perverts?) > > GIOP itself. > > If an ORB vendor decided to do this exact proposal using a proprietary > service context, what would it be to you? Why is it any different when > it is more than one ORB vendor doing the same? I don't care about what individual vendors are doing. I do care about what we write into the spec. > > The suggestion that is being made means to marshal an exception in conflict > > with its IDL definition. In other words, the data being marshaled is no > > longer in agreement with the IDL definition of a type. > > I disagree. This proposal allows additional *optional* information to > be passed. Since a receiver that has no knowledge of the service > context can still unmarshal the exception, your claim that there is a > conflict is simply not true. Well, I certainly think that this sets a very dangerous precedent. I can just see the next change coming up: we decide that we'd like to add an extra field to some IDL struct. Because we don't want to touch the IDL, we just add another service context to carry the extra field... I most definitely don't want to set that precedent. And, given that there is no guarantee that the string will be present, because it's optional, I seriously wonder what it's going to be good for, given that I can't rely on it being there anyway. What's being suggested here is useful only for Java clients talking to Java servers via RMI over IIOP -- and for that, we are going to make additions to GIOP? > This argument doesn't fly. With this argument, you must also reject the > OTS service contexts because they put information into GIOP messages > that only have to do with transactions and not all ORBs or applications > use transactions. No. The service context isn't present unless it's needed, and the service context isn't there for only one language. > The GIOP service context is there *precisely* to carry things that are > application, language, or service dependant, and are properly not part > of the GIOP protocol. The GIOP serivce context is there *precisely* to carry things that are *service* dependent. I do not recall words in the spec anywhere to say that it is meant to be for application- or language-specific things. It's a *service* context, not an application or language context. > > Finally, I have yet to hear someone explain to me why minor codes are > > insufficient. In particular, I don't see why the minor code couldn't be > > translated into the reason string on the receiving end, so the entire > > issue would go back where it belongs, namely, in the domain of the > > Java language mapping. > > You are ignoring the original reason for the proposal. The Java to IDL > mapping maps some Java exceptions (which have a reason string and NO > minor code) to CORBA system exceptions. Without this added context, > some information is thrown away and the Java to IDL mapping is less than > complete. Too bloody bad then, ain't it? I don't recall us changing GIOP because not all COM constructs map clean onto IDL either. But, no matter. I shall immediately submit an issue to add a C++ service context that permits me to transmit C++ pointer values in a service context. After all, C++ exceptions often contain pointers, so I'm forced to throw information away when I want to map a C++ exception to a system exception, and the C++ to IDL mapping is less than complete... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html To: Michi Henning cc: Jonathan Biggar , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: Your message of "Wed, 22 Mar 2000 18:41:41 PST." From: Bill Janssen Message-Id: <00Mar22.201044pst."3686"@watson.parc.xerox.com> Date: Wed, 22 Mar 2000 20:10:53 PST Content-Type: text X-UIDL: =#Td9*:g!!+96e9m_L!! > No, I don't think so. I am watching the service context being abused > to pile more and more things into the platform in a way subverts > (perverts?) > GIOP itself. Perhaps this is where a strong AB would help... > In particular, I don't see why the minor code couldn't be > translated into the reason string on the receiving end, so the > entire > issue would go back where it belongs, namely, in the domain of the > Java language mapping. While being clear that I think that sending such dubious (thanks, Max!) information back to the client is a bad idea... The "reason" could be something that varies for a given minor code, such as a stack trace, or source code line numbers, or whatever. Bill Date: Wed, 22 Mar 2000 20:28:42 -0800 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Jonathan Biggar , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 0@a!!T1Ee9S\#e9F_Vd9 Michi - Michi Henning wrote: > On Wed, 22 Mar 2000, Jonathan Biggar wrote: > > > > No, I don't think so. I am watching the service context being abused > > > to pile more and more things into the platform in a way subverts (perverts?) > > > GIOP itself. > > > > If an ORB vendor decided to do this exact proposal using a proprietary > > service context, what would it be to you? Why is it any different when > > it is more than one ORB vendor doing the same? > > I don't care about what individual vendors are doing. I do care about > what we write into the spec. > > > > The suggestion that is being made means to marshal an exception in conflict > > > with its IDL definition. In other words, the data being marshaled is no > > > longer in agreement with the IDL definition of a type. > > > > I disagree. This proposal allows additional *optional* information to > > be passed. Since a receiver that has no knowledge of the service > > context can still unmarshal the exception, your claim that there is a > > conflict is simply not true. > > Well, I certainly think that this sets a very dangerous precedent. I can > just see the next change coming up: we decide that we'd like to add an > extra field to some IDL struct. Because we don't want to touch the IDL, > we just add another service context to carry the extra field... > I most definitely don't want to set that precedent. > > And, given that there is no guarantee that the string will be present, > because it's optional, I seriously wonder what it's going to be good for, > given that I can't rely on it being there anyway. What's being suggested > here is useful only for Java clients talking to Java servers via RMI over > IIOP -- and for that, we are going to make additions to GIOP? > > > This argument doesn't fly. With this argument, you must also reject the > > OTS service contexts because they put information into GIOP messages > > that only have to do with transactions and not all ORBs or applications > > use transactions. > > No. The service context isn't present unless it's needed, and the service > context isn't there for only one language. > > > The GIOP service context is there *precisely* to carry things that are > > application, language, or service dependant, and are properly not part > > of the GIOP protocol. > > The GIOP serivce context is there *precisely* to carry things that > are *service* dependent. I do not recall words in the spec anywhere to say > that it is meant to be for application- or language-specific things. Just like you point out above, it'll be available for all languages. I think you're obfuscating the matter when you bring the language issue in. It might only be more easily exploitable by Java language ORBs, but other ORBs could use it as well. > It's a *service* context, not an application or language context. Is reporting a "reason" on an exception not a service? > > > > Finally, I have yet to hear someone explain to me why minor > codes are > > > insufficient. In particular, I don't see why the minor code > couldn't be > > > translated into the reason string on the receiving end, so the > entire > > > issue would go back where it belongs, namely, in the domain of > the > > > Java language mapping. > > > > You are ignoring the original reason for the proposal. The Java > to IDL > > mapping maps some Java exceptions (which have a reason string and > NO > > minor code) to CORBA system exceptions. Without this added > context, > > some information is thrown away and the Java to IDL mapping is > less than > > complete. > > Too bloody bad then, ain't it? I don't recall us changing GIOP > because not > all COM constructs map clean onto IDL either. But, no matter. I > shall > immediately submit an issue to add a C++ service context that > permits > me to transmit C++ pointer values in a service context. After all, > C++ > exceptions often contain pointers, so I'm forced to throw > information away > when I want to map a C++ exception to a system exception, and the > C++ to > IDL mapping is less than complete... Are you concerned about (1) The style in which this information is being passed? (2) The content of the information being passed? (3) The fact that it is only and only usable by Java? Concern number (3) makes no sense to me, and I think Simon has already demolished that concern by pointing out a possible criteria which could be used to judge such concerns even if it was good only for Java. Concern (2) makes a bit of sense to me but only a bit, now. Concern (1) is what needs focus and attention. Do we have a collection of all service_contexts defined by all services and specs so far? Is there no service_context defined by any spec that contains useful information without having to trigger any action on the part of receiving and or sending orb to provide or use a particular service? In other words, has there not been a tradition set for this sin? Max > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 23 Mar 2000 14:23:21 +1000 (EST) From: Michi Henning To: Bill Janssen cc: Jonathan Biggar , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: <00Mar22.201044pst."3686"@watson.parc.xerox.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: YOOd9[S:e9p2+!!WFb!! On Wed, 22 Mar 2000, Bill Janssen wrote: > While being clear that I think that sending such dubious (thanks, > Max!) information back to the client is a bad idea... The "reason" > could be something that varies for a given minor code, such as a > stack > trace, or source code line numbers, or whatever. Now *that* is the first time that I've heard anything to point out deficiencies with the minor code idea. You are right -- minor codes are static and can't take into account things that vary at run time, such as a line number or PC value. Given that we are dealing with system exceptions, however, I don't see this as a serious limitation, in particular when you consider that almost all system exceptions indicate serious and hard errors about which the client (or the server) can't do anything anyway. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@corvette.floorboard.com Message-ID: <38D9A09C.94180D74@floorboard.com> Date: Wed, 22 Mar 2000 20:42:04 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: '$[!!?,ad9GAld9_9H!! Michi Henning wrote: > > > The suggestion that is being made means to marshal an exception > in conflict > > > with its IDL definition. In other words, the data being > marshaled is no > > > longer in agreement with the IDL definition of a type. > > > > I disagree. This proposal allows additional *optional* > information to > > be passed. Since a receiver that has no knowledge of the service > > context can still unmarshal the exception, your claim that there > is a > > conflict is simply not true. > > Well, I certainly think that this sets a very dangerous precedent. I > can > just see the next change coming up: we decide that we'd like to add > an > extra field to some IDL struct. Because we don't want to touch the > IDL, > we just add another service context to carry the extra field... > I most definitely don't want to set that precedent. > > And, given that there is no guarantee that the string will be > present, > because it's optional, I seriously wonder what it's going to be good > for, > given that I can't rely on it being there anyway. What's being > suggested > here is useful only for Java clients talking to Java servers via RMI > over > IIOP -- and for that, we are going to make additions to GIOP? Michi, Michi. This is *NOT* a change to GIOP! The only service context that is really a part of GIOP is the codeset context, since it affects the interpretation of marshalled data. (And for this reason, the codeset info really should have been part of the GIOP message format directly, which would resolve the other thread we have going on on this list.) ALL of the other service contexts are simply using GIOP as a transport mechanism, this proposed one as well. > > This argument doesn't fly. With this argument, you must also reject the > > OTS service contexts because they put information into GIOP messages > > that only have to do with transactions and not all ORBs or applications > > use transactions. > > No. The service context isn't present unless it's needed, and the service > context isn't there for only one language. You haven't presented a clear distinction why the OTS case is good, while this proposal is bad. > > The GIOP service context is there *precisely* to carry things that are > > application, language, or service dependant, and are properly not part > > of the GIOP protocol. > > The GIOP serivce context is there *precisely* to carry things that > are *service* dependent. I do not recall words in the spec anywhere to say > that it is meant to be for application- or language-specific things. > > It's a *service* context, not an application or language context. Fine, so we reword this proposal to call it the "reason string service" which just happens to work the same way. Arguing based on the fact that we call it a "service context" that you can't use if for application or language dependent purposes is incredibly weak. > > > Finally, I have yet to hear someone explain to me why minor codes are > > > insufficient. In particular, I don't see why the minor code couldn't be > > > translated into the reason string on the receiving end, so the entire > > > issue would go back where it belongs, namely, in the domain of the > > > Java language mapping. > > > > You are ignoring the original reason for the proposal. The Java to IDL > > mapping maps some Java exceptions (which have a reason string and NO > > minor code) to CORBA system exceptions. Without this added context, > > some information is thrown away and the Java to IDL mapping is less than > > complete. > > Too bloody bad then, ain't it? I don't recall us changing GIOP because not > all COM constructs map clean onto IDL either. But, no matter. I shall > immediately submit an issue to add a C++ service context that permits > me to transmit C++ pointer values in a service context. After all, C++ > exceptions often contain pointers, so I'm forced to throw information away > when I want to map a C++ exception to a system exception, and the C++ to > IDL mapping is less than complete... Sorry, Michi, but you are wrong. The DCOM/CORBA mapping added THREE service contexts, one of which passes through information (thread identifier) that is defined in DCOM but not in CORBA. This is a clear precedent for the proposal under debate. If someone wants to define a C++ to CORBA mapping, akin to the Java to IDL mapping, then they may just have to do that. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 23 Mar 2000 14:50:57 +1000 (EST) From: Michi Henning To: "M. Mortazavi" cc: Jonathan Biggar , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: <38D99D79.89868CFA@eng.sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: k90!!4T"!!8C-!!&"\!! On Wed, 22 Mar 2000, M. Mortazavi wrote: > Are you concerned about > (1) The style in which this information is being passed? Yes, that's one concern. The data being passed is no longer determined by the IDL definition. Moreover, it's architecturally bad. We are attacking things at completely the wrong level of abstraction by putting the string into the service context. I still see this as a language-specific issue. I know, a number of people have pointed out that the feature may be useful in other languages. My answer to that is that, for the past ten years, CORBA has managed quite nicely without the feature, so I find it hard to believe that the feature suddenly is of extreme urgency. As far as I can see, the language-independent argument is no more than putting a sales spin on the fact that what it is really needed for is Java-to-Java via RMI over IIOP communication, and no amount of trying to sell me on the feature for other languages will change that. Arguments about the Java to IDL mapping being incomplete don't count to me either. First, I'd have to ask why a Java to IDL mapping was designed and approved that didn't take this issue into account from day one. Second, I'd have to ask why the feature wasn't addressed the way it should have been, that is, either as a language specific issue (which is architecturally clean) or as an IDL issue by adding the string to system exceptions (which would be clean too). > (2) The content of the information being passed? I have my doubts as to the usefulness of the information in the first place. The way I see it, it's useful only for debugging (considering that only system exceptions are concerned). For that, the information might as well be logged at the server end. > (3) The fact that it is only and only usable by Java? > > Concern number (3) makes no sense to me, and I think Simon has > already demolished that > concern by pointing out a possible criteria which could be used to > judge such concerns > even if it was good only for Java. See above. If it's good only for Java, then it belongs into the Java language mapping, not the GIOP protocol. If it's good for all languages, then it belongs into IDL, not the GIOP protocol. The current approach is neither here nor there and being suggested simply "because it would be nice to have", not because there is "overwhelming customer demand for the feature" (and, I strongly suspect, because no-one thought of this earlier, when the thinking should have been done). > Do we have a collection of all > service_contexts defined by all services and specs so far? Is there > no service_context > defined by any spec that contains useful information without having > to trigger any action > on the part of receiving and or sending orb to provide or use a > particular service? In > other words, has there not been a tradition set for this sin? I'm not sure. But even in the presence of sinful tradition, I'm not at all sure that two wrongs make a right. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Jeffrey Mischkinsky Message-Id: <200003230450.UAA10156@wheel.dcn.davis.ca.us> Subject: Re: Transferring Java exception reason string across the wire To: janssen@parc.xerox.com (Bill Janssen) Date: Wed, 22 Mar 2000 20:50:43 -0800 (PST) Cc: michi@ooc.com.au (Michi Henning), jon@floorboard.com (Jonathan Biggar), interop@omg.org, java-rtf@omg.org In-Reply-To: <00Mar22.201044pst."3686"@watson.parc.xerox.com> from "Bill Janssen" at Mar 22, 2000 08:10:53 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: U<+!!lAB!!1W[!!aj&!! 'Bill Janssen' writes: > > > No, I don't think so. I am watching the service context being > abused > > to pile more and more things into the platform in a way subverts > (perverts?) > > GIOP itself. > > Perhaps this is where a strong AB would help... You'll just have to wait until the RTF report comes up for a vote, and see what happens. :-) In the meantime.... this beats watching daytime TV. (I think :-) There must be a reason for this... if only someone would send it to me :-) jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Thu, 23 Mar 2000 15:35:18 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: <38D9A09C.94180D74@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: H?_!![R2!!eZhd9Z= Michi, Michi. This is *NOT* a change to GIOP! The only service context > that is really a part of GIOP is the codeset context, since it affects > the interpretation of marshalled data. (And for this reason, the > codeset info really should have been part of the GIOP message format > directly, which would resolve the other thread we have going on on this > list.) Yep. > ALL of the other service contexts are simply using GIOP as a transport > mechanism, this proposed one as well. > > > > This argument doesn't fly. With this argument, you must also reject the > > > OTS service contexts because they put information into GIOP messages > > > that only have to do with transactions and not all ORBs or applications > > > use transactions. > > > > No. The service context isn't present unless it's needed, and the service > > context isn't there for only one language. > > You haven't presented a clear distinction why the OTS case is good, > while this proposal is bad. As I said, the OTS context isn't just for one language, it's present only when needed, and it's the only way to permit both transactional and non-transactional implementations to use the same IDL. > > It's a *service* context, not an application or language context. > > Fine, so we reword this proposal to call it the "reason string > service" > which just happens to work the same way. Arguing based on the fact > that > we call it a "service context" that you can't use if for application > or > language dependent purposes is incredibly weak. I find it incredibly weak that system exceptions in Java suddenly would have preferred status, that a change at the protocol level is required to make it possible, that the information isn't guaranteed to be there at all, and that I can't access it anywhere except with RMI over IIOP (because the language mappings are missing, if nothing else). > Sorry, Michi, but you are wrong. The DCOM/CORBA mapping added THREE > service contexts, one of which passes through information (thread > identifier) that is defined in DCOM but not in CORBA. This is a > clear > precedent for the proposal under debate. That information is relevant to all languages, not just one, no? > If someone wants to define a C++ to CORBA mapping, akin to the Java to > IDL mapping, then they may just have to do that. I'd oppose that just as much as I'm opposing the current proposal. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Thu, 23 Mar 2000 08:51:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: H"jd9:4id9W#gd9@@:!! > From: Jonathan Biggar [mailto:jon@floorboard.com] > I just don't understand why some people are getting their > knickers tied > up in a knot over this one. The information to be transmitted in > the > proposed service context is a diagnostic, most likely debugging > information. I don't see applications algorithmically > depending on the > contents of the string, and if you are worried about that, we > can put a > caution in the definition of the service context to that effect. In that case, perhaps this service context should be called something like DiagnosticData, and should contain an Any. Relationship to exceptions should not be implied, except perhaps to the extent that the Java language mapping chooses to make some hack. I would still be troubled by this, but less so. In general I am troubled by anything that has insufficient semantics to permit meaningful interoperation, between languages or between orbs. From: Paul Kyzivat To: interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Thu, 23 Mar 2000 09:10:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: cEOe9eCLe98> The GIOP serivce context is there *precisely* to carry things that > are *service* dependent. I do not recall words in the spec > anywhere to say > that it is meant to be for application- or language-specific things. > > It's a *service* context, not an application or language context. This is an important point! We have other cases where service contexts are being used for something other than a service, and almost without exception they are causing us a world of hurt. E.g. CodeSet, CodeBase Sender: Peter.Walker@eng.sun.com Message-ID: <38DA2CE8.456CA5EF@eng.Sun.COM> Date: Thu, 23 Mar 2000 06:40:40 -0800 From: Peter Walker Organization: Sun Microsystems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Simon Nash , Paul Kyzivat , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: :Opd9HB$"!dNBe9PSkd9 Michi Henning wrote: > > On Wed, 22 Mar 2000, Simon Nash wrote: > > > Paul, > > I believe we have to be responsive to reasonable requests made by > our users. > > Of course I would like to do them all in an architecturally pure > way as far > > as possible. But if it's a choice between doing something a > little less pure > > and turning down a reasonable user request for no reason that the > users can > > understand, I'd rather have a better (in the functional sense) > product and > > delighted customers. > > You keep assuming that request is reasonable. My assertion is that > it is not. > Your customers don't have to use CORBA, after all. > They already are ! Pj. Date: Thu, 23 Mar 2000 10:55:04 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "M. Mortazavi" Cc: Matthew Newhook , butek@us.ibm.com, Michi Henning , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <852568AA.004A9334.00@d54mta08.raleigh.ibm.com> <20000322132409.A26065@ooc.com> <38D9734F.2E9FA7D7@eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ;Q1e93MXd9NS%e9Wo)e9 "M. Mortazavi" wrote: > Matthew - > > Matthew Newhook wrote: > > > Hi, > > > > On Wed, Mar 22, 2000 at 07:26:24AM -0600, butek@us.ibm.com wrote: > > > Yes, this is a hack, but so is most of CORBA. > > > > It is? Please enumerate the set of nasty hacks that pollute most of CORBA. > > > > > The real problem is that exceptions are not first class objects. If they > > > were, the Java bindings could extend the base SystemException class to add > > > a reason string and that class could be sent across the wire. If the other > > > side isn't Java, then it would just see a SystemException and everything > > > would be peachy. > > > > Mmmm... isn't SystemException a struct which isn't extensible? ;) > > But the extensibility is not of much use in the way you're thinking of. An orb vendor > can always do what they want, including such extensions, but it does non mean they'll be > acceptable for inclusion in the spec. Placing my combined AB and Board alternate hat firmly on.....Actually, if the position articulated by Masood is Sun's official position on this matter, I am very happy with killing this service context idea. My real concern is that Sun (and other Java licensees) will introduce this through a JCP because they decide this is needed. Afterall, a group of vendors can band together and define a set of service contexts that their products will use, without bothering to get it blessed by OMG. If said group includes all or most of the top Java vendors, it would constitute a significant plurality, of CORBA vendors. If that is what is going to happen, I'd prefer to see it (or at least a discussion of it leading to the use of the much tried and tested voting process) happen within the OMG process first rather than in a side/back-door separate process. Regards, Jishnu. To: Paul Kyzivat Cc: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire MIME-Version: 1.0 Content-ID: <14187.953827841.1@gte.com> Date: Thu, 23 Mar 2000 11:10:42 -0500 From: "Gary D. Duzan" Content-Type: text/plain; charset="us-ascii" X-UIDL: Kpa!!FO/e9*Q,e9\d4e9 In Message <9B164B713EE9D211B6DC0090273CEEA926BD3C@bos1.noblenet.com> , Paul Kyzivat wrote: =>In that case, perhaps this service context should be called something like =>DiagnosticData, and should contain an Any. Relationship to exceptions should =>not be implied, except perhaps to the extent that the Java language mapping =>chooses to make some hack. => =>I would still be troubled by this, but less so. => =>In general I am troubled by anything that has insufficient semantics to =>permit meaningful interoperation, between languages or between orbs. If we try to generalize the problem, I think it is fair to say that run time debugging information attached to a SystemException (or any other reply) is going to be specific to the server implementation, so no client should be expected to understand it; i.e., it should be opaque to the client. Such information can only be interpreted by returning it to the server, either in-band, using an application-defined interface, or out-of-band, using some tool provided by the server. So why send the information to the client at all? At least one possible motivating (but not necessarily convincing) possibility come to mind: remote diagnosis of problems when the server is not available (due, e.g., to intervening firewalls.) This might be the case when supporting an already-deployed system, but you do have the server-side debugging tools available. Server-side logging of the debugging data was presented as an alternative to sending it to the client, and it does seem to be a better solution for most situations. So assuming that remote diagnosis is a sufficiently motivating issue, what about implementation? A vendor (or language mapping) specific solution may be sufficient in some cases, but not in others. Let's imagine for a moment a multi-tier system with a client and server using the same ORB, a firewall between them, and a back-end system using another language/ORB. If the back-end system is raising the exception, diagnosing the problem from the client would require forwarding the run time debugging to the client in a way which allows it to deal with it (e.g., display it in hex, store it to a file, or otherwise make it available to the server debugging tool), if not actually understand it. If the method of transport of the information were standard, if not the contents, at least a foreign ORB/language could know to act on it (though a format for storing/transmitting the information to the debugging tool is left open.) A standard service context may be a reasonable method, if you care to consider this a "Remote Debugging Service". So even further assuming that this general-purpose facility were made available, does it solve the RMI/IIOP reason string problem? Well, maybe. If by convention (or as specified in the language mapping) the information passed was the reason string, we still have the problem of interpretation. Since a client implementation would be free to ignore the information entirely, it could certainly ignore information it didn't understand, so if it were able to determine that the information was a string, the RMI/IIOP client would be free to stuff it in the reason field, discarding it otherwise. Of course, there is no guarantee that the string was generated by an RMI/IIOP server, so if the RMI implementation expects the string to be in a particular format, it is going to be out of luck. (I'm not familiar enough with RMI to know if this is the case or not.) The fact that the client will really have no clue as to what any of it means is its own problem, and not one that should concern anyone outside of the RMI/IIOP arena. Does all that sound right? Are there any other motivating factors for wanting a general-purpose facility for delivering detailed run time debugging data to clients? If not, and there is agreement that remote debugging isn't a major issue, then it seems that something vendor or language-specific would be better, and the core spec shouldn't be altered to deal with it. If remote debugging or other factors are found to be sufficiently desirable, and some solution as described above would meet the requirements of RMI/IIOP, then it seems that it should be made standard. Gary Duzan GTE Laboratories From: Bill Binko To: "'Paul Kyzivat'" , interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Thu, 23 Mar 2000 11:20:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: L_&!!?dB!!6(@!!~/Q!! Paul Wrote: > >> From: Jonathan Biggar [mailto:jon@floorboard.com] > >> I just don't understand why some people are getting their >> knickers tied >> up in a knot over this one. The information to be transmitted in the >> proposed service context is a diagnostic, most likely debugging >> information. I don't see applications algorithmically >> depending on the >> contents of the string, and if you are worried about that, we >> can put a >> caution in the definition of the service context to that effect. > >In that case, perhaps this service context should be called >something like >DiagnosticData, and should contain an Any. Relationship to >exceptions should >not be implied, except perhaps to the extent that the Java >language mapping >chooses to make some hack. > Paul, This is exactly what I was proposing earlier: make this less controversial by defining it in a language-neutral way and having a discussion about what the structure of a diagnostic message should look like. (Anys may not fly with small footprint ORBs). After all, this type of information is useful in other circumstances and with PI, it would be trivial for the ORB _or_ the app to populate it. Binko Sender: Peter.Walker@eng.sun.com Message-ID: <38DA437A.7776D2F9@eng.Sun.COM> Date: Thu, 23 Mar 2000 08:16:58 -0800 From: Peter Walker Organization: Sun Microsystems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jis@fpk.hp.com CC: "M. Mortazavi" , Matthew Newhook , butek@us.ibm.com, Michi Henning , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <852568AA.004A9334.00@d54mta08.raleigh.ibm.com> <20000322132409.A26065@ooc.com> <38D9734F.2E9FA7D7@eng.sun.com> <38DA3E57.49AA8E29@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 5Bgd9PPP!!e~S!!~_=e9 Jishnu Mukerji wrote: > > "M. Mortazavi" wrote: > > > Matthew - > > > > Matthew Newhook wrote: > > > > > Hi, > > > > > > On Wed, Mar 22, 2000 at 07:26:24AM -0600, butek@us.ibm.com > wrote: > > > > Yes, this is a hack, but so is most of CORBA. > > > > > > It is? Please enumerate the set of nasty hacks that pollute most > of CORBA. > > > > > > > The real problem is that exceptions are not first class > objects. If they > > > > were, the Java bindings could extend the base SystemException > class to add > > > > a reason string and that class could be sent across the wire. > If the other > > > > side isn't Java, then it would just see a SystemException and > everything > > > > would be peachy. > > > > > > Mmmm... isn't SystemException a struct which isn't extensible? > ;) > > > > But the extensibility is not of much use in the way you're > thinking of. An orb vendor > > can always do what they want, including such extensions, but it > does non mean they'll be > > acceptable for inclusion in the spec. > > Placing my combined AB and Board alternate hat firmly > on.....Actually, if the position > articulated by Masood is Sun's official position on this matter, I > am very happy with killing > this service context idea. My real concern is that Sun (and other > Java licensees) will > introduce this through a JCP because they decide this is > needed. Afterall, a group of vendors > can band together and define a set of service contexts that their > products will use, without > bothering to get it blessed by OMG. If said group includes all or > most of the top Java > vendors, it would constitute a significant plurality, of CORBA > vendors. If that is what is > going to happen, I'd prefer to see it (or at least a discussion of > it leading to the use of > the much tried and tested voting process) happen within the OMG > process first rather than in > a side/back-door separate process. > > Regards, > > Jishnu. First, I thought we were still in discussion - so Max's observations/comments are part of a long train of collective thought. Second, no that is not Sun's official position at this stage. The discussion may not be over. Third, we too wish to see things that are to do with CORBA defined, maintained, revised etc. in a timely way *in the OMG*. Finally, JCP is not a side/back-door process and has nothing to do with this issue as far I can see. Regards, Peter. -- ================================================================== Peter J. Walker Senior Staff Engineer, Enterprise Java Java Software, Platform Products 20525 Mariani, Cupertino, CA pwalker@eng.Sun.com http://java.sun.com/j2ee Phone (408)517-5679 FAX (408)863-3195 ================================================================== Date: Thu, 23 Mar 2000 11:16:07 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar Cc: Michi Henning , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <38D98125.D3755A33@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Okjd9$>F!!<6+e9#jod9 Jonathan Biggar wrote: > Michi Henning wrote: > > > This is irrelevant, since the proposal does not make IIOP in any > wah > > > language dependent. It just happens to make IIOP work better > for Java > > > applications when JAVA is on both sides of the pipe. > > > > > > I just don't understand why some people are getting their > knickers tied > > > up in a knot over this one. The information to be transmitted > in the > > > proposed service context is a diagnostic, most likely debugging > > > information. I don't see applications algorithmically depending > on the > > > contents of the string, and if you are worried about that, we > can put a > > > caution in the definition of the service context to that effect. > > > > What use is the diagnostic on the client side? The client doesn't > even > > know where the server is, or in what language it's implemented. > > It would make a lot more sense for the server to log this info > instead > > of returning it to the client. > > > > In addition, if it's OK to add extra optional stuff to the service > context, > > then I assume that it would be OK to do that for C++, and COBOL, > and > > SmallTalk, and C, and Ada too? If so, I don't think it would take > me long > > to think up about half a dozen things that I think might be useful > for > > C++ implementations. In my personal opinion, after the requirements have been run through the "genuine usefulness test" possible ways of addressing them, even using the dreaded notion of a new service context, if that is what it takes, should be considered and run through the usual evaluation and voting process if it comes to that. > > > > > Shall I really go and raise all of these as issues so we can > debate > > them at our leasure? > > > > And, of course, I will be stridently insisting on adoption of > these > > C++-specific features. After all, what is fair for Java is fair > for C++... > > > > And, I'm sure, I can think of a few more for COBOL too. I think > it's about > > time that we added lots of optional tags to the service context > for all > > those COBOL servers out there... :-( > > > > Needless to say, in the absence of stronger arguments as to why > this change > > is necessary, I will continue to oppose it. > > The argument for the change is simple: to allow Java programs that > used > RMI to use IIOP transparently. This is a quite reasonable request, > and > given that anyone who doesn't implement a Java ORB can completely > forget > that the service context even exists, the request has extremely > minimal > impact. That is about the way I see it too. However, now that Sun and IBM seem to disagree even on the usefulness of it for Java, we could perhaps let them go away and yell at each other privately for a while and then come back when they have made up their collective minds about whether it is useful or not.:-) > I really think you are erring towards pedagogy here. I tend to agree with Jon on this one. Service contexts have been used for enhancing interworking with other environments like COM in the past. For better or for worse, the PTC voted to bring about a degree of congruence between the Java environment and the CORBA environment. The relationship between Java and CORBA is a special one as articulated in the various PTC motions, including the one adopting the CORBA Component Model. I know some people don't like it, but that is the way the votes came out. Given this fact, I don't see any point in being rediculously strident about opposing a genuine requirement (notice the use of the term "genuine" there*[see footnote below]) to deliver on that overall direction. As for additions to support COBOL, I am sure we would make them if they were necessary and there were someone to file an answer to the BC questionnaire saying that they were going to deliver those enhancements in their product. Taking the least common denominator position mindlessly would spell the doom of CORBA somewhat prematurely I think. Just my usually uninformed opinion, of course. *I believe that it is more important to discuss the genuineness of the requirement. If the requirement is genuine, I see no reason to oppose using service context to satify it. To this end I find the discussion around Michi's challenge and Masood's rejoinder regarding the genuineness of the requirement much more useful, than the pointlessly inflamatory discussion about "my hack is sweeter than yours" and "the whole world is a hack anyway".:-) Jishnu. Date: Thu, 23 Mar 2000 08:43:35 -0800 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: jis@fpk.hp.com CC: Peter Walker , Matthew Newhook , butek@us.ibm.com, Michi Henning , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <852568AA.004A9334.00@d54mta08.raleigh.ibm.com> <20000322132409.A26065@ooc.com> <38D9734F.2E9FA7D7@eng.sun.com> <38DA3E57.49AA8E29@fpk.hp.com> <38DA437A.7776D2F9@eng.Sun.COM> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: e3#!!@*9!!Gh?!!K0Ud9 Jishnu - Peter is correct about this. My assumption has been that we're still discussing an open issue but I would like to steer the issue away from language sensitivities for a moment in order to make it clearer for all, including myself, to see and settle the issue. We cannot discuss this in a sane manner as long as people muddy the waters with their prejudices. Simon's criteria of judging such cases seems a good measure for judging these cases. Max Peter Walker wrote: > Jishnu Mukerji wrote: > > > > "M. Mortazavi" wrote: > > > > > Matthew - > > > > > > Matthew Newhook wrote: > > > > > > > Hi, > > > > > > > > On Wed, Mar 22, 2000 at 07:26:24AM -0600, butek@us.ibm.com > wrote: > > > > > Yes, this is a hack, but so is most of CORBA. > > > > > > > > It is? Please enumerate the set of nasty hacks that pollute > most of CORBA. > > > > > > > > > The real problem is that exceptions are not first class > objects. If they > > > > > were, the Java bindings could extend the base > SystemException class to add > > > > > a reason string and that class could be sent across the > wire. If the other > > > > > side isn't Java, then it would just see a SystemException > and everything > > > > > would be peachy. > > > > > > > > Mmmm... isn't SystemException a struct which isn't extensible? > ;) > > > > > > But the extensibility is not of much use in the way you're > thinking of. An orb vendor > > > can always do what they want, including such extensions, but it > does non mean they'll be > > > acceptable for inclusion in the spec. > > > > Placing my combined AB and Board alternate hat firmly > on.....Actually, if the position > > articulated by Masood is Sun's official position on this matter, I > am very happy with killing > > this service context idea. My real concern is that Sun (and other > Java licensees) will > > introduce this through a JCP because they decide this is > needed. Afterall, a group of vendors > > can band together and define a set of service contexts that their > products will use, without > > bothering to get it blessed by OMG. If said group includes all or > most of the top Java > > vendors, it would constitute a significant plurality, of CORBA > vendors. If that is what is > > going to happen, I'd prefer to see it (or at least a discussion of > it leading to the use of > > the much tried and tested voting process) happen within the OMG > process first rather than in > > a side/back-door separate process. > > > > Regards, > > > > Jishnu. > > First, I thought we were still in discussion - so Max's > observations/comments are part of a long train of collective > thought. > > Second, no that is not Sun's official position at this stage. The > discussion may not be over. > > Third, we too wish to see things that are to do with CORBA defined, > maintained, revised etc. in a timely way *in the OMG*. > > Finally, JCP is not a side/back-door process and has nothing to do > with > this issue as far I can see. > > Regards, > Peter. > > -- > ================================================================== > Peter J. Walker > Senior Staff Engineer, Enterprise Java > Java Software, Platform Products 20525 Mariani, Cupertino, CA > pwalker@eng.Sun.com http://java.sun.com/j2ee > Phone (408)517-5679 FAX (408)863-3195 > ================================================================== Date: Thu, 23 Mar 2000 11:35:24 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning Cc: Jonathan Biggar , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 3!+!!kK&e9k:4!!8^Be9 Michi Henning wrote: > > The GIOP service context is there *precisely* to carry things that are > > application, language, or service dependant, and are properly not part > > of the GIOP protocol. > > The GIOP serivce context is there *precisely* to carry things that > are *service* dependent. I do not recall words in the spec anywhere to say > that it is meant to be for application- or language-specific things. > > It's a *service* context, not an application or language context. > Currently, there are 10 standard service contexts defined. They are: const ServiceId TransactionService = 0; const ServiceId CodeSets = 1; const ServiceId ChainBypassCheck = 2; const ServiceId ChainBypassInfo = 3; const ServiceId LogicalThreadId = 4; const ServiceId BI_DIR_IIOP = 5; const ServiceId SendingContextRunTime = 6; const ServiceId INVOCATION_POLICIES = 7; const ServiceId FORWARDED_IDENTITY = 8; const ServiceId UnknownExceptionInfo = 9; Of these, only one appears to be realted strictly to a Service .... the TransactionService one. CodeSet has clearly nothing to do with a Service in the sense of CORBA service. The next three have to do with COM-CORBA interworking. Bi_DIR_IIOP has precious little to do with a service. SendingContextRunTime is an OBV related thing. One could argue that INVOCATION_POLICIES and FORWARDED_IDENTITY are service related, but they are borderline. UnknownExceptionInfo is clearly not Service related. Based on this evidence I strongly susepct that the position being taken by Michi reagrding the purpose of Service Contexts is not sustainable, unless of course he is using the term Service in a way that I don't quite understand. > Too bloody bad then, ain't it? I don't recall us changing GIOP because not > all COM constructs map clean onto IDL either. But we did add service contexts to carry extra stuff for COM bridge. So depending on what you mean by "changing GIOP" we did change it in the sense of adding a three new standard service contexts: ChainBypassCheck, ChainBypassInfo and LogicalThreadId. > But, no matter. I shall > immediately submit an issue to add a C++ service context that > permits > me to transmit C++ pointer values in a service context. After all, > C++ > exceptions often contain pointers, so I'm forced to throw > information away > when I want to map a C++ exception to a system exception, and the > C++ to > IDL mapping is less than complete... If it is a genuine requirement for C++ I think you should indeed submit such an issue and we should discuss it. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: Peter.Walker@eng.sun.com Message-ID: <38DA4BDD.F9D800FA@eng.Sun.COM> Date: Thu, 23 Mar 2000 08:52:45 -0800 From: Peter Walker Organization: Sun Microsystems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <38DA2CE8.456CA5EF@eng.Sun.COM> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 8Q]d9':m!!iWad9Q>bd9 Peter Walker wrote: > > Michi Henning wrote: > > > > On Wed, 22 Mar 2000, Simon Nash wrote: > > > > > Paul, > > > I believe we have to be responsive to reasonable requests made > by our users. > > > Of course I would like to do them all in an architecturally pure > way as far > > > as possible. But if it's a choice between doing something a > little less pure > > > and turning down a reasonable user request for no reason that > the users can > > > understand, I'd rather have a better (in the functional sense) > product and > > > delighted customers. > > > > You keep assuming that request is reasonable. My assertion is that > it is not. > > Your customers don't have to use CORBA, after all. > > > > They already are ! > > Pj. BTW - just to clarify my comment. I meant to infer that people already were using CORBA (not that they were leaving it as someone thought) - i.e. they have already made their choice and want to inject new requirements into CORBA. If on the other hand we make CORBA stand still they will vote with their feet. I think this thread may have started to turn to examine what Service Contexts are for - IMHO we should look at them as service CONTEXTS. Little to do with service per se and loads to do with CONTEXT. Pj. -- ================================================================== Peter J. Walker Senior Staff Engineer, Enterprise Java Java Software, Platform Products 20525 Mariani, Cupertino, CA pwalker@eng.Sun.com http://java.sun.com/j2ee Phone (408)517-5679 FAX (408)863-3195 ================================================================== Date: Thu, 23 Mar 2000 11:56:58 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "M. Mortazavi" Cc: Peter Walker , Matthew Newhook , butek@us.ibm.com, Michi Henning , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <852568AA.004A9334.00@d54mta08.raleigh.ibm.com> <20000322132409.A26065@ooc.com> <38D9734F.2E9FA7D7@eng.sun.com> <38DA3E57.49AA8E29@fpk.hp.com> <38DA437A.7776D2F9@eng.Sun.COM> <38DA49B7.3B457897@eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: _N+!!Lb~!!c@Wd9]G7!! "M. Mortazavi" wrote: > Jishnu - > > Peter is correct about this. > My assumption has been that we're still discussing an open issue but I would like to steer the > issue away from language sensitivities for a moment in order to make it clearer for all, including > myself, to see and settle the issue. > We cannot discuss this in a sane manner as long as people muddy the waters with their > prejudices. Simon's criteria of judging such cases seems a good measure for judging these cases. As I mentioned in a later message, I think the discussion about the legitimacy of the requirement is a valuable one. Please do carry on the good discussion. > > First, I thought we were still in discussion - so Max's > > observations/comments are part of a long train of collective > thought. Yep, I was just checking.:-) > > Second, no that is not Sun's official position at this stage. The > > discussion may not be over. I got the info that I was looking for.:-) > > Third, we too wish to see things that are to do with CORBA defined, > > maintained, revised etc. in a timely way *in the OMG*. I know, that's why I'd rather see this hashed out at OMG than the discussion being shut down prematurely. > > Finally, JCP is not a side/back-door process and has nothing to do with > > this issue as far I can see. Sorry, I was not picking on JCP in particular. I was using it as an example of a legitimate mechanism outside the OMG process through which things like "standard" service contexts could potentially get added to GIOP, not an OMG "standard", but *a* "standard". I apologize for using an inappropriate term like "side/back-door", it was only used relative to OMG process. Peace? Jishnu. From: Bill Binko To: "'jis@fpk.hp.com'" , Michi Henning Cc: Jonathan Biggar , interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Thu, 23 Mar 2000 12:29:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: `]`!!'[6e9/~X!!f#8e9 Jishnu wrote: >Michi Henning wrote: > >> > The GIOP service context is there *precisely* to carry >things that are >> > application, language, or service dependant, and are >properly not part >> > of the GIOP protocol. >> >> The GIOP serivce context is there *precisely* to carry things that >> are *service* dependent. I do not recall words in the spec >anywhere to say >> that it is meant to be for application- or language-specific things. >> >> It's a *service* context, not an application or language context. >> > >Currently, there are 10 standard service contexts defined. They are: > >const ServiceId TransactionService = 0; >const ServiceId CodeSets = 1; >const ServiceId ChainBypassCheck = 2; >const ServiceId ChainBypassInfo = 3; >const ServiceId LogicalThreadId = 4; >const ServiceId BI_DIR_IIOP = 5; >const ServiceId SendingContextRunTime = 6; >const ServiceId INVOCATION_POLICIES = 7; >const ServiceId FORWARDED_IDENTITY = 8; >const ServiceId UnknownExceptionInfo = 9; > >Of these, only one appears to be realted strictly to a Service .... the >TransactionService one. CodeSet has clearly nothing to do with >a Service in the >sense of CORBA service. The next three have to do with >COM-CORBA interworking. >Bi_DIR_IIOP has precious little to do with a service. >SendingContextRunTime is an >OBV related thing. One could argue that INVOCATION_POLICIES >and FORWARDED_IDENTITY >are service related, but they are borderline. >UnknownExceptionInfo is clearly not >Service related. > This made me actually go read the text of UnkownExceptionInfo. Here it is: * UnknownExceptionInfo identifies a CDR encapsulation of a marshaled instance of a java.lang.throwable or one of its subclasses as described in Java to IDL Language Mapping, Section 1.4.8.1, "Mapping of UnknownExceptionInfo Service Context," on page 1-32. It seems the Java vendors are asking for far LESS of a corruption than this in their current request. Therefore, it seems there is precedent for this type of service context. Can we please get past the purity issue and decide: 1) Whether we are going to make this useful to other languages or not. 2) If so, what form should this thing take. Binko From: Paul Kyzivat To: interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Thu, 23 Mar 2000 13:38:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: FP*!!>Y -----Original Message----- > From: Gary D. Duzan [mailto:gdd0@gte.com] > Sent: Thursday, March 23, 2000 11:11 AM > To: Paul Kyzivat > Cc: interop@omg.org; java-rtf@omg.org > Subject: Re: Transferring Java exception reason string across > the wire > > > In Message > <9B164B713EE9D211B6DC0090273CEEA926BD3C@bos1.noblenet.com> , > Paul Kyzivat wrote: > > =>In that case, perhaps this service context should be called > something like > =>DiagnosticData, and should contain an Any. Relationship to > exceptions should > =>not be implied, except perhaps to the extent that the Java > language mapping > =>chooses to make some hack. > => > =>I would still be troubled by this, but less so. > => > =>In general I am troubled by anything that has insufficient > semantics to > =>permit meaningful interoperation, between languages or between > orbs. > > If we try to generalize the problem, I think it is fair to say > that run time debugging information attached to a SystemException > (or any other reply) is going to be specific to the server > implementation, so no client should be expected to understand it; > i.e., it should be opaque to the client. Such information can only > be interpreted by returning it to the server, either in-band, using > an application-defined interface, or out-of-band, using some tool > provided by the server. > So why send the information to the client at all? At least one > possible motivating (but not necessarily convincing) possibility > come to mind: remote diagnosis of problems when the server is not > available (due, e.g., to intervening firewalls.) This might be the > case when supporting an already-deployed system, but you do have > the server-side debugging tools available. Server-side logging of > the debugging data was presented as an alternative to sending it > to the client, and it does seem to be a better solution for most > situations. > So assuming that remote diagnosis is a sufficiently motivating > issue, what about implementation? A vendor (or language mapping) > specific solution may be sufficient in some cases, but not in > others. Let's imagine for a moment a multi-tier system with a > client and server using the same ORB, a firewall between them, and > a back-end system using another language/ORB. If the back-end system > is raising the exception, diagnosing the problem from the client > would require forwarding the run time debugging to the client in > a way which allows it to deal with it (e.g., display it in hex, > store it to a file, or otherwise make it available to the server > debugging tool), if not actually understand it. If the method of > transport of the information were standard, if not the contents, > at least a foreign ORB/language could know to act on it (though a > format for storing/transmitting the information to the debugging > tool is left open.) A standard service context may be a reasonable > method, if you care to consider this a "Remote Debugging Service". > So even further assuming that this general-purpose facility were > made available, does it solve the RMI/IIOP reason string problem? > Well, maybe. If by convention (or as specified in the language > mapping) the information passed was the reason string, we still > have the problem of interpretation. Since a client implementation > would be free to ignore the information entirely, it could certainly > ignore information it didn't understand, so if it were able to > determine that the information was a string, the RMI/IIOP client > would be free to stuff it in the reason field, discarding it > otherwise. Of course, there is no guarantee that the string was > generated by an RMI/IIOP server, so if the RMI implementation > expects the string to be in a particular format, it is going to be > out of luck. (I'm not familiar enough with RMI to know if this is > the case or not.) The fact that the client will really have no clue > as to what any of it means is its own problem, and not one that > should concern anyone outside of the RMI/IIOP arena. > Does all that sound right? Are there any other motivating factors > for wanting a general-purpose facility for delivering detailed run > time debugging data to clients? If not, and there is agreement that > remote debugging isn't a major issue, then it seems that something > vendor or language-specific would be better, and the core spec > shouldn't be altered to deal with it. If remote debugging or other > factors are found to be sufficiently desirable, and some solution > as described above would meet the requirements of RMI/IIOP, then > it seems that it should be made standard. > > Gary Duzan > GTE Laboratories > > Date: Thu, 23 Mar 2000 18:26:53 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Peter Walker , butek@us.ibm.com, > interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: =QWd90,E!!3Pnd9lpT!! Michi, I am disturbed by the tone of some of your recent comments. They seem to say "CORBA is the way it is. If it doesn't meet certain needs of real-world customers, that's tough. The customers had better find some other solution." With all due respect, I don't think this will further the cause of CORBA. No product, organization, or architecture can afford to ignore the legitimate requests of its customers. If we do, they will indeed go and find other solutions and I don't think we would want that to happen. Simon Michi Henning wrote: > > On Wed, 22 Mar 2000, Peter Walker wrote: > > > Michi Henning wrote: > > > > > > I will continue to refuse to add > > > language-specific hacks to the protocol level, just as I will > refuse to > > > add language-specific things to IDL. > > > > > > > Michi, > > > > We already did this with a bunch of types from the COBOL world and > where > > did the "look and feel" of IDL come from in the first place? > > What hacks are currently in the protocol for COBOL types? > > The look and feel clearly came from the C/C++ world. Tough. That's > the look > and feel we have. If you don't like that, don't use CORBA. > > Cheers, > > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Thu, 23 Mar 2000 18:31:26 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Paul Kyzivat , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: \4=e9X+*!!YXgd9S"A!! Michi, There's no need to require the use of ASCII. The char/string codeset is negotiable, but not the natural language in the string. I think the choice of language should be left to the application rather than requiring it to be English. Simon Michi Henning wrote: > > On Wed, 22 Mar 2000, Paul Kyzivat wrote: > > > On the other hand, features that only work when the two ends are > both Java > > seriously break CORBA language independence, and should be > discouraged. > > (Those who believe the only language is Java will disagree.) So a > better > > solution would be to agree that a string is a useful component of > > SystemException, and then add that feature in a way that makes > sense in a > > language independent way. > > I could live with that, if we are prepared to rev GIOP for it, and > figure > out how we avoid breaking existing marshaling code with that change. > > But, even assuming that we can sort this out, I am still doubtful > about > the utility of sending a string that can't be localized. We could, > of course, > simply agree that the string is always in ASCII, using > English. However, > that then is only marginally better than using more precise minor > codes, > so it begs the question whether all the minor improvement is worth > all the disruption. > > Cheers, > > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Thu, 23 Mar 2000 18:51:57 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Paul Kyzivat , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Y\3!!i'-!!H5U!!oV-e9 Michi, Michi Henning wrote: > > On Wed, 22 Mar 2000, Simon Nash wrote: > > > Paul, > > I believe we have to be responsive to reasonable requests made by > our users. > > Of course I would like to do them all in an architecturally pure > way as far > > as possible. But if it's a choice between doing something a > little less pure > > and turning down a reasonable user request for no reason that the > users can > > understand, I'd rather have a better (in the functional sense) > product and > > delighted customers. > > You keep assuming that request is reasonable. My assertion is that > it is not. > Your customers don't have to use CORBA, after all. > I think the above response is unreasonable. You keep saying things > like this. Do you really want all IBM's customers to stop using CORBA? Really??? > Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Thu, 23 Mar 2000 21:04:07 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Bill Janssen , Jonathan Biggar , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: !<=e9^^g!!:Z`d9jQO!! Michi, Michi Henning wrote: > > On Wed, 22 Mar 2000, Bill Janssen wrote: > > > While being clear that I think that sending such dubious (thanks, > > Max!) information back to the client is a bad idea... The > "reason" > > could be something that varies for a given minor code, such as a > stack > > trace, or source code line numbers, or whatever. > > Now *that* is the first time that I've heard anything to point out > deficiencies with the minor code idea. You are right -- minor codes > are > static and can't take into account things that vary at run time, > such as > a line number or PC value. Given that we are dealing with system > exceptions, however, I don't see this as a serious limitation, in > particular > when you consider that almost all system exceptions indicate serious > and > hard errors about which the client (or the server) can't do anything > anyway. > Not just those things, but any additional information about the cause > of the failure. For example, a MARSHAL exception caused by failure to > unmarshal a derived valuetype could have a reason string containing the name of > the type for which no definition was available. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Thu, 23 Mar 2000 21:08:44 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Bill Binko , "'Bill Janssen'" , "'Jonathan Biggar'" , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: nAN!!T3b!!XXO!!#i%!! Michi, Michi Henning wrote: > > On Wed, 22 Mar 2000, Bill Binko wrote: > > > I just think it is something > > that Java ORB vendors (particularly those running RMI over IIOP) > will > > _need_. > > Hmmm... Considering that the Java mapping and RMI over IIOP have > been around > for quite some time, I'm having problems accepting the supposed > urgency > of this change. After all, if it really is that pressing, then, by > implication, > Java and RMI/IIOP are unusable in their current state, no? > It's a usability issue. That's not the same as saying that RMI-IIOP > is unusable. > I still keep hearing arguments that repeat that the reason string is > incredibly important. I still don't hear arguments to explain why > minor codes are insufficient, nor do I hear arguments to explain why > this can't be dealt with as Java language mapping issue, by > translating > the minor code into a string at the receiving end. > This can only be done if all possible strings that could ever be sent by a server are expressible as unique 32-bit numbers. Clearly this is not possible. For strings with fixed contents it may be possible, but not for strings with dynamically generated contents. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Thu, 23 Mar 2000 21:15:43 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "M. Mortazavi" CC: Jonathan Biggar , Jonathan Biggar <"jon"@jon@biggar.org>, Michi Henning , Jonathan Biggar , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <200003212352.PAA26486@corvette.floorboard.com> <38D970F6.957DC362@eng.sun.com> <38D97C67.81E93F07@floorboard.com> <38D98900.CDF0E8AD@eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: > Jonathan - > > Jonathan Biggar wrote: > > > "M. Mortazavi" wrote: > > > > > > The only other choice would be to extend the format of system > exceptions > > > > in GIOP 1.3 to add a reason string. > > > > > > That's not even a choice. IIOP loses its worth when it > becomes language or os > > > dependent. Minor codes are sufficient, when properly used. Note > that it's not > > > always possible to provide, even in Java, a stack trace of > "actual" reason that a > > > CORBA exception was raised. CORBA exceptions can be raised in > non-exceptional > > > Java cases. > > You seem to have glossed over the point I made in the sentence > above. "CORBA > exceptions can be raised in non-exceptional Java cases. " > Are we sure that all CORBA exceptions are raised when there's an > exceptional Java > situation. > I'm not sure about that. If someone can prove that most of them > are, then I'll start > thinking about this in a different light. > But then, I'll still have to be convinced why redundant > information is to be provided > according to a pre-specified manner. Furthermore, what's the use of > specifying a way of > passing this information if it cannot always be interpreted to the > extent it promises to > inform. > The Minor Code mechanism already exists and can be used quite > well to separate one > class of exceptional cases from the next. Vendors can provide > tools/tables/etc. to > interpret their MinorCodes. > The minor code defines a class of exceptional cases. The string would > augment this by providing information about the particular exception case > instance that has just occurred. > > And for the other cases, even if that stack trace is provided, it > > > does not guarantee any usefulness to the application > programmer. The ORB > > > developer has technology of his/her own to deal with the > situation. So, I don't > > > see any use to this. > > > > This is irrelevant, since the proposal does not make IIOP in any > wah > > language dependent. > > You're preaching to the Pope in this regard, and yes, it has > nothing to do with > language dependence but you don't seem to have taken a note of what > I was saying. Please > get out of the language dependence mode. Please see my note above. > > > It just happens to make IIOP work better for Java > > applications when JAVA is on both sides of the pipe. > > I'm not sure about this. Couldn't any CORBA exceptions be raised > during an excution > with no Java exception (or other language entity) in "view" to > provide a *textual* > "reason" that cannot be provided in a Minor Code? > Yes, in which case this optional service context would not be sent. > > I just don't understand why some people are getting their knickers tied > > up in a knot over this one. The information to be transmitted in the > > proposed service context is a diagnostic, most likely debugging > > information. > > If so, it can be a vendor specific service context. Right? > Or are you debugging across ORBs? > In other words, are you debugging ORB interoperability or application code? > > > I don't see applications algorithmically depending on the > > contents of the string, and if you are worried about that, > > Absolutely. > > > we can put a > > caution in the definition of the service context to that effect. > > A caution never worked with me. > > I'm *also* worried about interpretability and usefulness of any such *textual* > information. I think, while satisfying some curious developers, it will certainly muddy > the waters for them or others. > It's not for use by developers. It's there to help users and support people by giving them more information about the cause of failures. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Thu, 23 Mar 2000 21:17:23 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: "M. Mortazavi" , Jonathan Biggar , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: d29e9f^Vd9T8bd9CF^!! Michi, Michi Henning wrote: > > On Wed, 22 Mar 2000, M. Mortazavi wrote: > > > Are you concerned about > > (1) The style in which this information is being passed? > > Yes, that's one concern. The data being passed is no longer > determined > by the IDL definition. > > Moreover, it's architecturally bad. We are attacking things at > completely > the wrong level of abstraction by putting the string into the > service context. > Are you saying that passing a reason string is OK, but you don't like the proposed mechanism? If so, can you suggest a better mechanism? > I still see this as a language-specific issue. I know, a number of > people have pointed out that the feature may be useful in other > languages. > My answer to that is that, for the past ten years, CORBA has managed > quite > nicely without the feature, so I find it hard to believe that the > feature > suddenly is of extreme urgency. > This argument could be used to reject any proposed change. Yet for > some strange reason we seem to continue to make them. I wonder why? > As far as I can see, the language-independent > argument is no more than putting a sales spin on the fact that what it is > really needed for is Java-to-Java via RMI over IIOP communication, and > no amount of trying to sell me on the feature for other languages will change > that. > As I have already pointed out, it's equally applicable to the IDL to Java mapping. It's less obviously applicable to other languages since exceptions in those languages don't contain a reason string. > Arguments about the Java to IDL mapping being incomplete don't count to me > either. First, I'd have to ask why a Java to IDL mapping was designed and > approved that didn't take this issue into account from day one. > The reasons we have RTFs and FTFs is to correct deficiencies and oversights in adopted specifications. Often it is not until products get out into the field that certain deficiencies are noticed. This is why user feedback is so important and should not be ignored. > Second, > I'd have to ask why the feature wasn't addressed the way it should have been, > that is, either as a language specific issue (which is architecturally > clean) or as an IDL issue by adding the string to system exceptions (which > would be clean too). > So you agree a language specific issue would be clean? Would you be OK with transferring this to the Java RTF for them to resolve for Java only and no other languages? > > (2) The content of the information being passed? > > I have my doubts as to the usefulness of the information in the > first place. > The way I see it, it's useful only for debugging (considering that > only system > exceptions are concerned). For that, the information might as well > be > logged at the server end. > That's right, it's a human-readable message used for debugging. Maybe > the client doesn't have access to the server error log. Such things are > usually controlled by system administrators and support people. One of the > best debug aids is associating error information as closely as possible > with the point of failure. Returning such information to the client at the time of failure is often extremely useful. > > (3) The fact that it is only and only usable by Java? > > > > Concern number (3) makes no sense to me, and I think Simon has > already demolished that > > concern by pointing out a possible criteria which could be used to > judge such concerns > > even if it was good only for Java. > > See above. If it's good only for Java, then it belongs into the Java > language > mapping, not the GIOP protocol. If it's good for all languages, then > it > belongs into IDL, not the GIOP protocol. The current approach is > neither > here nor there and being suggested simply "because it would be nice > to have", > not because there is "overwhelming customer demand for the feature" > (and, > I strongly suspect, because no-one thought of this earlier, when the > thinking > should have been done). > I'd be OK with transferring this to the Java RTF to define a Java-only > solution. I think this will still require a new service context, though. This is more than a "nice to have." We have received strong customer feedback that losing the reason string when system exceptions are thrown from server to client is a problem. We will have to find some solution, and we would prefer an OMG standard solution to a proprietary one. Simon > > Do we have a collection of all > > service_contexts defined by all services and specs so far? Is > there no service_context > > defined by any spec that contains useful information without > having to trigger any action > > on the part of receiving and or sending orb to provide or use a > particular service? In > > other words, has there not been a tradition set for this sin? > > I'm not sure. But even in the presence of sinful tradition, I'm not > at all > sure that two wrongs make a right. > > Cheers, > > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Fri, 24 Mar 2000 07:35:16 +1000 (EST) From: Michi Henning To: Peter Walker cc: Simon Nash , Paul Kyzivat , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: <38DA2CE8.456CA5EF@eng.Sun.COM> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: We,e9aO7!!VM]!!F!Vd9 On Thu, 23 Mar 2000, Peter Walker wrote: > > Your customers don't have to use CORBA, after all. > > > > They already are ! Well, in that case, why did it take them so long to discover that their application cannot possibly built without having the reason string? ;-) Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: Peter.Walker@eng.sun.com Message-ID: <38DA8E84.F172DA1E@eng.Sun.COM> Date: Thu, 23 Mar 2000 13:37:08 -0800 From: Peter Walker Organization: Sun Microsystems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Simon Nash , Paul Kyzivat , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &-(e93#Ud90G1!!&5)e9 Michi Henning wrote: > > On Thu, 23 Mar 2000, Peter Walker wrote: > > > > Your customers don't have to use CORBA, after all. > > > > > > > They already are ! > > Well, in that case, why did it take them so long to discover that > their > application cannot possibly built without having the reason string? > ;-) Its not a binary can build/cant build thing - I think its an ease of use, ease of fault finding thing. Michi, BTW - Is that all the sleep you get? :-) Pj. Date: Fri, 24 Mar 2000 07:47:04 +1000 (EST) From: Michi Henning To: Peter Walker cc: Simon Nash , Paul Kyzivat , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: <38DA8E84.F172DA1E@eng.Sun.COM> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: $%\!!VN'!!acOe98pCe9 On Thu, 23 Mar 2000, Peter Walker wrote: > > > They already are ! > > > > Well, in that case, why did it take them so long to discover that > their > > application cannot possibly built without having the reason > string? ;-) > > Its not a binary can build/cant build thing - I think its an ease of > use, ease of fault finding thing. Yes. I wasn't really serious. > BTW - Is that all the sleep you get? :-) Peter, come on, own up to it. You just wish I'd sleep like Rip van Winkle :-) Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: Peter.Walker@eng.sun.com Message-ID: <38DA931F.149E6D73@eng.Sun.COM> Date: Thu, 23 Mar 2000 13:56:47 -0800 From: Peter Walker Organization: Sun Microsystems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Simon Nash , Paul Kyzivat , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 4<[d9a6_!!V5A!!5~+e9 Michi Henning wrote: > > Peter, come on, own up to it. You just wish I'd sleep like Rip van > Winkle :-) I can just see the headlines - "Human time capsule wakes to find an all Java world" :-) :-) yes, yes, I know - gratuitous :-) On a serious note - I do wonder whether the information/data to be conveyed in the manner suggested will be so variable as to make any fix/hack we might make useless in all but the most trivial cases. Anyone, Simon care to elaborate on the use cases here and indicate how closed or well defined the usage is likely to be ??..... Pj. Date: Fri, 24 Mar 2000 07:57:15 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: <38DA47CB.7ACC1FA6@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: /h7e9Gg3e9p'$e9bIad9 On Thu, 23 Mar 2000, Jishnu Mukerji wrote: > Michi Henning wrote: > > > It's a *service* context, not an application or language context. > > > > Currently, there are 10 standard service contexts defined. They are: > [...] > Based on this evidence I strongly susepct that the position being taken by Michi > reagrding the purpose of Service Contexts is not sustainable, unless of course he is > using the term Service in a way that I don't quite understand. You are right. Clearly, I can't sit here and claim that the contexts are for services only. (Although I *will* maintain that's what they initially were intended for, so there! ;-) I read through the other messages in this thread. My feeling is that the entire idea would be a lot more useful (and architecturally more palatable) if the feature were - not restricted to Java with RMI over IIOP only - we had a standardized format for the exception info - we had an extensible format for the exception info - we had a number of standardized tags/values that describe various things about an exception So, instead of arguing, Michi is going to make a 180 degree turn and change to making constructive suggestions. (If we have to do this, we should at least do it properly...) I think that an exception context with a defined tag *might* be useful for debugging. I also think that the format should be extensible and probably use name-value pairs for various interesting things, for example: - stack trace - source file and line number - some sort of human-readable message - domain name and port number of the sending server - process/thread ID - signal mask - ... These are just wild ideas, and I would expect that all of these would be optional. There are still issues about things like: - Is the feature useful enough to warrant adding it? - Are the localization issues important? (Probably not, if we accept that this is a debugging aid.) - How do the various language mappings make this information available to the client? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Fri, 24 Mar 2000 08:09:38 +1000 (EST) From: Michi Henning To: Simon Nash cc: Peter Walker , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: <38DA61ED.38486DED@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 5l"e9C+%e9+:fd9VM(!! On Thu, 23 Mar 2000, Simon Nash wrote: > Michi, > I am disturbed by the tone of some of your recent comments. They > seem to > say "CORBA is the way it is. If it doesn't meet certain needs of > real-world > customers, that's tough. The customers had better find some other > solution." > > With all due respect, I don't think this will further the cause of > CORBA. > No product, organization, or architecture can afford to ignore the > legitimate requests of its customers. If we do, they will indeed go > and > find other solutions and I don't think we would want that to happen. Simon, I have no problem at all with making CORBA better. I do have a problem with things that are piled into the spec without sufficient thought and are no more than a special hack for a special problem. That way, we will lose the integrity of the architecture. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 23 Mar 2000 22:34:02 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Peter Walker CC: Michi Henning , Paul Kyzivat , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <38DA931F.149E6D73@eng.Sun.COM> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: U?Pe9OpH!!Xc7!!%1'e9 Peter, Peter Walker wrote: > > Michi Henning wrote: > > > > Peter, come on, own up to it. You just wish I'd sleep like Rip van > Winkle :-) > > I can just see the headlines - "Human time capsule wakes to find an > all > Java world" :-) :-) yes, yes, I know - gratuitous :-) > > > On a serious note - I do wonder whether the information/data to be > conveyed in the manner suggested will be so variable as to make any > fix/hack we might make useless in all but the most trivial cases. > Anyone, Simon care to elaborate on the use cases here and indicate > how > closed or well defined the usage is likely to be ??..... > Here are the use cases of which I'm aware: 1. RMI-IIOP exceptions that map to CORBA system exceptions. For > example, an EJB throws a javax.jta.TransactionRolledBack exception to its EJB container. The EJB container rethrows this as a CORBA TRANSACTION_ROLLEDBACK exception which flows back to the EJB client over IIOP as a system exception. The client ORB rethrows this to the client application as a javax.jta.TransactionRolledBack exception, as specified in the Java to IDL mapping. Unfortunately the reason string placed in the original exception by the EJB has been lost and is not available to the client. 2. IDL/Java system exceptions that are constructed by a CORBA Java server application by calling the constructor that takes a reason string. The client gets the system exception, but without the reason string. 3. Maybe there are other use cases for other language combinations but I don't think I am the best person to articulate them. Case 1 could occur with a C++ CORBA client accessing an EJB but in this case I don't think there would be such a strong expectation that the server's reason string be preserved and handed back to the client. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Thu, 23 Mar 2000 17:34:04 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning Cc: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: /^,!!#Oi!!GiR!!b1a!! Michi Henning wrote: > On Thu, 23 Mar 2000, Jishnu Mukerji wrote: > > > Michi Henning wrote: > > > > > It's a *service* context, not an application or language context. > > > > > > > Currently, there are 10 standard service contexts defined. They are: > > > [...] > > > Based on this evidence I strongly suspect that the position being taken by Michi > > regarding the purpose of Service Contexts is not sustainable, unless of course he is > > using the term Service in a way that I don't quite understand. > > You are right. Clearly, I can't sit here and claim that the contexts are > for services only. (Although I *will* maintain that's what they initially > were intended for, so there! ;-) Actually, the confusion comes from the use of the term "Service" with slightly different meaning in different contexts. In the context of Chapter 13 I believe the term "Service" refers to "ORB Service" as described in section 13.2. Within that context all of the uses that service contexts have been put to, actually in some sense do carry an "ORB service" related context. > I read through the other messages in this thread. My feeling is that the > entire idea would be a lot more useful (and architecturally more palatable) > if the feature were > > - not restricted to Java with RMI over IIOP only > > - we had a standardized format for the exception info > > - we had an extensible format for the exception info > > - we had a number of standardized tags/values that describe various > things about an exception > > So, instead of arguing, Michi is going to make a 180 degree turn and change > to making constructive suggestions. (If we have to do this, we should at > least do it properly...) Thank you. I knew we could come around to that sooner or later.:-) At least notionally, if one were developing an "ORB Service" for richer exception handling, then it would be appropriate to have one or more service contexts associated with such an ORB service. I would be cautious though of doing this sort of a thing through a revision process. My preference would be to do an RFP or RFC if this is cosnidered to be a pressing issue. > I think that an exception context with a defined tag *might* be useful > for debugging. I also think that the format should be extensible and probably > use name-value pairs for various interesting things, for example: > > - stack trace > - source file and line number > - some sort of human-readable message > - domain name and port number of the sending server > - process/thread ID > - signal mask > - ... > > These are just wild ideas, and I would expect that all of these would be > optional. There are still issues about things like: > > - Is the feature useful enough to warrant adding it? > - Are the localization issues important? (Probably not, if we accept > that this is a debugging aid.) > - How do the various language mappings make this information available > to the client? I agree. I have actually been thinking through the deeper architectural issue that is hiding behind some of the specific discussion regarding the details of carrying exception related info.In that context, I would still like to keep the door ajar to allow specific environment interworking related service contexts. Ideally, it would be nice to have these things work with all languages, but I would feel terrible if CORBA were to loose a significant market opportunity just because we did not want to address a *legitimate* need of a particular extremely popular environment. I think we should evaluate such cases carefully and reach a considered conclusion instead of getting stuck in dogmas. A flexible, extensible architecture that is carefully monitored is likely to survive much longer and evolve into spectacular new areas of application, than a dogmatically guarded one. Conversely a mindlessly free for all approach to such things would also be bad. What we need is a balanced middle path, which is what makes the AB job such a challange. I believe that the entire edifice of interoperability (and indeed any of the myriads of transparencies) in CORBA is built around the notion of interoperability domains. Within a given domain one is able to provide certain levels of each of the important transparencies. For OMG on the whole, it is a good thing if we can get popular environments to ride on the "protocol part" of CORBA without forcing them to give up the transparencies that are near and dear to that environment, even though all of these do not map to every other language environment supported by CORBA. Yes, there should a minimum LCD set of transparencies that should be maintained across the board, but islands of higher than LCD transparencies within well defined domains should not necessarily be discouraged out of hand. Such islands are completely consistent with the overall domain based interoperability architecture on which CORBA interoperability is based. That, of course is just my humble opinion. Thanks, Jishnu. From: Paul Kyzivat To: interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Thu, 23 Mar 2000 17:43:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: D5B!!BDn!!%]a!! From: Simon Nash [mailto:nash@hursley.ibm.com] > Michi, > There's no need to require the use of ASCII. The char/string > codeset is negotiable, but not the natural language in the string. > I think the choice of language should be left to the application > rather than requiring it to be English. Simon, I am afraid the codeset is not negotiable for the strings in a service context. Service contexts are encapsulations, and the codeset for characters and strings in encapsulations is the default. There is also a related interop rtf issue in progress (or did we just vote it?). With it, codeset for particular uses of encapsulations could be declared as part of their definition. But that then is fixed rather than negotiable. X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 23 Mar 2000 15:23:38 -0800 To: Peter Walker , Michi Henning From: Edward Cobb Subject: Re: Transferring Java exception reason string across the wire Cc: butek@us.ibm.com, interop@omg.org, java-rtf@omg.org In-Reply-To: <38D95F01.9B880144@eng.Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: 3Z/!!~?R!!aB>e9hP"e9 I've been away from my E-mail for the last two days and have just gotten through the myriad of message on this particular topic. I'd like to suggest to those of you bashing Russ' proposal that you walk over to your marketing departments and ask them what's really going on in the industry today (or read some analysts reports if you don't have or can't find your marketing folks). 1. Java use is growing like wildfire, with an uptake faster than any prior programming language in history 2. EJB and the J2EE APIs are the preferred way of building enterprise applications in Java and industry acceptance (as measure by product inventory) is close to (if not already exceeding) the total acceptance of CORBA in its ten year history. CORBA, as a programming interface for Java, will continue to decline and ultimately disappear as J2EE matures. 3. In this environment, there are large numbers of people who have already proclaimed CORBA as irrelevant, if not dead, given the overwhelming acceptance of Java 4. In a Java-only world, CORBA has much less to offer than it has in a multi-language world (that's a technical fact) One of the few things it does has to offer is proven interoperability. Multible OMG technologies have been extended to provide this interoperability (RMI over IIOP, Java to IDL, among others). But, as Michi points out, most CORBA technology shows its C and C++ lineage. A mark of a successful standards organization is its ability to adapt to changes in the marketplace. Those that don't go out of business or are subsumed by others (X/Open, OSF, to name two). The world is not the same as it was ten years ago. If we insist on pretending that it is, its not a matter of "if" CORBA is irrelevant, its only a matter of "when." Russ' proposal can be viewed as a "hack" in the architectural purist sense. The right thing to do is go back and make exceptions first class objects (Russ proposed that as well a while back with almost as violent a reaction). Such a radical solution is not without precedent in the OMG (can you say POA?). Given the rising importance of Java, this and other radical solutions should be considered, although these are not appropriate for an RTF. Russ' solution solves a real customer problem for the largest segment of the CORBA community and one, that BEA at least, is interest in keeping. The OMG has already gone to great lengths to portray the Java and CORBA communities as synergistic and complementary. It would be a shame to have the same organization drive a wedge between them because it refuses to adapt to the changing market reality. Frankly, I don't care if we can do this cross-language as long as we have a Java solution. If we go back and make exceptions first class objects, we can deal with the cross-language issue then. At 04:02 PM 3/22/00 -0800, Peter Walker wrote: >Michi Henning wrote: >> >> The look and feel clearly came from the C/C++ world. Tough. That's the look >> and feel we have. If you don't like that, don't use CORBA. >> > >;-) > >Darn I can't get an emoticon to fit the mood :-) > >Pj. > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 23 Mar 2000 16:27:03 -0800 To: Michi Henning , Simon Nash From: Edward Cobb Subject: Re: Transferring Java exception reason string across the wire Cc: Peter Walker , butek@us.ibm.com, interop@omg.org, java-rtf@omg.org In-Reply-To: References: <38DA61ED.38486DED@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: *igd98F%!!j!9e9O)$e9 I observe that an irrevelant architecture with integrity is of considerably less value than a relevant architecture with some loss of integrity. Of course, a relevant architecture with integrity .... At 08:09 AM 3/24/00 +1000, Michi Henning wrote: >On Thu, 23 Mar 2000, Simon Nash wrote: > >> Michi, >> I am disturbed by the tone of some of your recent comments. They seem to >> say "CORBA is the way it is. If it doesn't meet certain needs of real-world >> customers, that's tough. The customers had better find some other solution." >> >> With all due respect, I don't think this will further the cause of CORBA. >> No product, organization, or architecture can afford to ignore the >> legitimate requests of its customers. If we do, they will indeed go and >> find other solutions and I don't think we would want that to happen. > >Simon, > >I have no problem at all with making CORBA better. I do have a problem with >things that are piled into the spec without sufficient thought and are no >more than a special hack for a special problem. That way, we will lose the >integrity of the architecture. > > Cheers, > > Michi. >-- >Michi Henning +61 7 3891 5744 >Object Oriented Concepts +61 4 1118 2700 (mobile) >Suite 4, 904 Stanley St +61 7 3891 5009 (fax) >East Brisbane 4169 michi@ooc.com.au >AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** To: Simon Nash cc: Michi Henning , Paul Kyzivat , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: Your message of "Thu, 23 Mar 2000 14:43:59 PST." <38DA62FE.BD6B57CC@hursley.ibm.com> From: Bill Janssen Message-Id: <00Mar23.163934pst."3686"@watson.parc.xerox.com> Date: Thu, 23 Mar 2000 16:39:45 PST Content-Type: text X-UIDL: 7@6e9AD&e9X!/e9p^ld9 > I think the choice > of language should be left to the application rather than requiring > it to > be English. Simon, What's the `application' here? All we have to play with are clients, servers, interfaces, language mappings, and ORBs. The client and server together make up an `application', I guess. So should they both be involved in the choice of the language? And if so, how? Bill To: Peter Walker cc: Michi Henning , Simon Nash , Paul Kyzivat , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire In-Reply-To: Your message of "Thu, 23 Mar 2000 14:47:17 PST." <38DA931F.149E6D73@eng.Sun.COM> From: Bill Janssen Message-Id: <00Mar23.164633pst."3686"@watson.parc.xerox.com> Date: Thu, 23 Mar 2000 16:46:40 PST Content-Type: text X-UIDL: [*7e9TBTd9=da!!"6?!! > On a serious note - I do wonder whether the information/data to be > conveyed in the manner suggested will be so variable as to make any > fix/hack we might make useless in all but the most trivial cases. Much like these mail headers that say, "In reply to your message of ..." but fail to give the Message-ID. Or we might have cases analogous to Microsoft Outlook, which doesn't fill in either the "References" header or the "In-Reply-To" header, and thus needlessly prevents a lot of threading analysis. That would be when the receiving ORB begins to rely on the information in the context, but the sending ORB doesn't send it (presumably for good and sufficient reasons -- I'm sure there's a reason Outlook doesn't populate those header fields even though every other mailer in the world does). Bill Date: Thu, 23 Mar 2000 23:09:31 -0800 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Jishnu Mukerji , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: /D3e9Ib_!!k_I!!1>^!! Michi - There are some very good ideas here and certainly it was worth turning the ship around 180d. (1) On the content - stack trace - source file and line number - some sort of human-readable message - domain name and port number of the sending server ^ How would this work with firewalls/proxies - process/thread ID - signal mask - ... - implementation language ?:0) (2) On the questions: - Is the feature useful enough to warrant adding it? The call for it is widespread. It's certainly useful for debugging and failure reporting purposes. - Are the localization issues important? (Probably not, if we accept that this is a debugging aid.) They can be for failure reporting although system integrators will have to take care of this. We have to try really hard to make it any more impossible. - How do the various language mappings make this information available to the client? This is clear for the case of Java. For other language mappings, some further definition work may be required. In the worst (and the best for debuggging) case, the contents of the exception context can be dumped onto the requesting client. What's done with it is not as important as what it might contain in each of its fields. Language mappings can further refine the intended use of each field for that particular language. Regards, Max Michi Henning wrote: > On Thu, 23 Mar 2000, Jishnu Mukerji wrote: > > > Michi Henning wrote: > > > > > It's a *service* context, not an application or language context. > > > > > > > Currently, there are 10 standard service contexts defined. They are: > > > [...] > > > Based on this evidence I strongly susepct that the position being taken by Michi > > reagrding the purpose of Service Contexts is not sustainable, unless of course he is > > using the term Service in a way that I don't quite understand. > > You are right. Clearly, I can't sit here and claim that the contexts are > for services only. (Although I *will* maintain that's what they initially > were intended for, so there! ;-) > > I read through the other messages in this thread. My feeling is that the > entire idea would be a lot more useful (and architecturally more palatable) > if the feature were > > - not restricted to Java with RMI over IIOP only > > - we had a standardized format for the exception info > > - we had an extensible format for the exception info > > - we had a number of standardized tags/values that describe various > things about an exception > > So, instead of arguing, Michi is going to make a 180 degree turn and change > to making constructive suggestions. (If we have to do this, we should at > least do it properly...) > > I think that an exception context with a defined tag *might* be useful > for debugging. I also think that the format should be extensible and probably > use name-value pairs for various interesting things, for example: > > - stack trace > - source file and line number > - some sort of human-readable message > - domain name and port number of the sending server > - process/thread ID > - signal mask > - ... > > These are just wild ideas, and I would expect that all of these would be > optional. There are still issues about things like: > > - Is the feature useful enough to warrant adding it? > - Are the localization issues important? (Probably not, if we accept > that this is a debugging aid.) > - How do the various language mappings make this information available > to the client? > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 23 Mar 2000 23:49:18 -0800 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <9B164B713EE9D211B6DC0090273CEEA926BD47@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 9=V!!o(%e9NJU!!nCl!! Paul - Good point. The issues up for vote that might affect the current question are 2708 2784 So, I recommend people to review their vote on these two. The additions they bear require a pre-definition of the transmission codeset not the conversion or native codesets of encapsulated string/char data. Since codeset negotiation is for the discovery of a valid transmission codeset among ORBs, not for application level or native codesets, the proper transmission of strings still seems to be a system integrators issue since the idea is that it will be viewable at application level to the client for failure reporting and possibly debugging purposes. However, requiring a constraint on the transmission codeset for a "reason" string service context (or any other encapsulated string/char data) might put unnecessary burden on ORB developers, who could have found some transmission codeset but not the one that would have been required in the definition of the encapsulation, given positive vote on the above two issues. If there's a default transmission codeset which all orb's must support, then the issue might become a non-issue but I don't remember seeing that anywhere. Regards, Max Paul Kyzivat wrote: > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > > Michi, > > There's no need to require the use of ASCII. The char/string > > codeset is negotiable, but not the natural language in the string. > > I think the choice of language should be left to the application > > rather than requiring it to be English. > > Simon, > > I am afraid the codeset is not negotiable for the strings in a service > context. Service contexts are encapsulations, and the codeset for characters > and strings in encapsulations is the default. > > There is also a related interop rtf issue in progress (or did we just vote > it?). With it, codeset for particular uses of encapsulations could be > declared as part of their definition. But that then is fixed rather than > negotiable. From: Paul Kyzivat To: java-rtf@omg.org, interop@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Fri, 24 Mar 2000 08:57:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ,7'e9e(\!!R:o!!S>)e9 > From: Edward Cobb [mailto:ed.cobb@santa-clara.beasys.com] > I observe that an irrevelant architecture with integrity is of > considerably less value than a relevant architecture with some loss > of > integrity. IMO one of the attractive features of Java is that it has some architectural integrity. (Moreso than C++, which is riddled with pragmatic accomodations to C.) I wouldn't think the Java community would want to give that up so easily. > Of course, a relevant architecture with integrity .... This is of course what we should be striving for. Paul Date: Fri, 24 Mar 2000 14:41:37 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: Michi Henning , Paul Kyzivat , interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <00Mar23.163934pst."3686"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: oI6e9^HE!!m64!!1M3!! Bill, Yes, the client and server together make up an application and they should decide in some manner not (currently) prescribed by CORBA specs what language to use for these text messages. Simon Bill Janssen wrote: > > > I think the choice > > of language should be left to the application rather than > requiring it to > > be English. > > Simon, > > What's the `application' here? All we have to play with are > clients, > servers, interfaces, language mappings, and ORBs. The client and > server together make up an `application', I guess. So should they > both be involved in the choice of the language? And if so, how? > > Bill -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: Paul Kyzivat To: interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Fri, 24 Mar 2000 10:07:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Ie[d9`E#!!IRN!!"SB!! > From: M. Mortazavi [mailto:masood.mortazavi@eng.sun.com] > the above two issues. If there's a default transmission > codeset which all orb's must > support, then the issue might become a non-issue but I don't > remember seeing that > anywhere. All orbs must support 8859-1 (did I get that right?) for the encoding of strings in message headers and in all the currently defined encapsulations. From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: interop@omg.org, java-rtf@omg.org Message-ID: <852568AC.0058D916.00@d54mta08.raleigh.ibm.com> Date: Fri, 24 Mar 2000 10:02:14 -0600 Subject: Re: Transferring Java exception reason string across the wire Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: ;;W!!(_4e9WTj!!N8ad9 Wow. What a can of worms I opened! (I was out sick most of yesterday, and this morning's return to email has been entertaining.) I don't believe we're adamant about any particular solution to this issue at this point (though we're prototyping our proposal). I gave the proposal I did for a number of reasons: 1. it would be easy to add; 2. it's based on prior art; 3. it wouldn't break existing code; 4. we thought - erroneously - that restricting it to Java would make it more palatable. #3 is the only important issue, though #1 would be nice. Russell Butek butek@us.ibm.com From: "Rutt, T E (Tom)" To: interop@omg.org, java-rtf@omg.org, "'butek@us.ibm.com'" Subject: RE: Transferring Java exception reason string across the wire Date: Fri, 24 Mar 2000 13:27:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: ^m(!!33kd9EW2e9>^Sd9 > ---------- > From: butek@us.ibm.com[SMTP:butek@us.ibm.com] > Sent: Friday, March 24, 2000 11:02 AM > To: interop@omg.org; java-rtf@omg.org > Subject: Re: Transferring Java exception reason string across > the > wire > > > > Wow. What a can of worms I opened! (I was out sick most of > yesterday, > and > this morning's return to email has been entertaining.) > > I don't believe we're adamant about any particular solution to this > issue > at this point (though we're prototyping our proposal). I gave the > proposal > I did for a number of reasons: > > 1. it would be easy to add; > 2. it's based on prior art; > 3. it wouldn't break existing code; > 4. we thought - erroneously - that restricting it to Java would make > it > more palatable. > As it turns out, adding this new service context for use with GIOP 1.2 > would be putting it in a totally optional status. I would not want to rev to > GIOP 1.3 just to add recongition of this new standard service context for Java. The conformance claims for this new service context would have to be clarified. -- Tom Rutt Lucent Technologies - Bell Labs Rm 4L-336 Tel: +1(732)949-7862 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA email: terutt@lucent.com > #3 is the only important issue, though #1 would be nice. > > Russell Butek > butek@us.ibm.com > > Date: Fri, 24 Mar 2000 19:00:13 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Rutt, T E (Tom)" CC: interop@omg.org, java-rtf@omg.org, "'butek@us.ibm.com'" > Subject: Re: Transferring Java exception reason string across the wire References: > > Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: M)E!!#~jd9KSa!!^[C!! Tom, By a "totally optional status" I assume you mean that compliant GIOP 1.2 ORBs could ignore it if they like, but could also accept it. That sounds OK to me. Simon "Rutt, T E (Tom)" wrote: > > > ---------- > > From: butek@us.ibm.com[SMTP:butek@us.ibm.com] > > Sent: Friday, March 24, 2000 11:02 AM > > To: interop@omg.org; java-rtf@omg.org > > Subject: Re: Transferring Java exception reason string across > the > > wire > > > > > > > > Wow. What a can of worms I opened! (I was out sick most of > yesterday, > > and > > this morning's return to email has been entertaining.) > > > > I don't believe we're adamant about any particular solution to > this issue > > at this point (though we're prototyping our proposal). I gave the > > proposal > > I did for a number of reasons: > > > > 1. it would be easy to add; > > 2. it's based on prior art; > > 3. it wouldn't break existing code; > > 4. we thought - erroneously - that restricting it to Java would > make it > > more palatable. > > > As it turns out, adding this new service context for use with GIOP > 1.2 would > be > putting it in a totally optional status. I would not want to rev to > GIOP > 1.3 just to add > recongition of this new standard service context for Java. > > The conformance claims for this new service context would have to be > clarified. > > -- > Tom Rutt > Lucent Technologies - Bell Labs > Rm 4L-336 Tel: +1(732)949-7862 > 101 Crawford Corner Rd Fax: +1(732)949-1196 > Holmdel NJ, 07733 USA email: terutt@lucent.com > > > #3 is the only important issue, though #1 would be nice. > > > > Russell Butek > > butek@us.ibm.com > > > > -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: "Rutt, T E (Tom)" To: Bill Janssen , "'Simon Nash'" Cc: Michi Henning , Paul Kyzivat , interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Fri, 24 Mar 2000 14:36:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: ?*F!!0DPd9eiYd9aN9e9 > ---------- > From: Simon Nash[SMTP:nash@hursley.ibm.com] > Sent: Friday, March 24, 2000 9:41 AM > To: Bill Janssen > Cc: Michi Henning; Paul Kyzivat; interop@omg.org; java-rtf@omg.org > Subject: Re: Transferring Java exception reason string across > the > wire > > Bill, > Yes, the client and server together make up an application and they > should > decide in some manner not (currently) prescribed by CORBA specs what > language > to use for these text messages. > > Simon > > Bill Janssen wrote: > > > > > I think the choice > > > of language should be left to the application rather than > requiring it > to > > > be English. > Since service contexts use encapsulations, the default (according to > the issue resolution we are voting in vote 1) encoding is GIOP 1.0 (which does not include international char sets beyond latin-1). If you want other than giop 1.0 for the encapsulation, then you must state the giop version in the specification of the encapsulation, and the TCS-c and/or TCS-w isf strings or wstrings are encapsulated in the service context. -- Tom Rutt Lucent Technologies - Bell Labs Rm 4L-336 Tel: +1(732)949-7862 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA email: terutt@lucent.com > > > > Simon, > > > > What's the `application' here? All we have to play with are > clients, > > servers, interfaces, language mappings, and ORBs. The client and > > server together make up an `application', I guess. So should they > > both be involved in the choice of the language? And if so, how? > > > > Bill > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > From: "Rutt, T E (Tom)" To: Michi Henning , "'jis@fpk.hp.com'" > Cc: interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Fri, 24 Mar 2000 15:19:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: *pid9^, ---------- > From: Jishnu Mukerji[SMTP:jis@fpk.hp.com] > Reply To: jis@fpk.hp.com > Sent: Thursday, March 23, 2000 5:34 PM > To: Michi Henning > Cc: interop@omg.org; java-rtf@omg.org > Subject: Re: Transferring Java exception reason string across > the > wire > > Michi Henning wrote: > > > On Thu, 23 Mar 2000, Jishnu Mukerji wrote: > > > > > Michi Henning wrote: > > > > > > > It's a *service* context, not an application or language > context. > > > > > > > > > > Currently, there are 10 standard service contexts defined. They > are: > > > > > [...] > > > I have actually been thinking through the deeper architectural issue > that > is hiding behind > some of the specific discussion regarding the details of carrying > exception related > info.In that context, I would still like to keep the door ajar to > allow > specific > environment interworking related service contexts. Ideally, it would > be > nice to have these > things work with all languages, but I would feel terrible if CORBA > were to > loose a > significant market opportunity just because we did not want to > address a > *legitimate* need > of a particular extremely popular environment. > Thanks, > > Jishnu. > This problem is coming from reverse java to corba. This is not a language binding, but is , in fact, an interworking spec, just like com/corba and tmn/corba. the use of service context in com/corba was for interworking, not language binding. The reverse java was never a language mapping, and as such should be viewed as interworking, which I believe gives it more leaway. -- Tom Rutt Lucent Technologies - Bell Labs Rm 4L-336 Tel: +1(732)949-7862 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA email: terutt@lucent.com From: george_david Message-Id: <200003291537.HAA00539@jasper.loc251.tandem.com> Subject: RE: Transferring Java exception reason string across the wire To: interop@omg.org, java-rtf@omg.org Date: Wed, 29 Mar 100 07:37:47 -0800 (PST) Return-Recept-To: davidg@loc201.tandem.com (dave george) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: Dmkd9JcOd9i^Be9kRMd9 Oh dopey me...forgive me for being naive! I had thought that one of the great promises of CORBA was location transparency. Was I misled? Consider the case where the (Java) servant turns out to be local and it throws a BAD_PARAM with a reason string. For this case, the client gets a reason string. Then we consider the case where the servant is remote and it throws a BAD_PARAM with a reason string. Woops, the client doesn't get a reason string. Re-write those CORBA slides and books, folks... the OMG was only kidding...CORBA promises location transparency when it's convenient or whatever. -dave. From: Paul Kyzivat To: interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Wed, 29 Mar 2000 12:48:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: PQTd9]\7e9XbD!!J9 From: george_david [mailto:davidg@jasper.loc251.tandem.com] > Oh dopey me...forgive me for being naive! > > I had thought that one of the great promises of CORBA was > location transparency. > > Was I misled? > > Consider the case where the (Java) servant turns out to > be local and it throws a BAD_PARAM with a reason string. > For this case, the client gets a reason string. > Then we consider the case where the servant is remote > and it throws a BAD_PARAM with a reason string. > Woops, the client doesn't get a reason string. > > Re-write those CORBA slides and books, folks... > the OMG was only kidding...CORBA promises location transparency > when it's convenient or whatever. Don't blame CORBA for that! There is no such thing as a reason string as part of a CORBA BAD_PARAM exception. So a java program wouldn't be doing this, locally or not. I think the issue is a Java RMI program, throwing some java exception that has been *mapped* to BAD_PARAM for purposes of RMI-IOP. Your argument should be with the mapping, not with the transparency of CORBA itself. From: george_david Message-Id: <200003291829.KAA03659@jasper.loc251.tandem.com> Subject: Re: Transferring Java exception reason string across the wire To: interop@omg.org, java-rtf@omg.org Date: Wed, 29 Mar 100 10:29:23 -0800 (PST) In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BD7F@bos1.noblenet.com> from "Paul Kyzivat" at Mar 29, 0 12:48:48 pm Return-Recept-To: davidg@loc201.tandem.com (dave george) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: U#?e9QoIe9H)+!!b;^d9 Paul Kyzivat writes: > > > From: george_david [mailto:davidg@jasper.loc251.tandem.com] > > > Oh dopey me...forgive me for being naive! > > > > I had thought that one of the great promises of CORBA was > > location transparency. > > > > Was I misled? > > > > Consider the case where the (Java) servant turns out to > > be local and it throws a BAD_PARAM with a reason string. > > For this case, the client gets a reason string. > > Then we consider the case where the servant is remote > > and it throws a BAD_PARAM with a reason string. > > Woops, the client doesn't get a reason string. > > > > Re-write those CORBA slides and books, folks... > > the OMG was only kidding...CORBA promises location transparency > > when it's convenient or whatever. > > Don't blame CORBA for that! > > There is no such thing as a reason string as part of a CORBA > BAD_PARAM > exception. So a java program wouldn't be doing this, locally or not. > > I think the issue is a Java RMI program, throwing some java > exception that > has been *mapped* to BAD_PARAM for purposes of RMI-IOP. Your > argument should > be with the mapping, not with the transparency of CORBA itself. > My bad, the mapping is broken. It's sometimes difficult to distinguish between a mapping and CORBA itself. As Henning and Vinoski point out in their book, The mapping from IDL to C++ must address... The mapping must preserve location transparency... From: Paul Kyzivat To: interop@omg.org, java-rtf@omg.org Subject: RE: Transferring Java exception reason string across the wire Date: Thu, 30 Mar 2000 16:49:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: kb0e9ooGe9a!p!!L<"!! > From: Simon Nash [mailto:nash@hursley.ibm.com] > > There is no such thing as a reason string as part of a > CORBA BAD_PARAM > > exception. So a java program wouldn't be doing this, locally or > not. > > > Not true. See below. > > > I think the issue is a Java RMI program, throwing some java > exception that > > has been *mapped* to BAD_PARAM for purposes of RMI-IOP. > Your argument should > > be with the mapping, not with the transparency of CORBA itself. > > > It's not just an RMI issue. In the IDL to Java mapping, CORBA > system > exceptions like BAD_PARAM get mapped to Java language exceptions and > > therefore have detail strings like all other Java exceptions. These > detail strings are lost when the exceptions are marshalled remotely, > but not when they are thrown locally.. OK - then it is a problem with the IDL-to-Java language mapping too. You mapped a CORBA exception to something that has a data member not present in the wire representation of exception. Even so, I imagine this isn't a problem with corba exceptions that are received in Java - the string member is presumably derived from data on the wire, like the minor code or something. And it probably isn't a problem with exceptions that are received and then propagated because the derived information is simply lost and reconstructed at the other end. I presume the real problem is the ability to explicitly set a string member on an exception before throwing it. This should be judged a problem with the java mapping rather than with corba because corba never intended to have a way to do it. Of course you java guys can (as you are) come forward asking for extensions to corba because it is important to you. But that something altogether different. Paul Date: Thu, 30 Mar 2000 22:47:32 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: interop@omg.org Subject: Issue 3405 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: oAid9/i\d9$W*e9K;g!! Here's a proposal for this issue: 1. Add a new standard service context called ExceptionData. This service context may be sent on Reply messages with a reply_status of SYSTEM_EXCEPTION or USER_EXCEPTION, or on LocateReply messages with a locate_status of LOC_SYSTEM_EXCEPTION. 2. This service context is a CDR encapsulation of a sequence of ExceptionDataItem structures, encoded using GIOP 1.1 with a TCS-C of ISO8859-1 and a TCS-W of UCS-2. 3. The ExceptionDataItem structure is defined as follows: typedef unsigned long ExceptionItemId; struct ExceptionDataItem { ExceptionItemId item_id; sequence item_data; }; const ExceptionItemId DetailMessage = 0; // others may be added in future 4. The following pairs of exception data IDs and items are currently defined: item_id - DetailMessage item_data - wstring This would be all that's specified by the interop RTF. Language mapping RTFs could specify semantics and marshalling/unmarshalling rules for exception data items that may be sent in this service context. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Date: Thu, 30 Mar 2000 18:05:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 1I"!!5$2e928h!!JT5e9 Simon, Two questions (actually 2.5) for you: 1) do you really want this to apply to USER_EXCEPTION? 1a) if so, what should happen to this data if the exception is not known and is put into an Any in an UnknownUserException? 2) you are trying to put a wstring into an encapsulation. The rules (revision just voted) are that encapsulations are done using giop 1.0 (doesn't support wstring) unless explicitly stated. If you state some other giop version and use wchars or wstrings, then you must specify the codeset to be used. Are you prepared to be the guinea pig for that? (This codeset thing is going to keep biting us until we kill it!) Paul > -----Original Message----- > From: Simon Nash [mailto:nash@hursley.ibm.com] > Sent: Thursday, March 30, 2000 4:48 PM > To: interop@omg.org > Subject: Issue 3405 > > > Here's a proposal for this issue: > > 1. Add a new standard service context called ExceptionData. > This service > context may be sent on Reply messages with a reply_status of > SYSTEM_EXCEPTION or USER_EXCEPTION, or on LocateReply > messages with a > locate_status of LOC_SYSTEM_EXCEPTION. > > 2. This service context is a CDR encapsulation of a sequence of > ExceptionDataItem structures, encoded using GIOP 1.1 with a TCS-C > of ISO8859-1 and a TCS-W of UCS-2. > > 3. The ExceptionDataItem structure is defined as follows: > typedef unsigned long ExceptionItemId; > struct ExceptionDataItem { > ExceptionItemId item_id; > sequence item_data; > }; > const ExceptionItemId DetailMessage = 0; > // others may be added in future > > 4. The following pairs of exception data IDs and items are > currently defined: > item_id - DetailMessage > item_data - wstring > > This would be all that's specified by the interop RTF. > Language mapping > RTFs could specify semantics and marshalling/unmarshalling rules for > exception data items that may be sent in this service context. > > Simon > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > Sender: jbiggar@corvette.floorboard.com Message-ID: <38E3E950.BEB3C807@floorboard.com> Date: Thu, 30 Mar 2000 15:54:56 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interop@omg.org Subject: Re: Issue 3405 References: <9B164B713EE9D211B6DC0090273CEEA926BD8D@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: o4d!!elXd9\<+e9I8)!! Paul Kyzivat wrote: > > Simon, > > Two questions (actually 2.5) for you: > > 1) do you really want this to apply to USER_EXCEPTION? > > 1a) if so, what should happen to this data if the exception is not > known > and is put into an Any in an UnknownUserException? > > 2) you are trying to put a wstring into an encapsulation. > The rules (revision just voted) are that encapsulations are > done using giop 1.0 (doesn't support wstring) unless explicitly > stated. If you state some other giop version and use wchars > or wstrings, then you must specify the codeset to be used. > Are you prepared to be the guinea pig for that? Didn't he just do that in his proposal? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 31 Mar 2000 17:25:08 +1000 (EST) From: Michi Henning To: Simon Nash cc: interop@omg.org Subject: Re: Issue 3405 In-Reply-To: <38E3CB74.39CD9AC@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: )Vdd9d++!!!?X!!%":!! On Thu, 30 Mar 2000, Simon Nash wrote: > Here's a proposal for this issue: > > 1. Add a new standard service context called ExceptionData. This > service > context may be sent on Reply messages with a reply_status of > SYSTEM_EXCEPTION or USER_EXCEPTION, or on LocateReply messages > with a > locate_status of LOC_SYSTEM_EXCEPTION. > > 2. This service context is a CDR encapsulation of a sequence of > ExceptionDataItem structures, encoded using GIOP 1.1 with a TCS-C > of ISO8859-1 and a TCS-W of UCS-2. > > 3. The ExceptionDataItem structure is defined as follows: > typedef unsigned long ExceptionItemId; > struct ExceptionDataItem { > ExceptionItemId item_id; > sequence item_data; > }; > const ExceptionItemId DetailMessage = 0; > // others may be added in future > > 4. The following pairs of exception data IDs and items are currently > defined: > item_id - DetailMessage > item_data - wstring Suggestion: would it be better to make a sequence of ExceptionDataItem and send that with the ExceptionData tag? That way, we wouldn't have to add a new tag every time we want another item for exceptions. > This would be all that's specified by the interop RTF. Language mapping > RTFs could specify semantics and marshalling/unmarshalling rules for > exception data items that may be sent in this service context. Is that really a job for the language mappings? Certainly, I would expect at least the marshaling rules to be defined by interop, and have the language mappings deal with the language bindings. So, don't get me wrong, I'm not trying to shoot this down this time around ;-) I just want to make sure that it is well-defined and easily extensible. Basically, I think we should have a single service context tag for exception data. That tag identifies a sequence of pairs (instead of a single pair). As shown, each pair contains an identifier (an unsigned long) and an octet sequence. That octet sequence is an encapsulation of the actual data, so it can be dealt with even in the absence of type knowledge. One final glitch: If we have f() which calls g() which calls h(), and h() throws, what are the responsibilities of the ORB that implements g() if g() simply lets the exception through, but g's ORB doesn't understand the exception data? Don't we need a rule that obliges an ORB to pass the exception data through unchanged if an intermediate operation doesn't rethrow? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 30 Mar 2000 21:49:37 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interop@omg.org, java-rtf@omg.org Subject: Re: Transferring Java exception reason string across the wire References: <9B164B713EE9D211B6DC0090273CEEA926BD7F@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 'j:!!hJ4!!ff_d9"C$"! Paul, Paul Kyzivat wrote: > > > From: george_david [mailto:davidg@jasper.loc251.tandem.com] > > > Oh dopey me...forgive me for being naive! > > > > I had thought that one of the great promises of CORBA was > > location transparency. > > > > Was I misled? > > > > Consider the case where the (Java) servant turns out to > > be local and it throws a BAD_PARAM with a reason string. > > For this case, the client gets a reason string. > > Then we consider the case where the servant is remote > > and it throws a BAD_PARAM with a reason string. > > Woops, the client doesn't get a reason string. > > > > Re-write those CORBA slides and books, folks... > > the OMG was only kidding...CORBA promises location transparency > > when it's convenient or whatever. > > Don't blame CORBA for that! > > There is no such thing as a reason string as part of a CORBA > BAD_PARAM > exception. So a java program wouldn't be doing this, locally or not. > Not true. See below. > I think the issue is a Java RMI program, throwing some java exception that > has been *mapped* to BAD_PARAM for purposes of RMI-IOP. Your argument should > be with the mapping, not with the transparency of CORBA itself. > It's not just an RMI issue. In the IDL to Java mapping, CORBA system exceptions like BAD_PARAM get mapped to Java language exceptions and therefore have detail strings like all other Java exceptions. These detail strings are lost when the exceptions are marshalled remotely, but not when they are thrown locally.. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb To: Simon Nash cc: interop@omg.org Subject: Re: Issue 3405 In-Reply-To: Your message of "Thu, 30 Mar 2000 13:52:55 PST." <38E3CB74.39CD9AC@hursley.ibm.com> From: Bill Janssen Message-Id: <00Mar31.185159pst."3432"@watson.parc.xerox.com> Date: Fri, 31 Mar 2000 18:52:14 PST Content-Type: text X-UIDL: QkK!!FO6e9J+C!!:H=e9 > 2. This service context is a CDR encapsulation of a sequence of > ExceptionDataItem structures, encoded using GIOP 1.1 with a TCS-C > of ISO8859-1 and a TCS-W of UCS-2. I'd prefer TCS-W of UTF-8 on this, for the reasons we've gone into before. Bill From: "Rutt, T E (Tom)" To: Simon Nash , "'Bill Janssen'" Cc: interop@omg.org Subject: RE: Issue 3405 Getting ready to vote Date: Fri, 7 Apr 2000 12:07:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: $gH!!Pkfd9~JTd9D<%"! We need to resolve this last wrinkle before a vote. I believe we have an agreed solution (with Simon's original proposal and Michi's enhancement) but have not agreed on the transfer char set. If we go with UTF-16 we need to clarfiy the BE/LE aspects for the fixed choice. The generic IANA UTF-16 requires sending a special character as the first in the string to help determine endness. If we go with UTF-8 we will not have this problem, since it is byte oriented. Lets focus discussion on this point, so we can put this out to vote. -- Tom Rutt Lucent Technologies - Bell Labs Rm 4L-336 Tel: +1(732)949-7862 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA email: terutt@lucent.com > ---------- > From: Bill Janssen[SMTP:janssen@parc.xerox.com] > Sent: Friday, March 31, 2000 10:52 PM > To: Simon Nash > Cc: interop@omg.org > Subject: Re: Issue 3405 > > > 2. This service context is a CDR encapsulation of a sequence of > > ExceptionDataItem structures, encoded using GIOP 1.1 with a > TCS-C > > of ISO8859-1 and a TCS-W of UCS-2. > > I'd prefer TCS-W of UTF-8 on this, for the reasons we've gone into > before. > > Bill > To: "Rutt, T E (Tom)" cc: Simon Nash , interop@omg.org Subject: Re: Issue 3405 Getting ready to vote In-Reply-To: Your message of "Fri, 07 Apr 2000 09:07:15 PDT." From: Bill Janssen Message-Id: <00Apr7.104038pdt."3432"@watson.parc.xerox.com> Date: Fri, 7 Apr 2000 10:40:45 PDT Content-Type: text X-UIDL: "Z&e92A,e9b^[d9kT If we go with UTF-16 we need to clarfiy the BE/LE aspects for the fixed > choice. The generic IANA UTF-16 requires sending a special character as > the first in the string to help determine endness. Remember that we are not using IANA character sets, we are using the OSF registry. In any case, UTF-16 is defined by ISO, not IANA. There is no provision for a special character as the first in the string to determine endness; UTF-16 is always a big-endian format. Annex F of ISO 10646-1:1993 does recommend prefixing a UTF-16 string with the character "ZERO WIDTH NO-BREAK SPACE" (0xFEFF) *to detect errors*. This big-endianness means that code on Intel platforms will have to byte-swap all characters before sending. Note too that though UTF-16 is sometimes mistakenly thought of as a straightforward 16-bit encoding, it's really not. It's a 16-bit encoding of a 20-bit character space, just as UTF-8 is an 8-bit encoding of a 31-bit character space. So special processing of strings is probably still necessary to map to and from the programming language's form. It's tricky to get this right without reading the ISO specs, but let me again refer you to http://czyborra.com/utf/ for a brief discussion of some of these issues, especially the pros and cons of UTF-8. I'd suggest we just use UTF-8 as the transmission format for both types of strings. It should simplify things overall. Bill From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Getting ready to vote Date: Fri, 7 Apr 2000 15:09:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: j5Qd9~I@e9#ccd9l+Pd9 I am not especially wild about being required to provide support for conversion to/from UTF-8. It is something that I don't see a strong need for elsewhere. Windows and Java both use 16 bit unicode internally, in a flavor consistent with the machine's native byte order. Most unixes normally use 32 bit unicode in machine byte order. I would like to see one choice for TCS-W that will guarantee interoperability. The likely candidates are some variation on UTF-16 and/or UTF-32 that can use the sending system's byte order. Paul > -----Original Message----- > From: Rutt, T E (Tom) [mailto:terutt@lucent.com] > Sent: Friday, April 07, 2000 12:07 PM > To: Simon Nash; 'Bill Janssen' > Cc: interop@omg.org > Subject: RE: Issue 3405 Getting ready to vote > > > We need to resolve this last wrinkle before a vote. > > I believe we have an agreed solution (with Simon's original > proposal and > Michi's enhancement) but have not agreed on the transfer char set. > > If we go with UTF-16 we need to clarfiy the BE/LE aspects for > the fixed > choice. The generic IANA UTF-16 requires sending a special > character as > the first in the string to help determine endness. > > If we go with UTF-8 we will not have this problem, since it is byte > oriented. > > Lets focus discussion on this point, so we can put this out to vote. > > > -- > Tom Rutt > Lucent Technologies - Bell Labs > Rm 4L-336 Tel: +1(732)949-7862 > 101 Crawford Corner Rd Fax: +1(732)949-1196 > Holmdel NJ, 07733 USA email: terutt@lucent.com > > > > > ---------- > > From: Bill Janssen[SMTP:janssen@parc.xerox.com] > > Sent: Friday, March 31, 2000 10:52 PM > > To: Simon Nash > > Cc: interop@omg.org > > Subject: Re: Issue 3405 > > > > > 2. This service context is a CDR encapsulation of a sequence of > > > ExceptionDataItem structures, encoded using GIOP 1.1 > with a TCS-C > > > of ISO8859-1 and a TCS-W of UCS-2. > > > > I'd prefer TCS-W of UTF-8 on this, for the reasons we've > gone into before. > > > > Bill > > > Date: Fri, 07 Apr 2000 16:57:11 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: interop@omg.org Subject: Re: Issue 3405 References: > Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: [O+e9#b+e9"B`!!P4Be9 Michi, Michi Henning wrote: > > On Thu, 30 Mar 2000, Simon Nash wrote: > > > Here's a proposal for this issue: > > > > 1. Add a new standard service context called ExceptionData. This > service > > context may be sent on Reply messages with a reply_status of > > SYSTEM_EXCEPTION or USER_EXCEPTION, or on LocateReply messages > with a > > locate_status of LOC_SYSTEM_EXCEPTION. > > > > 2. This service context is a CDR encapsulation of a sequence of > > ExceptionDataItem structures, encoded using GIOP 1.1 with a > TCS-C > > of ISO8859-1 and a TCS-W of UCS-2. > > > > 3. The ExceptionDataItem structure is defined as follows: > > typedef unsigned long ExceptionItemId; > > struct ExceptionDataItem { > > ExceptionItemId item_id; > > sequence item_data; > > }; > > const ExceptionItemId DetailMessage = 0; > > // others may be added in future > > > > 4. The following pairs of exception data IDs and items are > currently defined: > > item_id - DetailMessage > > item_data - wstring > > Suggestion: would it be better to make a sequence of > ExceptionDataItem and > send that with the ExceptionData tag? That way, we wouldn't have to > add a new tag every time we want another item for exceptions. > I'm not sure how this differs from my proposal. My point 2 above > states that a sequence of ExceptionDataItem structures is sent in an ExceptionData service context. > > This would be all that's specified by the interop RTF. Language mapping > > RTFs could specify semantics and marshalling/unmarshalling rules for > > exception data items that may be sent in this service context. > > Is that really a job for the language mappings? Certainly, I would expect > at least the marshaling rules to be defined by interop, and have the language > mappings deal with the language bindings. > What do you include in marshaling rules? In the case of Java, I would propose the rules: a. the Java detailMessage field is marshaled into an ExceptionDataItem with item_id DetailMessage, and b. if an ExceptionDataItem with item_id DetailMessage is received, it is unmarshaled into the Java detailMessage field. These seem to be the proper domain of language mappings. What else would the interop chapter specify? > So, don't get me wrong, I'm not trying to shoot this down this time around ;-) > I just want to make sure that it is well-defined and easily extensible. > Basically, I think we should have a single service context tag for exception > data. That tag identifies a sequence of pairs (instead of a single pair). > As shown, each pair contains an identifier (an unsigned long) and an > octet sequence. That octet sequence is an encapsulation of the actual data, > so it can be dealt with even in the absence of type knowledge. > Again, I think that is what I am proposing. Please clarify how your suggestion is different. > One final glitch: If we have f() which calls g() which calls h(), and h() > throws, what are the responsibilities of the ORB that implements g() if > g() simply lets the exception through, but g's ORB doesn't understand > the exception data? Don't we need a rule that obliges an ORB to pass > the exception data through unchanged if an intermediate operation doesn't > rethrow? > A pass-through as you suggest would be nice but I think it's going to be tricky to implement. Normally the data would be unmarshaled from the g-h connection and placed in a language exception which is thrown to g. If the ORB can't do this because it doesn't understand the data, where can it put the data that will allow it to be retrieved and sent on the f-g connection when the same exception pops out of g and is caught by the ORB? The ORB could implement a global mapping of language exception objects to not-understood data, but if the language exception is caught and rethrown by g() then this would cause memory leaks. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Fri, 07 Apr 2000 16:59:34 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interop@omg.org Subject: Re: Issue 3405 Getting ready to vote References: <9B164B713EE9D211B6DC0090273CEEA926BDAD@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Y/p+e9 Paul, Don't ORBs have to support both UTF-8 and UTF-16 since these are the fallback codesets for TCS-C and TCS-W? Simon Paul Kyzivat wrote: > > I am not especially wild about being required to provide support for > conversion to/from UTF-8. It is something that I don't see a strong > need for > elsewhere. > > Windows and Java both use 16 bit unicode internally, in a flavor > consistent > with the machine's native byte order. Most unixes normally use 32 > bit > unicode in machine byte order. > > I would like to see one choice for TCS-W that will guarantee > interoperability. The likely candidates are some variation on UTF-16 > and/or > UTF-32 that can use the sending system's byte order. > > Paul > > > -----Original Message----- > > From: Rutt, T E (Tom) [mailto:terutt@lucent.com] > > Sent: Friday, April 07, 2000 12:07 PM > > To: Simon Nash; 'Bill Janssen' > > Cc: interop@omg.org > > Subject: RE: Issue 3405 Getting ready to vote > > > > > > We need to resolve this last wrinkle before a vote. > > > > I believe we have an agreed solution (with Simon's original > > proposal and > > Michi's enhancement) but have not agreed on the transfer char set. > > > > If we go with UTF-16 we need to clarfiy the BE/LE aspects for > > the fixed > > choice. The generic IANA UTF-16 requires sending a special > > character as > > the first in the string to help determine endness. > > > > If we go with UTF-8 we will not have this problem, since it is > byte > > oriented. > > > > Lets focus discussion on this point, so we can put this out to > vote. > > > > > > -- > > Tom Rutt > > Lucent Technologies - Bell Labs > > Rm 4L-336 Tel: +1(732)949-7862 > > 101 Crawford Corner Rd Fax: +1(732)949-1196 > > Holmdel NJ, 07733 USA email: terutt@lucent.com > > > > > > > > > ---------- > > > From: Bill Janssen[SMTP:janssen@parc.xerox.com] > > > Sent: Friday, March 31, 2000 10:52 PM > > > To: Simon Nash > > > Cc: interop@omg.org > > > Subject: Re: Issue 3405 > > > > > > > 2. This service context is a CDR encapsulation of a sequence > of > > > > ExceptionDataItem structures, encoded using GIOP 1.1 > > with a TCS-C > > > > of ISO8859-1 and a TCS-W of UCS-2. > > > > > > I'd prefer TCS-W of UTF-8 on this, for the reasons we've > > gone into before. > > > > > > Bill > > > > > -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Fri, 07 Apr 2000 17:34:46 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: interop@omg.org Subject: Re: Issue 3405 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: R+~e98GY!!Y:Yd9H<%e9 Michi, Michi Henning wrote: > > On Fri, 7 Apr 2000, Simon Nash wrote: > > > Michi, > > > > 2. This service context is a CDR encapsulation of a sequence > of > > > > ExceptionDataItem structures, encoded using GIOP 1.1 with a > TCS-C > > > > of ISO8859-1 and a TCS-W of UCS-2. > > > > > > > > 3. The ExceptionDataItem structure is defined as follows: > > > > typedef unsigned long ExceptionItemId; > > > > struct ExceptionDataItem { > > > > ExceptionItemId item_id; > > > > sequence item_data; > > > > }; > > > > const ExceptionItemId DetailMessage = 0; > > > > // others may be added in future > > > > > > > > 4. The following pairs of exception data IDs and items are > currently defined: > > > > item_id - DetailMessage > > > > item_data - wstring > > > > > > Suggestion: would it be better to make a sequence of > ExceptionDataItem and > > > send that with the ExceptionData tag? That way, we wouldn't have > to > > > add a new tag every time we want another item for exceptions. > > > > > I'm not sure how this differs from my proposal. My point 2 above > states that > > a sequence of ExceptionDataItem structures is sent in an > ExceptionData > > service context. > > Ah, OK. Maybe I just got confused by the absence of typedef for the > sequence. > The point is moot then. > > > > > This would be all that's specified by the interop RTF. > Language mapping > > > > RTFs could specify semantics and marshalling/unmarshalling > rules for > > > > exception data items that may be sent in this service context. > > > > > > Is that really a job for the language mappings? Certainly, I > would expect > > > at least the marshaling rules to be defined by interop, and have > the language > > > mappings deal with the language bindings. > > > > > What do you include in marshaling rules? In the case of Java, I > would > > propose the rules: > > a. the Java detailMessage field is marshaled into an > ExceptionDataItem > > with item_id DetailMessage, and > > b. if an ExceptionDataItem with item_id DetailMessage is > received, it is > > unmarshaled into the Java detailMessage field. > > These seem to be the proper domain of language mappings. What > else would > > the interop chapter specify? > > Maybe I'm missing something. I think the GIOP chapter should > specify: > > - that the ExceptionData tag indicates a sequence of > ExceptionDataItem that is encapsulated. > > - that an item ID of 0 (DetailMessage) indicates that the > octet > sequence of that item contains a string. > > I basically want to be sure that the GIOP chapter contains all of > the > information I need to completely unmarshal the context in its > entirety. > Otherwise, I have to start groping around in all the language > mappings > in order to get the complete picture of what goes on on the wire. > I think we are in violent agreement. I meant everything in my > proposal to be part of the GIOP chanpter. One small point: it's a wstring, not a string. > In addition, I may well want to change my C++ ORB so that it also > populates that context with relevant information. If we fragment the > definitions of the context contents over the language mapping > chapters, > maintenance of the spec will probably get tricky. > Again, I agree that the context content definitions should all be in > the GIOP chapter. > > > > 2. This service context is a CDR encapsulation of a sequence of > > > > ExceptionDataItem structures, encoded using GIOP 1.1 with a TCS-C > > > > of ISO8859-1 and a TCS-W of UCS-2. > > Isn't that a problem? Either it's a string or it's a wide string. It can't be > a string in some cases and and a wide string in other cases, otherwise > I don't know how to decode the contents of the octet sequence? > Right now the only stringthing that can be in it is a wstring if the id says DetailMessage. In the future, other ids could be added that carry strings. The id will say whether the octet sequence that follows contains a string or wstring. This is how the unmarshaller knows which TCS (C or W) to use. > > > One final glitch: If we have f() which calls g() which calls h(), and h() > > > throws, what are the responsibilities of the ORB that implements g() if > > > g() simply lets the exception through, but g's ORB doesn't understand > > > the exception data? Don't we need a rule that obliges an ORB to pass > > > the exception data through unchanged if an intermediate operation doesn't > > > rethrow? > > > > > A pass-through as you suggest would be nice but I think it's going to > > be tricky to implement. Normally the data would be unmarshaled from > > the g-h connection and placed in a language exception which is thrown > > to g. If the ORB can't do this because it doesn't understand the data, > > where can it put the data that will allow it to be retrieved and sent > > on the f-g connection when the same exception pops out of g and is caught > > by the ORB? > > I agree, that's the problem I was pointing out. The question is whether > this then makes the feature all that useful. Basically, if a call is > proxied by an ORB that doesn't understand the exception data, it will be lost. > I'm a little concerned about transparency here; as far as I can see, even > for a Java client that uses RMI over IIOP, there is no guarantee that > the data will be present if a bridge is in the middle somewhere or if > the server object is implemented by making calls to other objects. > This problem could be avoided if the DetailMessage item were supported by other language bindings as well as Java. I'd prefer to handle it this way. Simon > > The ORB could implement a global mapping of language > > exception objects to not-understood data, but if the language > exception > > is caught and rethrown by g() then this would cause memory leaks. > > I suspect that the leaks could be avoided with the correct > implementation > technique, so I'm not concerned about that for the moment. > > Cheers, > > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Sat, 8 Apr 2000 06:30:40 +1000 (EST) From: Michi Henning To: "Rutt, T E (Tom)" cc: Simon Nash , "'Bill Janssen'" , interop@omg.org Subject: RE: Issue 3405 Getting ready to vote In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: >Lod9M2#!!pJ9!!Q:=!! On Fri, 7 Apr 2000, Rutt, T E (Tom) wrote: > We need to resolve this last wrinkle before a vote. > > I believe we have an agreed solution (with Simon's original proposal > and > Michi's enhancement) but have not agreed on the transfer char set. > > If we go with UTF-16 we need to clarfiy the BE/LE aspects for the > fixed > choice. The generic IANA UTF-16 requires sending a special > character as > the first in the string to help determine endness. > > If we go with UTF-8 we will not have this problem, since it is byte > oriented. > > Lets focus discussion on this point, so we can put this out to vote. UTF-8 sounds OK to me. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Sat, 8 Apr 2000 08:23:46 +1000 (EST) From: Michi Henning To: Simon Nash cc: interop@omg.org Subject: Re: Issue 3405 In-Reply-To: <38EE0557.95CE6195@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: N;Q!!i-A!!(kNe9b//!! On Fri, 7 Apr 2000, Simon Nash wrote: > Michi, > > > 2. This service context is a CDR encapsulation of a sequence of > > > ExceptionDataItem structures, encoded using GIOP 1.1 with a > TCS-C > > > of ISO8859-1 and a TCS-W of UCS-2. > > > > > > 3. The ExceptionDataItem structure is defined as follows: > > > typedef unsigned long ExceptionItemId; > > > struct ExceptionDataItem { > > > ExceptionItemId item_id; > > > sequence item_data; > > > }; > > > const ExceptionItemId DetailMessage = 0; > > > // others may be added in future > > > > > > 4. The following pairs of exception data IDs and items are > currently defined: > > > item_id - DetailMessage > > > item_data - wstring > > > > Suggestion: would it be better to make a sequence of > ExceptionDataItem and > > send that with the ExceptionData tag? That way, we wouldn't have > to > > add a new tag every time we want another item for exceptions. > > > I'm not sure how this differs from my proposal. My point 2 above > states that > a sequence of ExceptionDataItem structures is sent in an > ExceptionData > service context. Ah, OK. Maybe I just got confused by the absence of typedef for the sequence. The point is moot then. > > > This would be all that's specified by the interop RTF. Language mapping > > > RTFs could specify semantics and marshalling/unmarshalling rules for > > > exception data items that may be sent in this service context. > > > > Is that really a job for the language mappings? Certainly, I would expect > > at least the marshaling rules to be defined by interop, and have the language > > mappings deal with the language bindings. > > > What do you include in marshaling rules? In the case of Java, I would > propose the rules: > a. the Java detailMessage field is marshaled into an ExceptionDataItem > with item_id DetailMessage, and > b. if an ExceptionDataItem with item_id DetailMessage is received, it is > unmarshaled into the Java detailMessage field. > These seem to be the proper domain of language mappings. What else would > the interop chapter specify? Maybe I'm missing something. I think the GIOP chapter should specify: - that the ExceptionData tag indicates a sequence of ExceptionDataItem that is encapsulated. - that an item ID of 0 (DetailMessage) indicates that the octet sequence of that item contains a string. I basically want to be sure that the GIOP chapter contains all of the information I need to completely unmarshal the context in its entirety. Otherwise, I have to start groping around in all the language mappings in order to get the complete picture of what goes on on the wire. In addition, I may well want to change my C++ ORB so that it also populates that context with relevant information. If we fragment the definitions of the context contents over the language mapping chapters, maintenance of the spec will probably get tricky. > > > 2. This service context is a CDR encapsulation of a sequence of > > > ExceptionDataItem structures, encoded using GIOP 1.1 with a > TCS-C > > > of ISO8859-1 and a TCS-W of UCS-2. Isn't that a problem? Either it's a string or it's a wide string. It can't be a string in some cases and and a wide string in other cases, otherwise I don't know how to decode the contents of the octet sequence? > > One final glitch: If we have f() which calls g() which calls h(), and h() > > throws, what are the responsibilities of the ORB that implements g() if > > g() simply lets the exception through, but g's ORB doesn't understand > > the exception data? Don't we need a rule that obliges an ORB to pass > > the exception data through unchanged if an intermediate operation doesn't > > rethrow? > > > A pass-through as you suggest would be nice but I think it's going to > be tricky to implement. Normally the data would be unmarshaled from > the g-h connection and placed in a language exception which is thrown > to g. If the ORB can't do this because it doesn't understand the data, > where can it put the data that will allow it to be retrieved and sent > on the f-g connection when the same exception pops out of g and is caught > by the ORB? I agree, that's the problem I was pointing out. The question is whether this then makes the feature all that useful. Basically, if a call is proxied by an ORB that doesn't understand the exception data, it will be lost. I'm a little concerned about transparency here; as far as I can see, even for a Java client that uses RMI over IIOP, there is no guarantee that the data will be present if a bridge is in the middle somewhere or if the server object is implemented by making calls to other objects. > The ORB could implement a global mapping of language > exception objects to not-understood data, but if the language > exception > is caught and rethrown by g() then this would cause memory leaks. I suspect that the leaks could be avoided with the correct implementation technique, so I'm not concerned about that for the moment. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Getting ready to vote Date: Fri, 7 Apr 2000 18:50:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: W4cd9$\g!!lOBe9AI:!! > From: Simon Nash [mailto:nash@hursley.ibm.com] > Paul, > Don't ORBs have to support both UTF-8 and UTF-16 since these > are the fallback codesets for TCS-C and TCS-W? Yes, but UTF-8 is only fallback for Char, and UTF-16 is only fallback for WChar. So there isn't the need for the width-changing conversions. You wouldn't see this problem with Java because you have no internal distinction between Char and WChar. Even then, there remains the "problem" that UTF-16 doesn't follow the byte order used for the rest of the message. This can cause more byte-swapping when talking between identical platforms. Again, Java doesn't care because it is always big-endian and that is what UTF-16 is. But it is wasteful when using intel (or alpha) machines. (I have never understood why there are big-endian machines. Little-endian is so much nicer! But I realize it is a religous issue.) Paul To: Paul Kyzivat cc: interop@omg.org Subject: Re: Issue 3405 Getting ready to vote In-Reply-To: Your message of "Fri, 07 Apr 2000 12:07:01 PDT." <9B164B713EE9D211B6DC0090273CEEA926BDAD@bos1.noblenet.com> From: Bill Janssen Message-Id: <00Apr7.155524pdt."3432"@watson.parc.xerox.com> Date: Fri, 7 Apr 2000 15:55:26 PDT Content-Type: text X-UIDL: dN6!!@igd94Z-!!+GJe9 > I am not especially wild about being required to provide support for > conversion to/from UTF-8. It is something that I don't see a strong > need for > elsewhere. > > Windows and Java both use 16 bit unicode internally, in a flavor > consistent > with the machine's native byte order. Most unixes normally use 32 > bit > unicode in machine byte order. > > I would like to see one choice for TCS-W that will guarantee > interoperability. The likely candidates are some variation on UTF-16 > and/or > UTF-32 that can use the sending system's byte order. Paul, I think all that needs to be done to do that is to write up a specification for such a thing and register it with the OSF to get a number. Then we cite that spec in the CORBA spec. Perhaps UCS-2 prefixed with an additional 16-bit value to indicate the byte order. Bill Date: Sat, 8 Apr 2000 09:10:30 +1000 (EST) From: Michi Henning To: Simon Nash cc: interop@omg.org Subject: Re: Issue 3405 In-Reply-To: <38EE0E26.DD278A51@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 3*He9ZA;e9\`7e9]V\!! On Fri, 7 Apr 2000, Simon Nash wrote: > > I basically want to be sure that the GIOP chapter contains all of the > > information I need to completely unmarshal the context in its entirety. > > Otherwise, I have to start groping around in all the language mappings > > in order to get the complete picture of what goes on on the wire. > > > I think we are in violent agreement. Miracles never cease to amaze me! :-) > I meant everything in my proposal > to be part of the GIOP chanpter. One small point: it's a wstring, > not > a string. OK, I don't think that was clear in the proposal. > > In addition, I may well want to change my C++ ORB so that it also > > populates that context with relevant information. If we fragment > the > > definitions of the context contents over the language mapping > chapters, > > maintenance of the spec will probably get tricky. > > > Again, I agree that the context content definitions should all be in > the > GIOP chapter. Sounds good to me. > > > > > 2. This service context is a CDR encapsulation of a sequence of > > > > > ExceptionDataItem structures, encoded using GIOP 1.1 with a TCS-C > > > > > of ISO8859-1 and a TCS-W of UCS-2. > > > > Isn't that a problem? Either it's a string or it's a wide string. It can't be > > a string in some cases and and a wide string in other cases, otherwise > > I don't know how to decode the contents of the octet sequence? > > > Right now the only stringthing that can be in it is a wstring if the id > says DetailMessage. In the future, other ids could be added that carry > strings. The id will say whether the octet sequence that follows > contains a string or wstring. This is how the unmarshaller knows which > TCS (C or W) to use. Ah, OK. I think we need to clarify the wording a bit then. I interpreted this to mean that the octet sequence can contain either type at will. > > > A pass-through as you suggest would be nice but I think it's going to > > > be tricky to implement. Normally the data would be unmarshaled from > > > the g-h connection and placed in a language exception which is thrown > > > to g. If the ORB can't do this because it doesn't understand the data, > > > where can it put the data that will allow it to be retrieved and sent > > > on the f-g connection when the same exception pops out of g and is caught > > > by the ORB? > > > > I agree, that's the problem I was pointing out. The question is whether > > this then makes the feature all that useful. Basically, if a call is > > proxied by an ORB that doesn't understand the exception data, it will be lost. > > I'm a little concerned about transparency here; as far as I can see, even > > for a Java client that uses RMI over IIOP, there is no guarantee that > > the data will be present if a bridge is in the middle somewhere or if > > the server object is implemented by making calls to other objects. > > > This problem could be avoided if the DetailMessage item were supported > by other language bindings as well as Java. I'd prefer to handle it > this way. Well, if nothing else, we have a compatibility issues here, in the sense that a new client that intereoperates with an older ORB won't get the context. So, passthrough feature aside, the client code cannot rely on the context being present anyway. That's what makes me a little wary of the feature in general, because of its optional nature. Usually what happens is that programmers end up intrisically relying on something that's optional, typically because they are not aware of the fact that is optional in the first place. Then, when deployment or interoperability scenarios change, the optional thing is no longer there, and the application breaks... In this particular case, I don't think that's too much of a danger because the reason string (as far as I can see) is something that provides simply additional debug information and won't be processed programmatically. It's something to be aware of though, and we should make it very clear that the client may not get any reason string with a system exception. That's also why I'm reluctant to go and hack around in all the language bindings to add this. It's quite a lot of work and quite intrusive, all for something that's optional. Maybe we simply have to accept that additional exception information may not be present and may not be accessible from all language bindings. For the Java RMI/IIOP case, I'd then leave it to the Java mapping RTF to decide how to make the reason string available in the Java binding, if at all. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Sat, 8 Apr 2000 09:28:47 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interop@omg.org Subject: RE: Issue 3405 Getting ready to vote In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BDAF@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: GOI!!~:2e9fY*!!;j'e9 On Fri, 7 Apr 2000, Paul Kyzivat wrote: > (I have never understood why there are big-endian machines. > Little-endian is so much nicer! Heresy! > But I realize it is a religous issue.) Yep :-) Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Date: Fri, 7 Apr 2000 20:31:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: '#g!!;':!!#\W!!Ongd9 > From: Michi Henning [mailto:michi@ooc.com.au] > > Right now the only stringthing that can be in it is a > wstring if the id > > says DetailMessage. In the future, other ids could be > added that carry > > strings. The id will say whether the octet sequence that follows > > contains a string or wstring. This is how the unmarshaller > knows which > > TCS (C or W) to use. > > Ah, OK. I think we need to clarify the wording a bit then. I > interpreted > this to mean that the octet sequence can contain either type at > will. I've lost track of what has been proposed. This service context (itself marshalled as an encapsulation) contains a sequence of ExceptionDataItem structures. Is each of these itself an encapsulation? If so, (while painful) there is no problem with one containing strings and another containing wide strings. But if they are not separate encapsulations, then there is no way to describe a sequence of things that don't all have the same shape. If they are encapsulations within encapsulations, why bother? You might as well make them separate service contexts. Paul From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Getting ready to vote Date: Fri, 7 Apr 2000 20:54:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ?Q]d9'O"e9YR`!!8*=!! > From: Bill Janssen [mailto:janssen@parc.xerox.com] > > I would like to see one choice for TCS-W that will guarantee > > interoperability. The likely candidates are some variation > on UTF-16 and/or > > UTF-32 that can use the sending system's byte order. > > Paul, > > I think all that needs to be done to do that is to write up a > specification for such a thing and register it with the OSF to get a > number. Then we cite that spec in the CORBA spec. Perhaps UCS-2 > prefixed with an additional 16-bit value to indicate the byte order. If we decide that is what we need, then I guess we have a way to do it. But, we don't want to send the byte order each time. We already know the byte order contextually, from the byte order of the message (or encapsulation) carrying it. So, we need a way to specify an encoding where the byte order is contextual. Do you think that can fly? Paul Date: Sat, 8 Apr 2000 10:58:34 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interop@omg.org Subject: RE: Issue 3405 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BDB0@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: +JJ!!F;6e91(1e9p7ed9 On Fri, 7 Apr 2000, Paul Kyzivat wrote: > > Ah, OK. I think we need to clarify the wording a bit then. I > > interpreted > > this to mean that the octet sequence can contain either type at > will. > > I've lost track of what has been proposed. This service context > (itself > marshalled as an encapsulation) contains a sequence of > ExceptionDataItem > structures. Is each of these itself an encapsulation? No, but the octet sequence in each ExceptionDataItem would contain an encapsulation. (At least that was the intent, I think. Simon?) > If they are encapsulations within encapsulations, why bother? You might as > well make them separate service contexts. I'm not sure it would be nice to have service context tags "Exception info for Java RMI over IIOP", "Exception info for, C++ over whatever", etc. I think Simon's suggestion is cleaner because the exception info that will be sent is extensible without addition of new service context tags and groups related things together. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Sat, 8 Apr 2000 12:04:14 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interop@omg.org Subject: RE: Issue 3405 Getting ready to vote In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BDB2@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ?Bn!!!9^d9<9pd93E5e9 On Fri, 7 Apr 2000, Paul Kyzivat wrote: > But, we don't want to send the byte order each time. We already know the > byte order contextually, from the byte order of the message (or > encapsulation) carrying it. > > So, we need a way to specify an encoding where the byte order is contextual. > Do you think that can fly? Hmmm... I think it would be preferable to have the byte order with the string. That way, I can blindly throw that string into something else without having to remarshal anything. And the extra cost is minimal. Compare this to encapsulations. We have a byte order in encapsulations, but no version number, which has bitten us in the past. There is a lot to be said for data that is context free... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html To: Paul Kyzivat cc: interop@omg.org Subject: Re: Issue 3405 Getting ready to vote In-Reply-To: Your message of "Fri, 07 Apr 2000 17:51:36 PDT." <9B164B713EE9D211B6DC0090273CEEA926BDB2@bos1.noblenet.com> From: Bill Janssen Message-Id: <00Apr7.195353pdt."3432"@watson.parc.xerox.com> Date: Fri, 7 Apr 2000 19:53:56 PDT Content-Type: text X-UIDL: `GU!!_a^d9G>O!!+#5e9 > So, we need a way to specify an encoding where the byte order is contextual. > Do you think that can fly? Well, UCS-4 would cover that case (or UCS-2, but it only handles the 16-bit space, which apparently can't handle Han). In those charsets, the byte-order isn't defined. We'd have to specify which level of code combination we'd want, I think. Bill To: Michi Henning cc: Paul Kyzivat , interop@omg.org Subject: Re: Issue 3405 Getting ready to vote In-Reply-To: Your message of "Fri, 07 Apr 2000 19:05:54 PDT." From: Bill Janssen Message-Id: <00Apr7.195438pdt."3432"@watson.parc.xerox.com> Date: Fri, 7 Apr 2000 19:54:47 PDT Content-Type: text X-UIDL: U6Le9X?0!!7hGe9EbV!! > Hmmm... I think it would be preferable to have the byte order with the > string. That way, I can blindly throw that string into something else > without having to remarshal anything. And the extra cost is minimal. > Compare this to encapsulations. We have a byte order in encapsulations, > but no version number, which has bitten us in the past. There is a lot > to be said for data that is context free... I think Michi's right. Bill From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Getting ready to vote Date: Mon, 10 Apr 2000 08:43:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 5\K!!k7~e92cHe9jB(!! We aren't talking about eliminating the possibility of negotiating other code sets, so I think it might still be ok to choose UCS-2 as a standard supported set for WChar. Wouldn't this map better to Java anyway, which I gather has no way to support more than a 16-bit set? Paul > -----Original Message----- > From: Bill Janssen [mailto:janssen@parc.xerox.com] > Sent: Friday, April 07, 2000 10:54 PM > To: Paul Kyzivat > Cc: interop@omg.org > Subject: Re: Issue 3405 Getting ready to vote > > > > So, we need a way to specify an encoding where the byte > order is contextual. > > Do you think that can fly? > > Well, UCS-4 would cover that case (or UCS-2, but it only handles the > 16-bit space, which apparently can't handle Han). In those > charsets, > the byte-order isn't defined. We'd have to specify which level of > code combination we'd want, I think. > > Bill > From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Date: Mon, 10 Apr 2000 09:06:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: =Z_!!1:Wd9=9?!!in0!! > From: Michi Henning [mailto:michi@ooc.com.au] > > I've lost track of what has been proposed. This service > context (itself > > marshalled as an encapsulation) contains a sequence of > ExceptionDataItem > > structures. Is each of these itself an encapsulation? > > No, but the octet sequence in each ExceptionDataItem would contain > an encapsulation. (At least that was the intent, I think. Simon?) Even though you said No, the rest of your sentence seems to say Yes - the service context (itself marshalled as an encapsulation in a request) contains a sequence of name/value pairs, where the value part of each pair is itself an encapsulation. So, to transmit an exception, I am going to have to doubly encapsulate the text from the exception. Not very appealing, but there are no fundamental technical issues with this. > > > If they are encapsulations within encapsulations, why > bother? You might as > > well make them separate service contexts. > > I'm not sure it would be nice to have service context tags > "Exception info > for Java RMI over IIOP", "Exception info for, C++ over whatever", > etc. That would only be needed if people actually want to dice things that fine. It could simply start out as "Exception info for Java RMI over IIOP", and then if other languages choose to map that same one to something meaningful in their language we could eventually change the name that we call it to something more general. > > I think Simon's suggestion is cleaner because the exception > info that will > be sent is extensible without addition of new service context tags > and > groups related things together. Agreed that this won't require new service context tags. But at the expense of yet another registry, this time using string names. That registry needs to go somewhere, so why is it fundamentally better than just assigning new service context tags? Because of the way encapsulations are now defined, each distinct kind of encapsulation needs a specification of giop version and code sets. In principle, the value corresponding to each distinct name tag could be different in this regard, and hence require some words in the interop chapter. (The alternative is to require that they all share the choices made for the encapsulation of their enclosing service context. Understand, I am just exploring the alternatives and their pros/cons. I am not necessarily (yet) advocating any one of these as better. Paul From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Getting ready to vote Date: Mon, 10 Apr 2000 09:28:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ]HJe93K-e9kFa!!pj1e9 > From: Michi Henning [mailto:michi@ooc.com.au] > > But, we don't want to send the byte order each time. We > already know the > > byte order contextually, from the byte order of the message (or > > encapsulation) carrying it. > > > > So, we need a way to specify an encoding where the byte > order is contextual. > > Do you think that can fly? > > Hmmm... I think it would be preferable to have the byte order with > the > string. That way, I can blindly throw that string into something > else > without having to remarshal anything. And the extra cost is minimal. Well, it hadn't previously occurred to me that anyone was thinking of doing it that way. But I am not fundamentally opposed to it. > Compare this to encapsulations. We have a byte order in encapsulations, In the case of encapulations, it was an explicit intent to support pulling encapsulations off the wire, saving them in encapsulated form, and sending them out again without remarshalling. We have an explicit internal representation (the rep for sequence) for holding them in this form. I don't understand how you plan to transfer this representation of string from one message to another without remarshalling. Are you just going to treat the entire string as an encapsulation? If so, there would need to be some way to alter the language mapping to map some strings as strings, and others as sequences of octet. > but no version number, which has bitten us in the past. This isn't it about to bite us again? It seems to me that in this case we should have no intent of pulling the strings off the wire without unmarshalling them, so tying the byte order to that of the containing encoding should not be any more of a problem than tying the giop version in which the strings are encoded to that of the containing encoding. > There is a lot to be said for data that is context free... Yes, there is. But where do you draw the line? We could enhance encapsulations to carry a giop version and code set info, and then encode every complex type as a separate encapsulation. In my mind that would be over the line. I am not sure about strings - I have yet to see any particular value in sending the byte order with each string. As long as I don't, I consider it to be over the line too. Were we to send the byte order with individual strings, presumably this would actually mean sending it with each non-byte-oriented encoding, whether it was for a wstring, a wchar, or even a string. Paul Sender: jis@fpk.hp.com Message-ID: <38F1E82C.F144E62E@fpk.hp.com> Date: Mon, 10 Apr 2000 10:41:48 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777) MIME-Version: 1.0 To: Michi Henning Cc: "Rutt, T E (Tom)" , Simon Nash , "'Bill Janssen'" , interop@omg.org Subject: Re: Issue 3405 Getting ready to vote References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: I=Zd!!5[m!!X6]!! Michi Henning wrote: > > On Fri, 7 Apr 2000, Rutt, T E (Tom) wrote: > > > We need to resolve this last wrinkle before a vote. > > > > I believe we have an agreed solution (with Simon's original > proposal and > > Michi's enhancement) but have not agreed on the transfer char set. > > > > If we go with UTF-16 we need to clarfiy the BE/LE aspects for the > fixed > > choice. The generic IANA UTF-16 requires sending a special > character as > > the first in the string to help determine endness. > > > > If we go with UTF-8 we will not have this problem, since it is > byte > > oriented. > > > > Lets focus discussion on this point, so we can put this out to > vote. > > UTF-8 sounds OK to me. Me too. Even more so after reading Bill's message and factoring in the additional information therein. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Mon, 10 Apr 2000 21:48:48 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Paul Kyzivat , interop@omg.org Subject: Re: Issue 3405 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: )6%e9)]S!!QA[!!p/Xd9 Michi, Michi Henning wrote: > > On Fri, 7 Apr 2000, Paul Kyzivat wrote: > > > > Ah, OK. I think we need to clarify the wording a bit then. I > > > interpreted > > > this to mean that the octet sequence can contain either type at > will. > > > > I've lost track of what has been proposed. This service context > (itself > > marshalled as an encapsulation) contains a sequence of > ExceptionDataItem > > structures. Is each of these itself an encapsulation? > > No, but the octet sequence in each ExceptionDataItem would contain > an encapsulation. (At least that was the intent, I think. Simon?) > I didn't say that in my proposal, and I don't see why double > encapsulation is needed. The encoding of each ExceptionDataItem item_data as a sequence of octets allows it to be skipped by any ORB that understands > the ExceptionData service context but not an individual ExceptionDataItem. Simon > > If they are encapsulations within encapsulations, why bother? You might as > > well make them separate service contexts. > > I'm not sure it would be nice to have service context tags "Exception info > for Java RMI over IIOP", "Exception info for, C++ over whatever", etc. > > I think Simon's suggestion is cleaner because the exception info that will > be sent is extensible without addition of new service context tags and > groups related things together. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 10 Apr 2000 21:58:21 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interop@omg.org Subject: Re: Issue 3405 References: <9B164B713EE9D211B6DC0090273CEEA926BDB5@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: -g%!!'--e9F"1!!F)-!! Paul, Paul Kyzivat wrote: > > > From: Michi Henning [mailto:michi@ooc.com.au] > > > > I've lost track of what has been proposed. This service > > context (itself > > > marshalled as an encapsulation) contains a sequence of > > ExceptionDataItem > > > structures. Is each of these itself an encapsulation? > > > > No, but the octet sequence in each ExceptionDataItem would contain > > an encapsulation. (At least that was the intent, I think. Simon?) > > Even though you said No, the rest of your sentence seems to say Yes > - > the service context (itself marshalled as an encapsulation in a > request) > contains a sequence of name/value pairs, where the value part of > each > pair is itself an encapsulation. > > So, to transmit an exception, I am going to have to doubly > encapsulate the > text from the exception. > > Not very appealing, but there are no fundamental technical issues > with this. > > > > > > If they are encapsulations within encapsulations, why > > bother? You might as > > > well make them separate service contexts. > > > > I'm not sure it would be nice to have service context tags > > "Exception info > > for Java RMI over IIOP", "Exception info for, C++ over whatever", > etc. > > That would only be needed if people actually want to dice things > that fine. > It could simply start out as "Exception info for Java RMI over > IIOP", and > then if other languages choose to map that same one to something > meaningful > in their language we could eventually change the name that we call > it to > something more general. > I have tried to avoid this because the consensus in the earlier debate > came out in favour of more generic language-neutral mechanisms at the GIOP > level. > > > > I think Simon's suggestion is cleaner because the exception > > info that will > > be sent is extensible without addition of new service context tags > and > > groups related things together. > > Agreed that this won't require new service context tags. > But at the expense of yet another registry, this time using string > names. > That registry needs to go somewhere, so why is it fundamentally > better than > just assigning new service context tags? > Not string names. My proposal uses numeric IDs to identify each ExceptionDataItem. Yes, it's another registry, and we could avoid the nesting by sending an individual service context for each piece of > exception data. I did it this way because I thought it was better to group all > this related information together. > Because of the way encapsulations are now defined, each distinct kind of > encapsulation needs a specification of giop version and code sets. In > principle, the value corresponding to each distinct name tag could be > different in this regard, and hence require some words in the interop > chapter. (The alternative is to require that they all share the choices made > for the encapsulation of their enclosing service context. > Since name tags are numbers, I believe this point is moot. Simon > Understand, I am just exploring the alternatives and their pros/cons. > I am not necessarily (yet) advocating any one of these as better. > > Paul -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 10 Apr 2000 22:01:27 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interop@omg.org Subject: Re: Issue 3405 References: <9B164B713EE9D211B6DC0090273CEEA926BDB0@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ;PZ!!ZWBe9bb]d9f;]d9 Paul, Paul Kyzivat wrote: > > > From: Michi Henning [mailto:michi@ooc.com.au] > > > > Right now the only stringthing that can be in it is a > > wstring if the id > > > says DetailMessage. In the future, other ids could be > > added that carry > > > strings. The id will say whether the octet sequence that > follows > > > contains a string or wstring. This is how the unmarshaller > > knows which > > > TCS (C or W) to use. > > > > Ah, OK. I think we need to clarify the wording a bit then. I > > interpreted > > this to mean that the octet sequence can contain either type at > will. > > I've lost track of what has been proposed. This service context > (itself > marshalled as an encapsulation) contains a sequence of > ExceptionDataItem > structures. Is each of these itself an encapsulation? > > If so, (while painful) there is no problem with one containing > strings and > another containing wide strings. > > But if they are not separate encapsulations, then there is no way to > describe a sequence of things that don't all have the same shape. > They do all have the same shape. They are all sequences of octets. > The interpretation of the octets within each sequence depends on the > numeric ID that precedes it. This is similar to their being encpasulations, > except that they don't individually carry a byte order. Simon > If they are encapsulations within encapsulations, why bother? You might as > well make them separate service contexts. > > Paul -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 10 Apr 2000 21:42:51 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Paul Kyzivat , interop@omg.org Subject: Re: Issue 3405 Getting ready to vote References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: P=g!!b$Vd9O6S!!cd>e9 Michi, Michi Henning wrote: > > On Fri, 7 Apr 2000, Paul Kyzivat wrote: > > > But, we don't want to send the byte order each time. We already > know the > > byte order contextually, from the byte order of the message (or > > encapsulation) carrying it. > > > > So, we need a way to specify an encoding where the byte order is > contextual. > > Do you think that can fly? > > Hmmm... I think it would be preferable to have the byte order with > the > string. That way, I can blindly throw that string into something > else > without having to remarshal anything. And the extra cost is minimal. > Compare this to encapsulations. We have a byte order in > encapsulations, > but no version number, which has bitten us in the past. There is a > lot > to be said for data that is context free... > If this is needed, it should be a more general notion of > byte-order-encoded string, not stuck in here ad hoc. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Date: Mon, 10 Apr 2000 18:12:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 3%3!!KHPd9T%Vd9)P"e9 > From: Simon Nash [mailto:nash@hursley.ibm.com] > They do all have the same shape. They are all sequences of > octets. The > interpretation of the octets within each sequence depends on > the numeric > ID that precedes it. This is similar to their being > encpasulations, except > that they don't individually carry a byte order. Yuck!!! So you are inventing yet another variation on encapsulation? And how would this be encoded/decoded? Assume it might be done in an interceptor. (Or do you assume this cannot be done by an interceptor?) Interceptors have a means of encoding/decoding encapsulations, but not this special variation. And aside from a couple of bytes saved, it doesn't help efficiency at all. You still must marshal to/from octets and then marshal the octets. I am becoming more convinced that these should be treated as separate service contexts. It eliminates one level of encapsulation, and it also makes it easier to write interceptors that deal with a particular piece of information. Without that, how would you ever generate one of these service contexts with more than one entry in the sequence? You could only do it if a single interceptor knew about all the tags. Similarly, when decoding, an interceptor would have to decode the entire sequence and then process the one(s) it was interested in. Of course we could always introduce a new kind of interceptor specifically to handle individual tags, with its own registration, but I doubt anybody really wants that. Paul Date: Tue, 11 Apr 2000 08:05:06 +1000 (EST) From: Michi Henning To: Simon Nash cc: Paul Kyzivat , interop@omg.org Subject: Re: Issue 3405 In-Reply-To: <38F23E30.2AE1E8BC@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: pEB!!-"]d97&e!!9?^d9 On Mon, 10 Apr 2000, Simon Nash wrote: > > No, but the octet sequence in each ExceptionDataItem would contain > > an encapsulation. (At least that was the intent, I think. Simon?) > > > I didn't say that in my proposal, and I don't see why double > encapsulation > is needed. The encoding of each ExceptionDataItem item_data as a > sequence of octets allows it to be skipped by any ORB that > understands the > ExceptionData service context but not an individual > ExceptionDataItem. We could do it that way. However, that means there won't be a separate byte ordering flag. In turn, that means that I cannot retain the contents of an item I don't know about if I need to remarshal in a different byte order. Wouldn't it be nicer to encapsulate each item? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Date: Mon, 10 Apr 2000 18:42:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: From: Simon Nash [mailto:nash@hursley.ibm.com] > > That would only be needed if people actually want to dice > things that fine. > > It could simply start out as "Exception info for Java RMI > over IIOP", and > > then if other languages choose to map that same one to > something meaningful > > in their language we could eventually change the name that > we call it to > > something more general. > > > I have tried to avoid this because the consensus in the > earlier debate came > out in favour of more generic language-neutral mechanisms at > the GIOP level. That wasn't the point I was trying to make. Whatever you want to call the tag, and whatever semantics you want to assign to it, you can achieve the same end making it a service context of its own. If we can agree to this as a language neutral thing, fine. If not, thats fine too. > Not string names. My proposal uses numeric IDs to identify each > ExceptionDataItem. Yes, it's another registry, and we could avoid > the > nesting by sending an individual service context for each > piece of exception > data. I did it this way because I thought it was better to > group all this related information together. Except that it isn't clear that the information is related. I gather you only have one piece of information in mind (the exception text) for use with Java. Perhaps some other language will have some other interesting piece of information. In any given implementation these may not be related at all. Putting them together only makes sense if a single piece of code is guaranteed to understand and process all the tags. That makes it very difficult to do with interceptors. And since we will need yet another registry, doesn't this just make things both more expensive to process and more complex than using separate service contexts? I think we are doing some unjustified generalization here. Paul Date: Tue, 11 Apr 2000 09:10:02 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interop@omg.org Subject: RE: Issue 3405 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BDBA@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: *6)e9D='!!$$O!!!Q\!! On Mon, 10 Apr 2000, Paul Kyzivat wrote: > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > > They do all have the same shape. They are all sequences of > > octets. The > > interpretation of the octets within each sequence depends on > > the numeric > > ID that precedes it. This is similar to their being > > encpasulations, except > > that they don't individually carry a byte order. > > Yuck!!! > > So you are inventing yet another variation on encapsulation? > > And how would this be encoded/decoded? Assume it might be done in an > interceptor. (Or do you assume this cannot be done by an > interceptor?) > > Interceptors have a means of encoding/decoding encapsulations, but > not this > special variation. > > And aside from a couple of bytes saved, it doesn't help efficiency > at all. > You still must marshal to/from octets and then marshal the octets. I agree with you. Either we have nested encapsulations, or we have a separate service context each. The in-between approach strikes me as wrong. > I am becoming more convinced that these should be treated as separate > service contexts. It eliminates one level of encapsulation, and it also > makes it easier to write interceptors that deal with a particular piece of > information. I could live with separate service contexts, although I still prefer Simon's grouping idea of keeping exception-related things together under a single service context. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Tue, 11 Apr 2000 11:45:31 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Paul Kyzivat , interop@omg.org Subject: Re: Issue 3405 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: KEp!!>iid9f`[d9i_)e9 Michi, Michi Henning wrote: > > On Mon, 10 Apr 2000, Simon Nash wrote: > > > > No, but the octet sequence in each ExceptionDataItem would > contain > > > an encapsulation. (At least that was the intent, I > think. Simon?) > > > > > I didn't say that in my proposal, and I don't see why double > encapsulation > > is needed. The encoding of each ExceptionDataItem item_data as a > > sequence of octets allows it to be skipped by any ORB that > understands the > > ExceptionData service context but not an individual > ExceptionDataItem. > > We could do it that way. However, that means there won't be a > separate > byte ordering flag. In turn, that means that I cannot retain the > contents > of an item I don't know about if I need to remarshal in a different > byte > order. Wouldn't it be nicer to encapsulate each item? > You can remarshal the whole service context. Given that all this > exception data is intended to travel from server to client, and pass through > intervening bridges and routers unchanged and unfiltered, I don't see a need to > retain and remarshal some parts of it but not the whole service context. And > even if there were such a need, those parts could be remarshalled within an ExceptionData service context that specifies a byte order. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Tue, 11 Apr 2000 13:34:29 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interop@omg.org Subject: Re: Issue 3405 References: <9B164B713EE9D211B6DC0090273CEEA926BDBD@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: !D2!!?g>!!+[K!!7k+!! Paul, Paul Kyzivat wrote: > > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > > > That would only be needed if people actually want to dice > > things that fine. > > > It could simply start out as "Exception info for Java RMI > > over IIOP", and > > > then if other languages choose to map that same one to > > something meaningful > > > in their language we could eventually change the name that > > we call it to > > > something more general. > > > > > I have tried to avoid this because the consensus in the > > earlier debate came > > out in favour of more generic language-neutral mechanisms at > > the GIOP level. > > That wasn't the point I was trying to make. > Whatever you want to call the tag, and whatever semantics you want > to assign > to it, you can achieve the same end making it a service context of > its own. > > If we can agree to this as a language neutral thing, fine. > If not, thats fine too. > > > Not string names. My proposal uses numeric IDs to identify each > > ExceptionDataItem. Yes, it's another registry, and we could avoid > the > > nesting by sending an individual service context for each > > piece of exception > > data. I did it this way because I thought it was better to > > group all this related information together. > > Except that it isn't clear that the information is related. > I gather you only have one piece of information in mind (the > exception text) > for use with Java. Perhaps some other language will have some other > interesting piece of information. In any given implementation these > may not > be related at all. > The implementation that creates the ExceptionData service context will > be in some language, and it will put into it whatever information makes > sense for that language. There will never be a need to mix Java and C++ > exception data for a single exception. > Putting them together only makes sense if a single piece of code is > guaranteed to understand and process all the tags. That makes it > very > difficult to do with interceptors. > > And since we will need yet another registry, doesn't this just make > things > both more expensive to process and more complex than using separate > service > contexts? > > I think we are doing some unjustified generalization here. > I can live with treating all these as separate service contexts. If > anyone has strong objections, speak now or forever hold your peace. Likewise, I have heard most sentiment in favour of UTF-8 for the reason string encoding, and I will specify this in my revised proposal unless anyone objects. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Date: Tue, 11 Apr 2000 11:29:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: B1+e9/7Oe9V""!!`Tc!! > From: Simon Nash [mailto:nash@hursley.ibm.com] > The implementation that creates the ExceptionData service > context will be in > some language, and it will put into it whatever information > makes sense for > that language. There will never be a need to mix Java and > C++ exception > data for a single exception. Let me try to restate my current understanding. You can then agree or not. - An ExceptionData service context can contain any subset of a number of optional components. - A given language binding will specify which subset is applicable to that application. This reflects extra state of the exception that is shared by like language bindings. - Some components may be used by multiple language bindings, permitting them to share extra state in a consistent way. - The processing of this service context will typically be performed by the language binding and the orb, not by interceptors. (Interceptors would not be in a position to alter the representation of the exception.) - There is no guarantee that components not specified by the language binding will be propagated by an intermediate server when an exception is propagated through a chain of calls. Have I got it? Paul Date: Tue, 11 Apr 2000 20:04:15 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interop@omg.org Subject: Re: Issue 3405 References: <9B164B713EE9D211B6DC0090273CEEA926BDC5@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: \9B!!e9WVmd9 Paul, I agree with most of this. However, I wouldn't totally rule out the involvement of interceptors. For example, they could log exceptions and their associated data. They could also possibly perform some translation or augmentation of some parts of the exception data. If this is easier if we make each piece of exception data a separate service context, that's fine with me. Simon Paul Kyzivat wrote: > > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > > The implementation that creates the ExceptionData service > > context will be in > > some language, and it will put into it whatever information > > makes sense for > > that language. There will never be a need to mix Java and > > C++ exception > > data for a single exception. > > Let me try to restate my current understanding. You can then agree > or not. > > - An ExceptionData service context can contain any subset of a > number of > optional components. > > - A given language binding will specify which subset is applicable > to that > application. This reflects extra state of the exception that is > shared by > like language bindings. > > - Some components may be used by multiple language bindings, > permitting them > to share extra state in a consistent way. > > - The processing of this service context will typically be performed > by the > language binding and the orb, not by interceptors. (Interceptors > would not > be in a position to alter the representation of the exception.) > > - There is no guarantee that components not specified by the > language > binding will be propagated by an intermediate server when an > exception is > propagated through a chain of calls. > > Have I got it? > > Paul -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: "Rutt, T E (Tom)" To: interop@omg.org, "'Paul Kyzivat'" Subject: RE: Issue 3405 Getting ready to vote Date: Tue, 11 Apr 2000 15:18:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: D?Od9nHCe9#[!e9BM^!! > ---------- > From: Paul Kyzivat[SMTP:paulk@roguewave.com] > Sent: Friday, April 07, 2000 3:09 PM > To: interop@omg.org > Subject: RE: Issue 3405 Getting ready to vote > > I am not especially wild about being required to provide support for > conversion to/from UTF-8. It is something that I don't see a strong > need > for > elsewhere. > > Windows and Java both use 16 bit unicode internally, in a flavor > consistent > with the machine's native byte order. Most unixes normally use 32 > bit > unicode in machine byte order. > > I would like to see one choice for TCS-W that will guarantee > interoperability. The likely candidates are some variation on UTF-16 > and/or > UTF-32 that can use the sending system's byte order. > > Paul > UTF-16 can carry the data beyond the 1 bit unicode (there is a trick involved but it is part of the standard). If the UTF16 is in an encapsulation, why cannot we use the byte order of the encapsulation to determine the byte order of its contained UTF16 along with the integers? -- Tom Rutt Lucent Technologies - Bell Labs Rm 4L-336 Tel: +1(732)949-7862 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA email: terutt@lucent.com From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Date: Tue, 11 Apr 2000 15:52:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Y^fd94f[!!4g)!!k0Ce9 Simon, I wasn't ruling out interceptors only, but while there seems to be no reason to prevent an interceptor from being registered for this sc, I don't think an interceptor has enough capability to fully provide the functionality intended. So some non-interceptor-based handling of this seems required. As long as the normal processing of this is not via interceptors, using one or several sc's seems irrelevant on that score. The main reason I am inclined toward separate sc's is to: - avoid double encapsulation - eliminate the need for a separate registry But some new problems have occured to me regarding the use of sc's for this in general: - the order in which this stuff is processed. SCs are required to be decoded and processed before the reply body. So, there won't yet be an exception to attach this data to. The data will have to be held until after the exception is decoded, and then attached. This is at least inconvenient. It is also another problem with using interceptors to handle this SC. - as of GIOP 1.2, system exceptions can be returned with LocateReply messages. But LocateReply messages don't carry service contexts. - if an exception can be passed as data (now or in the future) the use of this SC to carry part of the exception will be a real problem. I forget if it is currently legal to marshal an Any containing an exception. If so, this would be one such case. This would also rule out any hope of making exceptions first class data types. Paul > -----Original Message----- > From: Simon Nash [mailto:nash@hursley.ibm.com] > Sent: Tuesday, April 11, 2000 3:04 PM > To: Paul Kyzivat > Cc: interop@omg.org > Subject: Re: Issue 3405 > > > Paul, > I agree with most of this. However, I wouldn't totally rule out the > > involvement of interceptors. For example, they could log exceptions > and their associated data. They could also possibly perform > some translation > or augmentation of some parts of the exception data. If this > is easier if > we make each piece of exception data a separate service > context, that's fine > with me. > > Simon > > Paul Kyzivat wrote: > > > > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > > > > The implementation that creates the ExceptionData service > > > context will be in > > > some language, and it will put into it whatever information > > > makes sense for > > > that language. There will never be a need to mix Java and > > > C++ exception > > > data for a single exception. > > > > Let me try to restate my current understanding. You can > then agree or not. > > > > - An ExceptionData service context can contain any subset > of a number of > > optional components. > > > > - A given language binding will specify which subset is > applicable to that > > application. This reflects extra state of the exception > that is shared by > > like language bindings. > > > > - Some components may be used by multiple language > bindings, permitting them > > to share extra state in a consistent way. > > > > - The processing of this service context will typically be > performed by the > > language binding and the orb, not by interceptors. > (Interceptors would not > > be in a position to alter the representation of the exception.) > > > > - There is no guarantee that components not specified by > the language > > binding will be propagated by an intermediate server when > an exception is > > propagated through a chain of calls. > > > > Have I got it? > > > > Paul > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Getting ready to vote Date: Tue, 11 Apr 2000 15:57:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: CHf!!:_~e9De0!!f]^d9 > From: Rutt, T E (Tom) [mailto:terutt@lucent.com] > UTF-16 can carry the data beyond the 1 bit unicode > (there is a trick involved but it is part of the standard). 1-bit unicode? That must use some really fancy coding techniques! Seriously, did you mean 16-bit? Can you say more? I was surprised when Bill said that UTF8 covers a bigger code space than UTF16. Can that really be true? > > If the UTF16 is in an encapsulation, why cannot we use the byte > order of the > encapsulation to determine the byte order of its contained UTF16 > along with the integers? That is what I am hoping for. I am just looking for guidance from you experts on code set registries regarding a legal way to achieve that. Paul Sender: jbiggar@corvette.floorboard.com Message-ID: <38F3838F.F15F9012@floorboard.com> Date: Tue, 11 Apr 2000 12:57:03 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Rutt, T E (Tom)" CC: interop@omg.org, "'Paul Kyzivat'" Subject: Re: Issue 3405 Getting ready to vote References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 3hI!!/;4!!K,He9PND!! "Rutt, T E (Tom)" wrote: > > > ---------- > > From: Paul Kyzivat[SMTP:paulk@roguewave.com] > > Sent: Friday, April 07, 2000 3:09 PM > > To: interop@omg.org > > Subject: RE: Issue 3405 Getting ready to vote > > > > I am not especially wild about being required to provide support > for > > conversion to/from UTF-8. It is something that I don't see a > strong need > > for > > elsewhere. > > > > Windows and Java both use 16 bit unicode internally, in a flavor > > consistent > > with the machine's native byte order. Most unixes normally use 32 > bit > > unicode in machine byte order. > > > > I would like to see one choice for TCS-W that will guarantee > > interoperability. The likely candidates are some variation on > UTF-16 > > and/or > > UTF-32 that can use the sending system's byte order. > UTF-16 can carry the data beyond the 1 bit unicode (there is a trick involved > but it is part of the standard). I assume you mean 16-bit unicode? > If the UTF16 is in an encapsulation, why cannot we use the byte order of the > encapsulation to determine the byte order of its contained UTF16 along with > the integers? Yes, but technically it's not UTF16 anymore, since UTF16 requires big-endian byte order. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org To: Paul Kyzivat cc: interop@omg.org Subject: Re: Issue 3405 Getting ready to vote In-Reply-To: Your message of "Tue, 11 Apr 2000 12:53:27 PDT." <9B164B713EE9D211B6DC0090273CEEA926BDCB@bos1.noblenet.com> From: Bill Janssen Message-Id: <00Apr11.141739pdt."3432"@watson.parc.xerox.com> Date: Tue, 11 Apr 2000 14:17:43 PDT Content-Type: text X-UIDL: @";e94lWd9HV@e9`Ab!! > 1-bit unicode? That must use some really fancy coding techniques! > Seriously, did you mean 16-bit? Can you say more? > I was surprised when Bill said that UTF8 covers a bigger code space > than > UTF16. Can that really be true? Yep. UTF-16 covers 20 bits, and is big-endian. UTF-8 covers 31 bits, and is endian-neutral. No mystery, really; they were just defined in different contexts. Bill To: "Rutt, T E (Tom)" cc: interop@omg.org, "'Paul Kyzivat'" Subject: Re: Issue 3405 Getting ready to vote In-Reply-To: Your message of "Tue, 11 Apr 2000 12:18:33 PDT." From: Bill Janssen Message-Id: <00Apr11.141554pdt."3432"@watson.parc.xerox.com> Date: Tue, 11 Apr 2000 14:16:04 PDT Content-Type: text X-UIDL: M$Ie9hU/!!DgP!!!bf!! > If the UTF16 is in an encapsulation, why cannot we use the byte > order of the > encapsulation to determine the byte order of its contained UTF16 > along with the > integers? Because (he says again) UTF-16 is explicitly big-endian. So there's no question about its byte order. Bill To: Jonathan Biggar cc: "Rutt, T E (Tom)" , interop@omg.org, "'Paul Kyzivat'" Subject: Re: Issue 3405 Getting ready to vote In-Reply-To: Your message of "Tue, 11 Apr 2000 12:57:25 PDT." <38F3838F.F15F9012@floorboard.com> From: Bill Janssen Message-Id: <00Apr11.141944pdt."3432"@watson.parc.xerox.com> Date: Tue, 11 Apr 2000 14:19:55 PDT Content-Type: text X-UIDL: "XM!!eA!!!bF2!!bY\!! > Yes, but technically it's not UTF16 anymore, since UTF16 requires > big-endian byte order. Yes, I think what Tom meant is UCS-2 (which only covers 16 bits), with the byte-order being determined by byte order of the message or encapsulation. I continue to believe that UTF-8, handling for which we need to have anyway, is a better choice. Bill From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Getting ready to vote Date: Tue, 11 Apr 2000 18:29:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: CO"!!!XRd9LUU!!"@+!! > From: Bill Janssen [mailto:janssen@parc.xerox.com] > > 1-bit unicode? That must use some really fancy coding techniques! > > Seriously, did you mean 16-bit? Can you say more? > > I was surprised when Bill said that UTF8 covers a bigger > code space than > > UTF16. Can that really be true? > > Yep. UTF-16 covers 20 bits, and is big-endian. UTF-8 covers 31 > bits, > and is endian-neutral. No mystery, really; they were just defined > in > different contexts. weird! In another message Bill continued: > Yes, I think what Tom meant is UCS-2 (which only covers 16 bits), with > the byte-order being determined by byte order of the message or > encapsulation. I continue to believe that UTF-8, handling for which > we need to have anyway, is a better choice. What is the point of having two in memory representations but essentially a single wire representation? It bugs me to have representations where it takes an entire pass over the data to determine the size of the other representation. This can be a messy and expensive problem, especially when strings are large and messages are fragmented. It may be justified to pay this cost if somebody goes out of their way to negotiate this, but it doesn't seem like a great default. Paul To: Paul Kyzivat cc: interop@omg.org Subject: Re: Issue 3405 Getting ready to vote In-Reply-To: Your message of "Tue, 11 Apr 2000 15:27:39 PDT." <9B164B713EE9D211B6DC0090273CEEA926BDD1@bos1.noblenet.com> From: Bill Janssen Message-Id: <00Apr11.162831pdt."3432"@watson.parc.xerox.com> Date: Tue, 11 Apr 2000 16:28:37 PDT Content-Type: text X-UIDL: OLB!!oeKe9>WG!!I@Wd9 > It bugs me to have representations where it takes an entire pass over the > data to determine the size of the other representation. This can be a messy > and expensive problem, especially when strings are large and messages are > fragmented. It may be justified to pay this cost if somebody goes out of > their way to negotiate this, but it doesn't seem like a great default. I think the efficiency games for Unicode with respect to languages and operating systems are poorly understood at best. We probably can't hope to make a good choice here. I seem to recall hearing someone say once that Sun is using 32-bit Unicode (presumably UCS-4) as their `native' wide character set; can anyone confirm that? And if so, which programming languages does that apply to? I've also heard that Windows NT can use UCS-2 as their native wide character set, which seems oddly limiting given the grandiose dreams that Microsoft seems to have for Windows. Choosing one of these formats (UCS-4 or UCS-2) might give you some marshalling efficiency for some platform/programming-language combinations, *if* the string you're marshalling happens to be in that format (and not UTF-16 or UTF-8 already). On the other hand, you're paying for it with a lot of on-the-wire inefficiency. UTF-8 seems like a better tradeoff, in my mind. Better on-the-wire efficiency, endian-neutral to allow you to just grab it and stuff it somewhere else, and compatible with already-mandated machinery. But you may well pay a marshalling cost of some kind. We should be copying all of this to some Unicode discussion list, to get some authoritative answers on who's using what for what. Bill cc: Paul Kyzivat , interop@omg.org To: To: Subject: Re: Issue 3405 Getting ready to vote In-Reply-To: Your message of "Tue, 11 Apr 2000 16:28:53 PDT." <00Apr11.162831pdt."3432"@watson.parc.xerox.com> From: Bill Janssen Message-Id: <00Apr11.194354pdt."3438"@watson.parc.xerox.com> Date: Tue, 11 Apr 2000 19:44:08 PDT Content-Type: text X-UIDL: B1pd99gGe9Q,2!!$J From: Martin von Loewis To: janssen@parc.xerox.com CC: paulk@roguewave.com, interop@omg.org In-reply-to: <00Apr11.162831pdt."3432"@watson.parc.xerox.com> (message from Bill Janssen on Tue, 11 Apr 2000 16:28:37 PDT) Subject: Re: Issue 3405 Getting ready to vote References: <00Apr11.162831pdt."3432"@watson.parc.xerox.com> User-Agent: SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.6 (sparc-sun-solaris2.6) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-UIDL: 4DUd9LI6!!n\*e9,QQd9 > I seem to recall hearing someone say once that Sun is using 32-bit > Unicode (presumably UCS-4) as their `native' wide character set; can > anyone confirm that? On Solaris, wchar_t is a 32-bit integral type; I believe this is mandated by the Unix ABI for most architectures. The iconv function supports conversion both into UCS-2 and UCS-4, see iconv_unicode(5) for details. I don't know what the consequences are beyond internal representation; the only Unicode locales supported by Solaris 7 are UTF-8 locales. > And if so, which programming languages does that apply to? The definition of wchar_t would apply to every language that typically links to C (e.g. C++). Applications are free, of course, to not use this type. > I've also heard that Windows NT can use UCS-2 as their native wide > character set, which seems oddly limiting given the grandiose dreams > that Microsoft seems to have for Windows. One may think that UTF-16 was invented precisely to offer an escape path... Regards, Martin From: "Rutt, T E (Tom)" To: interop@omg.org Subject: RE: Issue 3405 Getting ready to vote Date: Wed, 12 Apr 2000 10:58:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: fZWd9&e ---------- > From: Bill Janssen[SMTP:janssen@parc.xerox.com] > Sent: Tuesday, April 11, 2000 10:44 PM > To: interop@omg.org; paulk@roguewave.com > Cc: Paul Kyzivat; interop@omg.org > Subject: Re: Issue 3405 Getting ready to vote > > Well, I'm running across more information that makes it necessary to > actually go upstairs and crack the Unicode tome in the library. In > particular, Mark Davis, the president of the Unicode Consortium, and > a > true authority, explicitly refutes my claim that UTF-16 is always > big-endian, in > > http://www-4.ibm.com/software/developer/library/utfencodingforms/index.htm > l. > > My guess is that the UTF-16 defined in this article is the *Unicode > Consortium's* definition of it, while the one registered with our > character set registry is the ISO 10646 definition of it, which may > be > more restrictive. > > See also http://www.unicode.org/. > > Bill > From: "Rutt, T E (Tom)" To: interop@omg.org, "'Paul Kyzivat'" Subject: RE: Issue 3405 Getting ready to vote Date: Wed, 12 Apr 2000 13:01:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: ",Z!!Ek3!!@k9!!ICm!! > ---------- > From: Paul Kyzivat[SMTP:paulk@roguewave.com] > Sent: Tuesday, April 11, 2000 6:29 PM > To: interop@omg.org > Subject: RE: Issue 3405 Getting ready to vote > > > From: Bill Janssen [mailto:janssen@parc.xerox.com] > > > > 1-bit unicode? That must use some really fancy coding > techniques! > > > Seriously, did you mean 16-bit? Can you say more? > > > I was surprised when Bill said that UTF8 covers a bigger > > code space than > > > UTF16. Can that really be true? > > I meant utf-16. They have a new trick to extend it to 17 planes. It > is not anticipated that the Unicode codepoints will ever get to 17 planes. Plane 0 is > unicode 16 (or Basic Multilingual Plane). Plane 1 is being filled up now (Klingon is in > plane 1). > > Yep. UTF-16 covers 20 bits, and is big-endian. UTF-8 covers 31 bits, > > and is endian-neutral. No mystery, really; they were just defined in > > different contexts. > > weird! > > In another message Bill continued: > > > Yes, I think what Tom meant is UCS-2 (which only covers 16 bits), with > > the byte-order being determined by byte order of the message or > > encapsulation. I continue to believe that UTF-8, handling for which > > we need to have anyway, is a better choice. > I meant UTF-16. Please read the character encoding model TR 17 http://www.unicode.org/unicode/reports/tr17/tr17-3 > What is the point of having two in memory representations but essentially > a > single wire representation? > > It bugs me to have representations where it takes an entire pass over the > data to determine the size of the other representation. This can be a > messy > and expensive problem, especially when strings are large and messages are > fragmented. It may be justified to pay this cost if somebody goes out of > their way to negotiate this, but it doesn't seem like a great default. > > Paul > Date: Thu, 13 Apr 2000 07:18:59 +1000 (EST) From: Michi Henning To: "Rutt, T E (Tom)" cc: interop@omg.org, "'Paul Kyzivat'" Subject: RE: Issue 3405 Getting ready to vote In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: OAZ!!n0Qd9^\k!!Z?9e9 On Wed, 12 Apr 2000, Rutt, T E (Tom) wrote: > Plane 1 is being filled up now (Klingon is in plane 1). Gee, isn't it refreshing to see how international standards bodies worry about the things that *really* matter? ;-) Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html To: Martin von Loewis cc: paulk@roguewave.com, interop@omg.org Subject: Re: Issue 3405 Getting ready to vote In-Reply-To: Your message of "Wed, 12 Apr 2000 01:43:20 PDT." <200004120843.KAA09940@pandora> From: Bill Janssen Message-Id: <00Apr12.155417pdt."3438"@watson.parc.xerox.com> Date: Wed, 12 Apr 2000 15:54:22 PDT Content-Type: text X-UIDL: Ld~e9MR5!!B&4e9lH>e9 > > I've also heard that Windows NT can use UCS-2 as their native wide > > character set, which seems oddly limiting given the grandiose > dreams > > that Microsoft seems to have for Windows. > > One may think that UTF-16 was invented precisely to offer an escape > path... Yes, I believe the current UTF-16 was indeed an escape path from 16 bits to 20 bits. Bill To: "Rutt, T E (Tom)" cc: interop@omg.org Subject: Re: Issue 3405 Getting ready to vote In-Reply-To: Your message of "Wed, 12 Apr 2000 08:02:39 PDT." From: Bill Janssen Message-Id: <00Apr12.161103pdt."3438"@watson.parc.xerox.com> Date: Wed, 12 Apr 2000 16:11:12 PDT Content-Type: text X-UIDL: D!`d94FTd9&~[d9l&F!! > Another good reference is the following unicode technical report "character > encoding model" > from the unicode consortia. > > http://www.unicode.org/unicode/reports/tr17/tr17-3 Agreed. In particular, it lays out the vocabulary (from the Unicode Consortium's point of view). What we are trying to agree on is called a "Character Encoding Scheme", which is ``a mapping of code units into serialized byte sequences''. Bill Date: Wed, 12 Apr 2000 16:33:46 -0700 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: Martin von Loewis , paulk@roguewave.com, interop@omg.org Subject: Re: Issue 3405 Getting ready to vote References: <00Apr12.155417pdt."3438"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: \/3e9m2-e9Z@#"!Y1Ld9 At this point, UTF-8 sounds reasonable to me for this service context. Doesn't this simply specify default encoding? In other words, what happens if a transmission code set has been negotiated to be different from the default encoding for a particular service context? Bill Janssen wrote: > > > I've also heard that Windows NT can use UCS-2 as their native wide > > > character set, which seems oddly limiting given the grandiose dreams > > > that Microsoft seems to have for Windows. > > > > One may think that UTF-16 was invented precisely to offer an escape > > path... > > Yes, I believe the current UTF-16 was indeed an escape path from 16 > bits to 20 bits. > > Bill Sender: jbiggar@corvette.floorboard.com Message-ID: <38F50F44.5C722B31@floorboard.com> Date: Wed, 12 Apr 2000 17:05:24 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "M. Mortazavi" CC: Bill Janssen , Martin von Loewis , paulk@roguewave.com, interop@omg.org Subject: Re: Issue 3405 Getting ready to vote References: <00Apr12.155417pdt."3438"@watson.parc.xerox.com> <38F507D9.37EEC445@eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: MnIe9k%]!!597!!8kD!! "M. Mortazavi" wrote: > > At this point, UTF-8 sounds reasonable to me for this service > context. > > Doesn't this simply specify default encoding? > > In other words, what happens if a transmission code set has been > negotiated to be > different from the default encoding for a particular service > context? Encapsulations define their own codeset, which is independent of the negotiated codeset. This is to guarantee that things like TypeCodes and IOR components don't have to be munged* and remunged all the time. *Munged is a technical term that means "messed with". :-) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Sun, 16 Apr 2000 14:14:32 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interop@omg.org Subject: Re: Issue 3405 Getting ready to vote References: <9B164B713EE9D211B6DC0090273CEEA926BDD1@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,kmd9dS`!!$2Ke9M1Ne9 Status: U Paul, Paul Kyzivat wrote: > > > From: Bill Janssen [mailto:janssen@parc.xerox.com] > > > > 1-bit unicode? That must use some really fancy coding techniques! > > > Seriously, did you mean 16-bit? Can you say more? > > > I was surprised when Bill said that UTF8 covers a bigger > > code space than > > > UTF16. Can that really be true? > > > > Yep. UTF-16 covers 20 bits, and is big-endian. UTF-8 covers 31 bits, > > and is endian-neutral. No mystery, really; they were just defined in > > different contexts. > > weird! > > In another message Bill continued: > > > Yes, I think what Tom meant is UCS-2 (which only covers 16 bits), with > > the byte-order being determined by byte order of the message or > > encapsulation. I continue to believe that UTF-8, handling for which > > we need to have anyway, is a better choice. > > What is the point of having two in memory representations but essentially a > single wire representation? > > It bugs me to have representations where it takes an entire pass over the > data to determine the size of the other representation. This can be a messy > and expensive problem, especially when strings are large and messages are > fragmented. It may be justified to pay this cost if somebody goes out of > their way to negotiate this, but it doesn't seem like a great default. > But this is the fallback for both TCS-C and TCS-W if there is no common codeset between sender and receiver. Are you unhappy with that as well? Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 17 Apr 2000 02:42:45 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interop@omg.org Subject: Re: Issue 3405 References: <9B164B713EE9D211B6DC0090273CEEA926BD8D@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: WY[d9de9e9egmd9~5&!! Status: U Paul, Paul Kyzivat wrote: > > Simon, > > Two questions (actually 2.5) for you: > > 1) do you really want this to apply to USER_EXCEPTION? > No. My proposal was tor system exceptions only. > 1a) if so, what should happen to this data if the exception is not known > and is put into an Any in an UnknownUserException? > > 2) you are trying to put a wstring into an encapsulation. > The rules (revision just voted) are that encapsulations are > done using giop 1.0 (doesn't support wstring) unless explicitly > stated. If you state some other giop version and use wchars > or wstrings, then you must specify the codeset to be used. > Are you prepared to be the guinea pig for that? > There's no way round this. Specifying string instead of wstring would not allow this detail message facility to be used by the Java to IDL mapping. > (This codeset thing is going to keep biting us until we kill it!) > OK, all together now... Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 17 Apr 2000 02:55:37 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interop@omg.org Subject: Re: Issue 3405 References: <9B164B713EE9D211B6DC0090273CEEA926BDCA@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ELQe9J84e9;S&e9aUNe9 Status: U Paul, Paul Kyzivat wrote: > > Simon, > > I wasn't ruling out interceptors only, but while there seems to be no reason > to prevent an interceptor from being registered for this sc, I don't think > an interceptor has enough capability to fully provide the functionality > intended. So some non-interceptor-based handling of this seems required. > > As long as the normal processing of this is not via interceptors, using one > or several sc's seems irrelevant on that score. > > The main reason I am inclined toward separate sc's is to: > - avoid double encapsulation > - eliminate the need for a separate registry > > But some new problems have occured to me regarding the use of sc's for this > in general: > > - the order in which this stuff is processed. SCs are required to be decoded > and processed before the reply body. So, there won't yet be an exception to > attach this data to. The data will have to be held until after the exception > is decoded, and then attached. This is at least inconvenient. It is also > another problem with using interceptors to handle this SC. > I don't think the ORB can handle this using interceptors alone. However I think it is reasonable to allow interceptors to inspect and perhaps manipulate the detail messages. I don't think the processing order issue is a big deal, since one or other of these must inevitably be decoded first before the two are combined. > - as of GIOP 1.2, system exceptions can be returned with LocateReply > messages. But LocateReply messages don't carry service contexts. > Perhaps we should relax this LocateReply restriction in GIOP 1.3. For now, I can live with not being able to pass text messages on these exceptions. > - if an exception can be passed as data (now or in the future) the use of > this SC to carry part of the exception will be a real problem. I forget if > it is currently legal to marshal an Any containing an exception. If so, this > would be one such case. This would also rule out any hope of making > exceptions first class data types. > Exceptions can only be "raised" by method invocations. They can't be inserted into anys. If we want to make system exceptions first-class types in the future, we should design this in such a way that this service context is no longer needed. This would include using an extensible data format for marshalling system exceptions. But I didn't hear much support for this when we last discussed it. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 17 Apr 2000 13:36:46 +1000 (EST) From: Michi Henning To: Simon Nash cc: Paul Kyzivat , interop@omg.org Subject: Re: Issue 3405 In-Reply-To: <38FA6F19.FF54585C@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: VB@!!lBDe9~%'!!M"ed9 Status: U On Mon, 17 Apr 2000, Simon Nash wrote: > > - if an exception can be passed as data (now or in the future) the use of > > this SC to carry part of the exception will be a real problem. I forget if > > it is currently legal to marshal an Any containing an exception. If so, this > > would be one such case. This would also rule out any hope of making > > exceptions first class data types. > > > Exceptions can only be "raised" by method invocations. They can't be > inserted into anys. No. At least in C++, you *can* insert an exception into an Any. Because an exception has a well-defined type code and on-the-wire representation, this also means that I can marshal an Any containing an exception. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Mon, 17 Apr 2000 18:16:46 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Paul Kyzivat , interop@omg.org Subject: Re: Issue 3405 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: maX!!mGI!!!Xm!!)~-e9 Michi, Thanks for putting me straight. I'm surprised by this, since exceptions can't be passed as method arguments outside of anys, for no reason that I've been able to understand. This revelation makes that limitation even more puzzling to me. I checked the Java support for this, and it appears to be possible to insert and extract user exceptions (which have Streamable holder classes) into an any, but not system exceptions. Does the same distinction apply in C++? If so (always the optimist), we would be OK since only system exceptions could have a detail message. Simon Michi Henning wrote: > > On Mon, 17 Apr 2000, Simon Nash wrote: > > > > - if an exception can be passed as data (now or in the future) the use of > > > this SC to carry part of the exception will be a real problem. I forget if > > > it is currently legal to marshal an Any containing an exception. If so, this > > > would be one such case. This would also rule out any hope of making > > > exceptions first class data types. > > > > > Exceptions can only be "raised" by method invocations. They can't be > > inserted into anys. > > No. At least in C++, you *can* insert an exception into an Any. Because > an exception has a well-defined type code and on-the-wire representation, > this also means that I can marshal an Any containing an exception. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Tue, 18 Apr 2000 08:05:38 +1000 (EST) From: Michi Henning To: Simon Nash cc: Paul Kyzivat , interop@omg.org Subject: Re: Issue 3405 In-Reply-To: <38FB46FE.DEC71CEA@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: \e#!!#Jkd9\]&!!KB1e9 On Mon, 17 Apr 2000, Simon Nash wrote: > Michi, > Thanks for putting me straight. I'm surprised by this, since exceptions > can't be passed as method arguments outside of anys, for no reason that > I've been able to understand. This revelation makes that limitation even > more puzzling to me. > > I checked the Java support for this, and it appears to be possible to > insert and extract user exceptions (which have Streamable holder classes) > into an any, but not system exceptions. Does the same distinction apply > in C++? If so (always the optimist), we would be OK since only system > exceptions could have a detail message. With the C++ mapping, I can insert and extract both system and user exceptions. This was never be meant to be used as a back-door way to marshal exceptions as parameters. Rather, the feature was introduced to deal with exception handling in the DII. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@corvette.floorboard.com Message-ID: <38FBA427.97AB8E7D@floorboard.com> Date: Mon, 17 Apr 2000 16:54:15 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Simon Nash , Paul Kyzivat , interop@omg.org Subject: Re: Issue 3405 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: X33e9\GE!!/-/!!E]He9 Michi Henning wrote: > > On Mon, 17 Apr 2000, Simon Nash wrote: > > > Michi, > > Thanks for putting me straight. I'm surprised by this, since exceptions > > can't be passed as method arguments outside of anys, for no reason that > > I've been able to understand. This revelation makes that limitation even > > more puzzling to me. > > > > I checked the Java support for this, and it appears to be possible to > > insert and extract user exceptions (which have Streamable holder classes) > > into an any, but not system exceptions. Does the same distinction apply > > in C++? If so (always the optimist), we would be OK since only system > > exceptions could have a detail message. > > With the C++ mapping, I can insert and extract both system and user exceptions. > This was never be meant to be used as a back-door way to marshal exceptions > as parameters. Rather, the feature was introduced to deal with exception > handling in the DII. I would definately be in favor of adding text to the C++ mapping that clarifies that using Anys to hold exceptions is only for use with the DII and/or DSI, and not for transmitting exceptions via a random Any parameter. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 18 Apr 2000 09:55:40 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Simon Nash , Paul Kyzivat , interop@omg.org Subject: Re: Issue 3405 In-Reply-To: <38FBA427.97AB8E7D@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: OYL!!\`hd9$Ol!!N^Md9 On Mon, 17 Apr 2000, Jonathan Biggar wrote: > > With the C++ mapping, I can insert and extract both system and user exceptions. > > This was never be meant to be used as a back-door way to marshal exceptions > > as parameters. Rather, the feature was introduced to deal with exception > > handling in the DII. > > I would definately be in favor of adding text to the C++ mapping that > clarifies that using Anys to hold exceptions is only for use with the > DII and/or DSI, and not for transmitting exceptions via a random Any > parameter. Yes, I'd certainly support that. Cheers, Michi. To: Jonathan Biggar cc: Michi Henning , Simon Nash , Paul Kyzivat , interop@omg.org Subject: Re: Issue 3405 In-Reply-To: Your message of "Mon, 17 Apr 2000 16:59:49 PDT." <38FBA427.97AB8E7D@floorboard.com> From: Bill Janssen Message-Id: <00Apr17.171957pdt."3438"@watson.parc.xerox.com> Date: Mon, 17 Apr 2000 17:20:03 PDT Content-Type: text X-UIDL: Ap6!!mTHe97c\!!'Oid9 > I would definately be in favor of adding text to the C++ mapping that > clarifies that using Anys to hold exceptions is only for use with the > DII and/or DSI, and not for transmitting exceptions via a random Any > parameter. Me too. Bill To: Simon Nash cc: Michi Henning , Paul Kyzivat , interop@omg.org Subject: Re: Issue 3405 In-Reply-To: Your message of "Mon, 17 Apr 2000 10:23:31 PDT." <38FB46FE.DEC71CEA@hursley.ibm.com> From: Bill Janssen Message-Id: <00Apr17.171732pdt."3438"@watson.parc.xerox.com> Date: Mon, 17 Apr 2000 17:17:43 PDT Content-Type: text X-UIDL: OSEe9&D0e9#3ad9\UOe9 Simon, > Thanks for putting me straight. I'm surprised by this, since exceptions > can't be passed as method arguments outside of anys, for no reason that > I've been able to understand. This limitation is because exceptions are semantically different than objects, and in some languages are really different (Modula-3 comes to mind). Recently, it has become fashionable to (1) add object systems to programming languages, and (2) use the object system to model exception types. But it hasn't always been that way, and the CORBA type system provides for that. It's actually a particularly bletcherous part of the generally bletcherous DII interface that allows exception to be `put into' an any, or removed from it. That was not part of the original design; exceptions were only manipulable with raise and catch. Bill Date: Tue, 18 Apr 2000 09:52:02 +0100 From: Owen Rees To: Bill Janssen , Simon Nash Cc: Michi Henning , Paul Kyzivat , interop@omg.org Subject: Re: Issue 3405 Message-ID: <2568782366.956051522@rees-o-home-1.hpl.hp.com> In-Reply-To: <00Apr17.171732pdt."3438"@watson.parc.xerox.com> X-Mailer: Mulberry/2.0.0 (Win32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii; format=flowed X-UIDL: A,Ud9i28!!aC\!!!V;e9 --On 17 April 2000 17:17 +0000 Bill Janssen wrote: It's actually a particularly bletcherous part of the generally bletcherous DII interface that allows exception to be `put into' an any, or removed from it. That was not part of the original design; exceptions were only manipulable with raise and catch. Even for those languages which can map CORBA exceptions to language exceptions, I am not sure that raise and catch are sufficient in the case where DII and DSI are most needed. If you are constructing a request level bridge that has to replace every object reference that goes by, you have to process user exceptions that contain object references. If the bridge is generic, with no static information about the types it will handle, there has to be some way to navigate through the structure of an UnknownUserException, and create/raise/return a new instance if necessary. Putting an exception into an Any may be ugly, but where it can be done generically, it is effective. I have found that it is harder to handle system exceptions generically than user exceptions; I have never been able to work out if the specification says you ought to be able to put a SystemException (not knowing its specific type) into an Any, there are certainly some ORBs that do not support this, and it makes things difficult for a generic request level bridge implementor. Exceptions in Any's may be ugly, but at least this means that there is a generic way to navigate around the structure, so you are not forced into open-ended special case feature bloat the way you are when data is passed as sequence with a magic flag, as it is with Service Contexts. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Getting ready to vote Date: Tue, 18 Apr 2000 11:45:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: LDWd9nb^!!nbed9*`G!! > From: Simon Nash [mailto:nash@hursley.ibm.com] > > It bugs me to have representations where it takes an entire > pass over the > > data to determine the size of the other representation. > This can be a messy > > and expensive problem, especially when strings are large > and messages are > > fragmented. It may be justified to pay this cost if > somebody goes out of > > their way to negotiate this, but it doesn't seem like a > great default. > > > But this is the fallback for both TCS-C and TCS-W if there is > no common codeset between sender and receiver. > Are you unhappy with that as well? Yes! However I fear this is a lost cause. From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Date: Tue, 18 Apr 2000 12:26:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: npad9iP5e9hFI!!:@Y!! > From: Simon Nash [mailto:nash@hursley.ibm.com] > > - the order in which this stuff is processed. SCs are > required to be decoded > > and processed before the reply body. So, there won't yet be > an exception to > > attach this data to. The data will have to be held until > after the exception > > is decoded, and then attached. This is at least > inconvenient. It is also > > another problem with using interceptors to handle this SC. > > > I don't think the ORB can handle this using interceptors > alone. However > I think it is reasonable to allow interceptors to inspect and perhaps > manipulate the detail messages. I don't think the processing > order issue > is a big deal, since one or other of these must inevitably be > decoded first before the two are combined. The more things (especially optional things) that we invent that can't be handled with interceptors, the fatter every orb gets. But as things are shaping up I agree that an interceptor can't do it all. But this may be indicative of a less than ideal design. > > - as of GIOP 1.2, system exceptions can be returned with LocateReply > > messages. But LocateReply messages don't carry service contexts. > > > Perhaps we should relax this LocateReply restriction in GIOP > 1.3. For now, > I can live with not being able to pass text messages on these > exceptions. Are you suggesting that LocateReply (and presumably LocateRequest) should carry service contexts? I think that may actually be a reasonable thing to do if we are going to continue to abuse SCs as we are. > > > - if an exception can be passed as data (now or in the > future) the use of > > this SC to carry part of the exception will be a real > problem. I forget if > > it is currently legal to marshal an Any containing an > exception. If so, this > > would be one such case. This would also rule out any hope of making > > exceptions first class data types. > > > Exceptions can only be "raised" by method invocations. They can't be > inserted into anys. If we want to make system exceptions > first-class types > in the future, we should design this in such a way that this > service context > is no longer needed. This would include using an extensible > data format for > marshalling system exceptions. But I didn't hear much > support for this > when we last discussed it. This has already been discussed. We are forced to permit exceptions in Anys for use in the DII and DSI, although it was a bad idea. I seem to recall this being discussed as part of some issue several months (or years) back, with a conclusion that it should not be legal to marshal an Any containing an exception. Am I just dreaming that, or does someone else remember it? This is another area where our type system is already screwed up. Paul Reply-To: From: "Nick Sharman" To: Subject: RE: Issue 3405 Date: Tue, 18 Apr 2000 17:51:50 +0100 Message-ID: <006f01bfa956$649d5f60$5610a8c0@thumper.uk.peerlogic.com> 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 V4.72.3110.3 Importance: Normal In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BDFC@bos1.noblenet.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ;[~!!3H From: Paul Kyzivat [mailto:paulk@roguewave.com] > > This has already been discussed. We are forced to permit > exceptions in Anys > for use in the DII and DSI, although it was a bad idea. I seem to recall > this being discussed as part of some issue several months (or years) back, > with a conclusion that it should not be legal to marshal an Any containing > an exception. Am I just dreaming that, or does someone else remember it? > We share the same delusion. In my dream, I asked the question, and others (including Michi, I think) reckoned it should be illegal. > This is another area where our type system is already screwed up. > > Paul > Yup. Nick Date: Wed, 19 Apr 2000 07:41:37 +1000 (EST) From: Michi Henning To: Nick Sharman cc: interop@omg.org Subject: RE: Issue 3405 In-Reply-To: <006f01bfa956$649d5f60$5610a8c0@thumper.uk.peerlogic.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ZKld9`g6!!:>Me9NH1e9 On Tue, 18 Apr 2000, Nick Sharman wrote: > > From: Paul Kyzivat [mailto:paulk@roguewave.com] > > > > This has already been discussed. We are forced to permit > > exceptions in Anys > > for use in the DII and DSI, although it was a bad idea. I seem to recall > > this being discussed as part of some issue several months (or years) back, > > with a conclusion that it should not be legal to marshal an Any containing > > an exception. Am I just dreaming that, or does someone else remember it? > > > We share the same delusion. In my dream, I asked the question, and others > (including Michi, I think) reckoned it should be illegal. This was discussed as part of issues 142, 1289. Unfortunately,no archive of the discussion is available :-( I wouldn't object to raising BAD_PARAM if an attempt is made to marshal an Any containing an exception. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Date: Tue, 18 Apr 2000 19:08:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ]BX!!E]I!!S$,!!)%kd9 > This was discussed as part of issues 142, 1289. > Unfortunately,no archive of the discussion is available :-( Of course, if no archive is available, perhaps we three simply all share the same (bad) dream. > > I wouldn't object to raising BAD_PARAM if an attempt is made > to marshal an Any containing an exception. Do you have a reason to chose that rather than MARSHAL? Barring a strong justification I tend to assume MARSHAL is the exception of choice for marshalling problems. And BAD_PARAM is always just the exception of last resort. Paul Date: Wed, 19 Apr 2000 10:12:09 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interop@omg.org Subject: RE: Issue 3405 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BE06@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: *`pd9hnad9O~f!!oAo!! On Tue, 18 Apr 2000, Paul Kyzivat wrote: > > I wouldn't object to raising BAD_PARAM if an attempt is made > > to marshal an Any containing an exception. > > Do you have a reason to chose that rather than MARSHAL? Yes :-) > Barring a strong justification I tend to assume MARSHAL is the > exception of choice for marshalling problems. And BAD_PARAM > is always just the exception of last resort. According to the definition of MARSHAL in the IDL chapter, it's supposed to be used for corrupted packets, or if an ORB detects a mismatch between the formal parameters of an operation and the actual data in a request/reply. So, MARSHAL is imply inappropriate for this case, whereas BAD_PARAM fits the bill. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Date: Wed, 19 Apr 2000 08:43:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: !)T!!GaL!!UnXd9$L?e9 Michi, I won't argue too hard on this one because it isn't very important. But the definition of what MARSHAL should be used for is the way it is because you wrote the definition, isn't it? Paul > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Tuesday, April 18, 2000 8:12 PM > To: Paul Kyzivat > Cc: interop@omg.org > Subject: RE: Issue 3405 > > > On Tue, 18 Apr 2000, Paul Kyzivat wrote: > > > > I wouldn't object to raising BAD_PARAM if an attempt is made > > > to marshal an Any containing an exception. > > > > Do you have a reason to chose that rather than MARSHAL? > > Yes :-) > > > Barring a strong justification I tend to assume MARSHAL is the > > exception of choice for marshalling problems. And BAD_PARAM > > is always just the exception of last resort. > > According to the definition of MARSHAL in the IDL chapter, > it's supposed > to be used for corrupted packets, or if an ORB detects a > mismatch between > the formal parameters of an operation and the actual data in > a request/reply. > So, MARSHAL is imply inappropriate for this case, whereas > BAD_PARAM fits > the bill. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 20 Apr 2000 07:22:42 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interop@omg.org Subject: RE: Issue 3405 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BE0A@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: $0l!![e)e9?7Wd9%<~!! On Wed, 19 Apr 2000, Paul Kyzivat wrote: > Michi, > > I won't argue too hard on this one because it isn't very important. > But the definition of what MARSHAL should be used for is the way it is > because you wrote the definition, isn't it? Sure is ;-) But seriously, the definitions came about by capturing what ORB implementations did in reality, so I didn't just suck them out of my finger tips ;-) No-one objected at the time (at least not about MARSHAL), so either we raise BAD_PARAM or we change the definition of MARSHAL. Personally, BAD_PARAM still strikes me as correct. After all, it is the application code that causes the error by passing an illegal parameter, and the marshaling code is innocent. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Date: Wed, 19 Apr 2000 17:49:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 3-ed9MU%e97>Xd9*\]!! Michi - I give up. My main problem is that BAD_PARAM is so overworked. But you make a good case anyhow. Paul > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Wednesday, April 19, 2000 5:23 PM > To: Paul Kyzivat > Cc: interop@omg.org > Subject: RE: Issue 3405 > > > On Wed, 19 Apr 2000, Paul Kyzivat wrote: > > > Michi, > > > > I won't argue too hard on this one because it isn't very important. > > But the definition of what MARSHAL should be used for is > the way it is > > because you wrote the definition, isn't it? > > Sure is ;-) But seriously, the definitions came about by > capturing what > ORB implementations did in reality, so I didn't just suck them out of > my finger tips ;-) No-one objected at the time (at least not > about MARSHAL), > so either we raise BAD_PARAM or we change the definition of MARSHAL. > Personally, BAD_PARAM still strikes me as correct. After all, > it is the > application code that causes the error by passing an illegal > parameter, and the marshaling code is innocent. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@corvette.floorboard.com Message-ID: <38FE2BE4.F6FCED07@floorboard.com> Date: Wed, 19 Apr 2000 14:57:56 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Paul Kyzivat , interop@omg.org Subject: Re: Issue 3405 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: p(@!!o2Ae957Yd9eCC!! Michi Henning wrote: > > On Wed, 19 Apr 2000, Paul Kyzivat wrote: > > > Michi, > > > > I won't argue too hard on this one because it isn't very important. > > But the definition of what MARSHAL should be used for is the way it is > > because you wrote the definition, isn't it? > > Sure is ;-) But seriously, the definitions came about by capturing what > ORB implementations did in reality, so I didn't just suck them out of > my finger tips ;-) No-one objected at the time (at least not about MARSHAL), > so either we raise BAD_PARAM or we change the definition of MARSHAL. > Personally, BAD_PARAM still strikes me as correct. After all, it is the > application code that causes the error by passing an illegal parameter, and > the marshaling code is innocent. I think I lean with Michi here. MARSHAL is less specific, since the error could have come from the sending the request or receiving the reply. BAD_PARAM is pretty specific--you passed an illegal parameter to the operation. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Date: Wed, 19 Apr 2000 18:07:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: nDNd99PB!!+)"!!Tb"e9 > From: Jonathan Biggar [mailto:jon@floorboard.com] > I think I lean with Michi here. MARSHAL is less specific, since the > error could have come from the sending the request or receiving the > reply. BAD_PARAM is pretty specific--you passed an illegal > parameter to the operation. I think I agree with you if this happens when a client is attempting to pass an Any containing an exception as an input parameter. But it isn't very clear if it is a server attempting to pass an the Any as an output parameter. The client didn't do anything wrong but is being told he passed a bad parameter. But I don't care enough to argue more about it. Paul Date: Thu, 20 Apr 2000 08:52:19 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interop@omg.org Subject: RE: Issue 3405 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BE11@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: AD6!![AF!!7Cj!! I think I agree with you if this happens when a client is attempting to pass > an Any containing an exception as an input parameter. > > But it isn't very clear if it is a server attempting to pass an the Any as > an output parameter. The client didn't do anything wrong but is being told > he passed a bad parameter. Interesting scenario. However, the completion status in this case will be yes instead of no, so the client can still tell what happened. > But I don't care enough to argue more about it. It's not a matter of one party winning and one party losing, Paul. I'm just trying to keep consistent exception semantics, and I'm not trying to give you a hard time ;-) (And I agree with you that BAD_PARAM is overworked. But it's the only exception we have to deal with this sort of thing...) In hindsight, it was probably wrong to use Any for the DII/DSI exception issue. Instead, a more type-safe interface would have been better... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 20 Apr 2000 03:19:51 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interop@omg.org Subject: Re: Issue 3405 References: <9B164B713EE9D211B6DC0090273CEEA926BDFC@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: -b`d9YcD!!mNS!!LbFe9 Paul, Paul Kyzivat wrote: > > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > > > - the order in which this stuff is processed. SCs are > > required to be decoded > > > and processed before the reply body. So, there won't yet be > > an exception to > > > attach this data to. The data will have to be held until > > after the exception > > > is decoded, and then attached. This is at least > > inconvenient. It is also > > > another problem with using interceptors to handle this SC. > > > > > I don't think the ORB can handle this using interceptors > > alone. However > > I think it is reasonable to allow interceptors to inspect and perhaps > > manipulate the detail messages. I don't think the processing > > order issue > > is a big deal, since one or other of these must inevitably be > > decoded first before the two are combined. > > The more things (especially optional things) that we invent that can't be > handled with interceptors, the fatter every orb gets. But as things are > shaping up I agree that an interceptor can't do it all. But this may be > indicative of a less than ideal design. > > > > > - as of GIOP 1.2, system exceptions can be returned with LocateReply > > > messages. But LocateReply messages don't carry service contexts. > > > > > Perhaps we should relax this LocateReply restriction in GIOP > > 1.3. For now, > > I can live with not being able to pass text messages on these > > exceptions. > > Are you suggesting that LocateReply (and presumably LocateRequest) should > carry service contexts? I think that may actually be a reasonable thing to > do if we are going to continue to abuse SCs as we are. > Yes, I am. > > > > > - if an exception can be passed as data (now or in the > > future) the use of > > > this SC to carry part of the exception will be a real > > problem. I forget if > > > it is currently legal to marshal an Any containing an > > exception. If so, this > > > would be one such case. This would also rule out any hope of making > > > exceptions first class data types. > > > > > Exceptions can only be "raised" by method invocations. They can't be > > inserted into anys. If we want to make system exceptions > > first-class types > > in the future, we should design this in such a way that this > > service context > > is no longer needed. This would include using an extensible > > data format for > > marshalling system exceptions. But I didn't hear much > > support for this > > when we last discussed it. > > This has already been discussed. We are forced to permit exceptions in Anys > for use in the DII and DSI, although it was a bad idea. I seem to recall > this being discussed as part of some issue several months (or years) back, > with a conclusion that it should not be legal to marshal an Any containing > an exception. Am I just dreaming that, or does someone else remember it? > > This is another area where our type system is already screwed up. > I agree. It's history now, and before my time, but I think it would have been better to deal with the DII/DSI exception issue in some other way. Moving swiftly along, are you sure it's necessary to put system exceptions into Anys to deal with the DII/DSI issue? I thought this was only needed to pass back user exceptions. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Thu, 20 Apr 2000 13:13:01 +0100 From: Owen Rees To: Simon Nash , Paul Kyzivat cc: interop@omg.org Subject: Re: Issue 3405 Message-ID: <2753641647.956236381@ews-proj-2.hpl.hp.com> In-Reply-To: <38FE6947.E773CAC6@hursley.ibm.com> X-Mailer: Mulberry/2.0.0 (Win32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii; format=flowed X-UIDL: pn/!!\bPd9>X@!!?B3e9 --On 20 April 2000 03:19 +0100 Simon Nash wrote: I agree. It's history now, and before my time, but I think it would have been better to deal with the DII/DSI exception issue in some other way. Moving swiftly along, are you sure it's necessary to put system exceptions into Anys to deal with the DII/DSI issue? I thought this was only needed to pass back user exceptions. The PIDL set_exception operation is the only way to return an exception, and this in the one that uses an Any (see the last paragraph on page 8-3 in formal/99-10-07.pdf). The operation used to be 'exception' in the old C++ mapping, but the use of an Any has not changed. Note that the paragraph I refer to implies that it is an error to exit the DIR via a language exception mapping of a CORBA exception, but the point is not made clearly. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Reply-To: From: "Nick Sharman" To: , "Portable Interceptors FTF" Subject: RE: Issue 3405 Date: Thu, 20 Apr 2000 14:29:09 +0100 Message-ID: <009701bfaacc$6870daa0$5610a8c0@thumper.uk.peerlogic.com> 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 V4.72.3110.3 Importance: Normal In-Reply-To: <2753641647.956236381@ews-proj-2.hpl.hp.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: C8_!!5>9!!WYL!!iO`!! > From: Owen Rees [mailto:owen_rees@hp.com] > > --On 20 April 2000 03:19 +0100 Simon Nash wrote: > > > I agree. It's history now, and before my time, but I think it > would have > > been better to deal with the DII/DSI exception issue in some other way. > > Moving swiftly along, are you sure it's necessary to put system > exceptions > > into Anys to deal with the DII/DSI issue? I thought this was > only needed > > to pass back user exceptions. > > The PIDL set_exception operation is the only way to return an exception, > and this in the one that uses an Any (see the last paragraph on > page 8-3 in > formal/99-10-07.pdf). The operation used to be 'exception' in the old C++ > mapping, but the use of an Any has not changed. Note that the paragraph I > refer to implies that it is an error to exit the DIR via a language > exception mapping of a CORBA exception, but the point is not made clearly. > In the Portable Interceptors submission (orbos/99-12-02), we have: local interface ClientRequestInfo : RequestInfo { ... readonly attribute any received_exception; ... }; local interface ServerRequestInfo : RequestInfo { ... readonly attribute any sending_exception; ... }; Unlike the RequestInfo attributes that give access to the arguments and results, an ORB can't choose not to make the exception available. And I believe the *_exception attributes are meant to give access to system exceptions as well as user exceptions. So the PI work will make us more dependent on Anys holding exceptions. Unfortunately, although some language bindings use a common base class or interface for all user exceptions and for user and system exeptions (e.g. CORBA::UserException and CORBA::Exception for C++, org.omg.CORBA.UserException and java.lang.exception for Java), there are no such relationships within the IDL type system so it's not easy to avoid exceptions in Anys without descending to PIDL. Any ideas? I can only suggest a new local interface: local interface AnyException { TypeCode type(); }; and require that every user and system exception E support an (implicit) operation "E narrow (in AnyException any_ex);". We would need a DynAnyException as well, I guess. We could then substitute AnyException for each "any" that's supposed to hold an exception. Regards From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3405 Date: Thu, 20 Apr 2000 17:53:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: dpm!!#3Xd9[M,!!0B0e9 Because exceptions can now be carried in LocateReply messages, this "feature" is incomplete as long as it is not possible to send service contexts in LocateReply messages. There are also potential problems with "session context" because LocateRequest messages can be sent on a connection before a Request message. One solution to these is to extend LocateRequest and LocateReply to permit service contexts. However this has implications on interceptors, and probably elsewhere. As a straw poll, should we extend LocateR* in this way? Or should we lump this into the "GIOP 2.0" wishlist? Paul Date: Fri, 21 Apr 2000 08:45:08 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interop@omg.org Subject: RE: Issue 3405 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BE1E@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: PpW!!2@(e9,Qbd92>l!! On Thu, 20 Apr 2000, Paul Kyzivat wrote: > As a straw poll, should we extend LocateR* in this way? > Or should we lump this into the "GIOP 2.0" wishlist? I would prefer that. I'd rather not have a GIOP 1.3 that effectively just does minor tinkering... Cheers, Michi. X-Sender: beckwb@192.84.85.3 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 21 Apr 2000 01:09:04 -0400 To: interop@omg.org From: Bill Beckwith Subject: Re: Issue 3405 Cc: dynamic@ois.com In-Reply-To: <38FE6947.E773CAC6@hursley.ibm.com> References: <9B164B713EE9D211B6DC0090273CEEA926BDFC@bos1.noblenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: NMb!![P"!!aTEe9emO!! WRT to putting exceptions in type Anys: I'm in Las Vegas at the Dynamic Scheduling joint submitters meeting. FYI, we do need the capability of putting an exception (user or system) into a type Any. Our draft IDL reflects this requirement. -- Bill Date: Fri, 21 Apr 2000 01:46:10 -0700 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interop@omg.org Subject: Re: Issue 3405 References: <9B164B713EE9D211B6DC0090273CEEA926BE1E@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: $1#!!IFg!!HfP!!JLQ!! > As a straw poll, should we extend LocateR* in this way? Seems like a good idea, but perhaps we can live without it for right now. Exception service context might remain somewhat incomplete without this but it was never intended that exception service context will provide complete exception handling decision support for system exception cases. It was meant mostly as a usability functionality as far as I can recall. > Or should we lump this into the "GIOP 2.0" wishlist? Depends on the complexity involved and the effect on other important activity such as interceptor ftf, csiv2, etc., which might have some mutual bearing on choices made here. Max From: "Rutt, T E (Tom)" To: interop@omg.org, "'Paul Kyzivat'" Subject: RE: Issue 3405 Date: Fri, 21 Apr 2000 10:06:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: ,Q@e9GV+!!c[\d9O]L!! > ---------- > From: Paul Kyzivat[SMTP:paulk@roguewave.com] > Sent: Thursday, April 20, 2000 5:53 PM > To: interop@omg.org > Subject: RE: Issue 3405 > > Because exceptions can now be carried in LocateReply messages, this > "feature" is incomplete as long as it is not possible to send service > contexts in LocateReply messages. > > There are also potential problems with "session context" because > LocateRequest messages can be sent on a connection before a Request > message. > > One solution to these is to extend LocateRequest and LocateReply to permit > service contexts. However this has implications on interceptors, and > probably elsewhere. > > As a straw poll, should we extend LocateR* in this way? > Or should we lump this into the "GIOP 2.0" wishlist? > I do not think we should have a GIOP 1.3 yet. Lets put this on the GIOP 1.3 wishlist. This can be made a separate issue which we can defer until we are "ready" for products migrating to giop 1.3. -- Tom Rutt Lucent Technologies - Bell Labs Rm 4L-336 Tel: +1(732)949-7862 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA email: terutt@lucent.com Date: Wed, 03 May 2000 21:29:42 +0100 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: terutt@lucent.com CC: interop@omg.org Subject: Revised proposal for issue 3405 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: JS_d9@ZH!!_A,!!*'A!! Tom, Here's a revised proposal for this issue, incorporating various comments from the discussion. I would like this placed in the upcoming vote. If anyone has any comments on this revised proposal, please send them to me ASAP. Proposal: 1. In section 13.6.7, add a new IDL ServiceId constant called ExceptionDetailMessage (value to be allocated). 2. In section 13.6.7, add a new bullet to the ServiceId list as follows: ExceptionDetailMessage identifies a CDR encapsulation of a wstring, encoded using GIOP 1.1 with a TCS-W of UTF-16. This service context may be sent on Reply messages with a reply_status of SYSTEM_EXCEPTION or USER_EXCEPTION, and on LocateReply messages with a locate_status of LOC_SYSTEM_EXCEPTION. The usage of this service context is defined by language mappings. 3. In Table 13-1, add an entry for ExceptionDetailMessage showing that it is part of GIOP 1.2. Discussion of Proposal: The exception detail message is now encoded as a dedicated service context. If further exception diagnostic data is added in the future, additional service contexts can be defined to carry this. The specified encoding for the encapsulated wstring is UTF-16. This seems natural since UTF-16 is the GIOP 1.1 fallback encoding for wstring, and so all ORBs must be able to support this encoding for wstring data. UTF-16 can be big endian or little endian but defaults to big endian. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: Paul Kyzivat To: interop@omg.org Subject: RE: Revised proposal for issue 3405 Date: Thu, 4 May 2000 09:32:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: UaJe99F)!!i;dd9KdB!! Simon, This proposal seems to assume the ability to send service contexts with locate requests. Either we need to also add that capability, or else change this proposal so that it doesn't assume that. Paul > -----Original Message----- > From: Simon Nash [mailto:nash@hursley.ibm.com] > Sent: Wednesday, May 03, 2000 4:30 PM > To: terutt@lucent.com > Cc: interop@omg.org > Subject: Revised proposal for issue 3405 > > > Tom, > Here's a revised proposal for this issue, incorporating > various comments > from the discussion. I would like this placed in the upcoming vote. > > If anyone has any comments on this revised proposal, please > send them to > me ASAP. > > Proposal: > > 1. In section 13.6.7, add a new IDL ServiceId constant called > ExceptionDetailMessage (value to be allocated). > > 2. In section 13.6.7, add a new bullet to the ServiceId list > as follows: > > * ExceptionDetailMessage identifies a CDR encapsulation of > a wstring, > encoded using GIOP 1.1 with a TCS-W of UTF-16. This > service context > may be sent on Reply messages with a reply_status of > SYSTEM_EXCEPTION > or USER_EXCEPTION, and on LocateReply messages with a > locate_status of > LOC_SYSTEM_EXCEPTION. The usage of this service context is defined > by language mappings. > > 3. In Table 13-1, add an entry for ExceptionDetailMessage > showing that it > is part of GIOP 1.2. > > Discussion of Proposal: > > The exception detail message is now encoded as a dedicated > service context. > If further exception diagnostic data is added in the future, > additional > service contexts can be defined to carry this. > > The specified encoding for the encapsulated wstring is > UTF-16. This seems > natural since UTF-16 is the GIOP 1.1 fallback encoding for > wstring, and so > all ORBs must be able to support this encoding for wstring > data. UTF-16 > can be big endian or little endian but defaults to big endian. > > Simon > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > Date: Thu, 04 May 2000 15:15:41 +0100 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: Paul Kyzivat CC: interop@omg.org Subject: Re: Revised proposal for issue 3405 References: <9B164B713EE9D211B6DC0090273CEEA926BE67@bos1.noblenet.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: _:5!!mL-!!OVed9pG6e9 Paul, You are correct. I should have removed this when updating the previous proposal, but I did not. Here's an updated revised proposal: 1. In section 13.6.7, add a new IDL ServiceId constant called ExceptionDetailMessage (value to be allocated). 2. In section 13.6.7, add a new bullet to the ServiceId list as follows: ExceptionDetailMessage identifies a CDR encapsulation of a wstring, encoded using GIOP 1.1 with a TCS-W of UTF-16. This service context may be sent on Reply messages with a reply_status of SYSTEM_EXCEPTION or USER_EXCEPTION. The usage of this service context is defined by language mappings. 3. In Table 13-1, add an entry for ExceptionDetailMessage showing that it is part of GIOP 1.2. Simon Paul Kyzivat wrote: > > Simon, > > This proposal seems to assume the ability to send service contexts with > locate requests. Either we need to also add that capability, or else change > this proposal so that it doesn't assume that. > > Paul > > > -----Original Message----- > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > Sent: Wednesday, May 03, 2000 4:30 PM > > To: terutt@lucent.com > > Cc: interop@omg.org > > Subject: Revised proposal for issue 3405 > > > > > > Tom, > > Here's a revised proposal for this issue, incorporating > > various comments > > from the discussion. I would like this placed in the upcoming vote. > > > > If anyone has any comments on this revised proposal, please > > send them to > > me ASAP. > > > > Proposal: > > > > 1. In section 13.6.7, add a new IDL ServiceId constant called > > ExceptionDetailMessage (value to be allocated). > > > > 2. In section 13.6.7, add a new bullet to the ServiceId list > > as follows: > > > > * ExceptionDetailMessage identifies a CDR encapsulation of > > a wstring, > > encoded using GIOP 1.1 with a TCS-W of UTF-16. This > > service context > > may be sent on Reply messages with a reply_status of > > SYSTEM_EXCEPTION > > or USER_EXCEPTION, and on LocateReply messages with a > > locate_status of > > LOC_SYSTEM_EXCEPTION. The usage of this service context is defined > > by language mappings. > > > > 3. In Table 13-1, add an entry for ExceptionDetailMessage > > showing that it > > is part of GIOP 1.2. > > > > Discussion of Proposal: > > > > The exception detail message is now encoded as a dedicated > > service context. > > If further exception diagnostic data is added in the future, > > additional > > service contexts can be defined to carry this. > > > > The specified encoding for the encapsulated wstring is > > UTF-16. This seems > > natural since UTF-16 is the GIOP 1.1 fallback encoding for > > wstring, and so > > all ORBs must be able to support this encoding for wstring > > data. UTF-16 > > can be big endian or little endian but defaults to big endian. > > > > Simon > > -- > > Simon C Nash, Technology Architect, IBM Java Technology Centre > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > > > -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: "Rutt, T E (Tom)" To: "Rutt, T E (Tom)" , "'Simon Nash'" Cc: interop@omg.org Subject: RE: Revised proposal for issue 3405 Date: Thu, 4 May 2000 11:49:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ampd9*?Ce9e!Me9'Kcd9 > ---------- > From: Simon Nash[SMTP:nash@hursley.ibm.com] > Sent: Wednesday, May 03, 2000 4:29 PM > To: terutt@lucent.com > Cc: interop@omg.org > Subject: Revised proposal for issue 3405 > > Tom, > Here's a revised proposal for this issue, incorporating various comments > from the discussion. I would like this placed in the upcoming vote. > > If anyone has any comments on this revised proposal, please send them to > me ASAP. > > Proposal: > > 1. In section 13.6.7, add a new IDL ServiceId constant called > ExceptionDetailMessage (value to be allocated). > > 2. In section 13.6.7, add a new bullet to the ServiceId list as follows: > > * ExceptionDetailMessage identifies a CDR encapsulation of a wstring, > encoded using GIOP 1.1 with a TCS-W of UTF-16. This service context > may be sent on Reply messages with a reply_status of SYSTEM_EXCEPTION > or USER_EXCEPTION, and on LocateReply messages with a locate_status of > LOC_SYSTEM_EXCEPTION. The usage of this service context is defined > by language mappings. > > 3. In Table 13-1, add an entry for ExceptionDetailMessage showing that it > is part of GIOP 1.2. > > Discussion of Proposal: > > The exception detail message is now encoded as a dedicated service > context. > If further exception diagnostic data is added in the future, additional > service contexts can be defined to carry this. > > The specified encoding for the encapsulated wstring is UTF-16. This seems > natural since UTF-16 is the GIOP 1.1 fallback encoding for wstring, and so > all ORBs must be able to support this encoding for wstring data. UTF-16 > can be big endian or little endian but defaults to big endian. What if we just state that the endian-ness is the same as that of the encapsulation. This would be a clarification for GIOP. What does JAVA do for endian-ness of UTF-16? -- Tom Rutt Lucent Technologies - Bell Labs Rm 4L-336 Tel: +1(732)949-7862 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA email: terutt@lucent.com To: "Rutt, T E (Tom)" cc: "'Simon Nash'" , interop@omg.org Subject: Re: Revised proposal for issue 3405 In-Reply-To: Your message of "Thu, 04 May 2000 17:17:28 PDT." From: Bill Janssen Message-Id: <00May5.104319pdt."3438"@watson.parc.xerox.com> Date: Fri, 5 May 2000 10:43:24 PDT Content-Type: text X-UIDL: H[dd9/~nd9JcB!![9cd9 > What if we just state that the endian-ness is the same as that of the > encapsulation. This would be a clarification for GIOP. > What does JAVA do for endian-ness of UTF-16? We could say that, but then it wouldn't be UTF-16. We could define a new format, and register it with the OSF registry. I got out the ISO spec, and checked this. UTF-16 does indeed ``default'' to big-endian. But the wording of the spec seems to clearly indicate (though it does not clearly say -- well, we know how that goes) that by placing a BOM (byte order marker) at the front of the string, you can send it either way. So, the official interpretation of a UTF-16 string should be: if the first two bytes are FE FF, it's big-endian; if FF FE, it's little-endian; if neither, it's big-endian. Bill From: "Rutt, T E (Tom)" To: "'Bill Janssen'" Cc: "'Simon Nash'" , interop@omg.org Subject: RE: Revised proposal for issue 3405 Date: Fri, 5 May 2000 13:48:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: kbQd9"GH!!:4dd9~?'e9 Ok, I will leave it as UTF-16 from the OSF registry. -- Tom Rutt Lucent Technologies - Bell Labs Rm 4L-336 Tel: +1(732)949-7862 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA email: terutt@lucent.com > ---------- > From: Bill Janssen[SMTP:janssen@parc.xerox.com] > Sent: Friday, May 05, 2000 1:43 PM > To: Rutt, T E (Tom) > Cc: 'Simon Nash'; interop@omg.org > Subject: Re: Revised proposal for issue 3405 > > > What if we just state that the endian-ness is the same as that of the > > encapsulation. This would be a clarification for GIOP. > > What does JAVA do for endian-ness of UTF-16? > > We could say that, but then it wouldn't be UTF-16. We could define a new > format, and register it with the OSF registry. > > I got out the ISO spec, and checked this. UTF-16 does indeed ``default'' > to > big-endian. But the wording of the spec seems to clearly indicate (though > it > does not clearly say -- well, we know how that goes) that by placing a BOM > (byte order marker) at the front of the string, you can send it either > way. > > So, the official interpretation of a UTF-16 string should be: if the > first two bytes are FE FF, it's big-endian; if FF FE, it's > little-endian; if neither, it's big-endian. > > Bill > Date: Sat, 06 May 2000 18:18:23 +0100 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: terutt@lucent.com CC: paulk@roguewave.com, interop@omg.org Subject: [Fwd: Revised proposal for issue 3405] Content-Type: multipart/mixed; boundary="------------5D06C26751F305DF895BAAC7" X-UIDL: LNFe9E#V!!\_F!!N>W!! Tom, The posted resolution for 3405 has an error, as pointed out by Paul. I resent the resolution with the error corrected (see attached email), but unfortunately the original version has been posted, not the revised version. The change was under point 2, removing the text referring to LocateReply messages. Can I therefore propose as a friendly amendmemt to the posted resolution that point 2 be changed to: 2. In section 13.6.7, add a new bullet to the ServiceId list as follows: ExceptionDetailMessage identifies a CDR encapsulation of a wstring, encoded using GIOP 1.1 with a TCS-W of UTF-16. This service context may be sent on Reply messages with a reply_status of SYSTEM_EXCEPTION or USER_EXCEPTION. The usage of this service context is defined by language mappings. Thanks, Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgbReceived: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [9.20.62.15]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA24144 for ; Thu, 4 May 2000 15:54:51 +0100 (BST) Received: from emerald.omg.org (emerald.omg.org [192.67.184.65]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA121544 for ; Thu, 4 May 2000 15:54:44 +0100 Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by emerald.omg.org (8.9.3/8.9.2) with ESMTP id KAA20915 for ; Thu, 4 May 2000 10:20:15 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA34122; Thu, 4 May 2000 15:19:54 +0100 Received: from hursley.ibm.com (shasta.hursley.ibm.com [9.20.11.7]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA22696; Thu, 4 May 2000 15:19:52 +0100 (BST) Message-ID: <3911860D.4D3C263D@hursley.ibm.com> Date: Thu, 04 May 2000 15:15:41 +0100 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: Paul Kyzivat CC: interop@omg.org Subject: Re: Revised proposal for issue 3405 References: <9B164B713EE9D211B6DC0090273CEEA926BE67@bos1.noblenet.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mozilla-Status2: 00000000 Paul, You are correct. I should have removed this when updating the previous proposal, but I did not. Here's an updated revised proposal: 1. In section 13.6.7, add a new IDL ServiceId constant called ExceptionDetailMessage (value to be allocated). 2. In section 13.6.7, add a new bullet to the ServiceId list as follows: ExceptionDetailMessage identifies a CDR encapsulation of a wstring, encoded using GIOP 1.1 with a TCS-W of UTF-16. This service context may be sent on Reply messages with a reply_status of SYSTEM_EXCEPTION or USER_EXCEPTION. The usage of this service context is defined by language mappings. 3. In Table 13-1, add an entry for ExceptionDetailMessage showing that it is part of GIOP 1.2. Simon Paul Kyzivat wrote: > > Simon, > > This proposal seems to assume the ability to send service contexts with > locate requests. Either we need to also add that capability, or else change > this proposal so that it doesn't assume that. > > Paul > > > -----Original Message----- > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > Sent: Wednesday, May 03, 2000 4:30 PM > > To: terutt@lucent.com > > Cc: interop@omg.org > > Subject: Revised proposal for issue 3405 > > > > > > Tom, > > Here's a revised proposal for this issue, incorporating > > various comments > > from the discussion. I would like this placed in the upcoming vote. > > > > If anyone has any comments on this revised proposal, please > > send them to > > me ASAP. > > > > Proposal: > > > > 1. In section 13.6.7, add a new IDL ServiceId constant called > > ExceptionDetailMessage (value to be allocated). > > > > 2. In section 13.6.7, add a new bullet to the ServiceId list > > as follows: > > > > * ExceptionDetailMessage identifies a CDR encapsulation of > > a wstring, > > encoded using GIOP 1.1 with a TCS-W of UTF-16. This > > service context > > may be sent on Reply messages with a reply_status of > > SYSTEM_EXCEPTION > > or USER_EXCEPTION, and on LocateReply messages with a > > locate_status of > > LOC_SYSTEM_EXCEPTION. The usage of this service context is defined > > by language mappings. > > > > 3. In Table 13-1, add an entry for ExceptionDetailMessage > > showing that it > > is part of GIOP 1.2. > > > > Discussion of Proposal: > > > > The exception detail message is now encoded as a dedicated > > service context. > > If further exception diagnostic data is added in the future, > > additional > > service contexts can be defined to carry this. > > > > The specified encoding for the encapsulated wstring is > > UTF-16. This seems > > natural since UTF-16 is the GIOP 1.1 fallback encoding for > > wstring, and so > > all ORBs must be able to support this encoding for wstring > > data. UTF-16 > > can be big endian or little endian but defaults to big endian. > > > > Simon > > -- > > Simon C Nash, Technology Architect, IBM Java Technology Centre > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > > > -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: "Rutt, T E (Tom)" To: "'interop@omg.org'" Subject: FW: FW: Is our interpretation of UTF-16 encoding correct? Date: Thu, 18 May 2000 00:00:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: _ ---------- > From: Kenneth Whistler[SMTP:kenw@sybase.com] > Sent: Wednesday, May 17, 2000 9:00 PM > To: terutt@lucent.com > Cc: Arnold.Winkler@unisys.com; kenw@sybase.com > Subject: RE: FW: Is our interpretation of UTF-16 encoding correct? > > Mr. Rutt, > > Arnold passed your questions on to me, and I will endeavor to > provide you with some answers. > > First of all, it is important to distinguish what we are now > calling "encoding forms" from what we are calling "encoding > schemes". UTF-16 is implicated in both. The full details of > the distinctions are made in the Unicode Technical Report #17, > Character Encoding Model. See: > > http://www.unicode.org/unicode/reports/tr17/ > > But the short take on this is as follows: > > **Encoding forms** essentially describe how the integral > numerical values specified in a character encoding standard > get realized as actual integral datatypes in computers. > In the character encoding, the numerical values are just abstract > integers, unassociated with particular datatypes. The character > encoding form makes that association, so you can actually put > characters into computer registers with known integral data sizes. > > The Unicode Standard now has 3 encoding forms: > > UTF-8 variable width encoding form, using an 8-bit byte as > the datatype (= "code unit"), and using 1 to 4 > of those bytes per character > > UTF-16 variable width encoding form, using a 16-bit word (= "wyde") > as the datatype, and using 1 to 2 of those wydes per > character > > UTF-32 fixed width encoding form, using a 32-bit word as the > datatype, and always using exactly 1 of those words > per character > > The encoding forms are relevant to in-memory processing of Unicode > data. It is also critical for API's to specify exactly which > encoding form they are using, since the character and string > parameters have to be bound to particular size datatypes by the > compilers and linkers. > > The BOM is not relevant when you are talking about encoding forms, > since you do not need it for in-memory processing, any more than > you need such a mechanism to tell your compiler what order to > put the bytes for handling a 16-, 32-, or 64-bit integer as a > number in registers or in API's. That stuff is all handled automatically > on each platform by the compilers. > > **Encoding schemes** describe how character data expressed in a > particular encoding form is serialized into byte streams. > > UTF-8 doesn't need any particular encoding scheme, since it is > byte-oriented already. You just pump out the bytes. > > UTF-16 has the byte-order problem when serialized as a byte stream. > As a result, there are *three* encoding schemes associated with it: > > UTF-16 if BOM present, 0xFE 0xFF ==> msb first > 0xFF 0xFE ==> lsb first > else msb first > > UTF-16BE msb first, no BOM > > UTF-16LE lsb first, no BOM > > In other words, the UTF-16BE and UTF-16LE encoding schemes require > no BOM signature (in fact they disallow it); these assume that the > information about byte order is identified correctly outside the > stream itself, for example, in MIME fields, other markup, > system context, or whatever. UTF-16 as an encoding *scheme* allows > the use of BOM as a signature, so that the stream can be self-identifying > as to byte order. > > UTF-32 is handled exactly by analogy to UTF-16. There are three > encoding schemes, UTF-32, UTF-32BE, UTF-32LE -- and their interpretation > is comparable, except that 32-bit entities are being serialized as > 4 bytes, and the signature BOM is 0x00 0x00 0xFE 0xFF, and so on. > > O.k., now with all that background in place, I can try to get to > your particular questions. > > First, I think you need to sharply distinguish *string* API's and > *streams*. All the string-handling API's should be dealing with > the encoding forms. When you are talking about wide strings (i.e., > Unicode strings in UTF-16 encoding form, bound to unsigned short* > in C or C++), then you are not dealing with BOM's at all -- or should > not be. The BOM's are not for string handling, and were never intended > to be. String concatenation operations, for example, should not be > examining and trimming off initial BOM's on Unicode strings, and so > on. If they are, something is terribly wrong in the implementation. > Here is an example of a complete, conformant implementation of > a Unicode string concatenation: > > unistring unistrcat( unistring s1, const unistring s2 ) > { > unistring t1 = s1; > unistring t2 = s2; > > /* advance to the end of s1 */ > while ( *t1 != UNINULL ) > { > t1++; > } > while ( *t2 != UNINULL ) > { > *t1++ = *t2++; > } > *t1 = UNINULL; > return ( s1 ); > } > > If "unistring" is type-bound to unsigned short*, then this works > for UTF-16. If "unistring" is type-bound to unsigned {32-bit} long*, > then this works for UTF-32. Note, no provisions for BOM's. There > should *not* be such provisions. > > Where you can run into BOM's, on the other hand, is when you are > serializing UTF-16 Unicode data into or out of byte streams intended > for interchange -- e.g. as plain text datafiles loose on the > Internet somewhere, or "loose" inside any mixed byte polarity > network sharing files. It is in those instances that you need to > make a decision as to which of the encoding schemes you will > declare and use. And if your encoding scheme is UTF-16, then it is > advisable to prepend a serialized UTF-16 byte stream with the BOM on > export, and the interpret any prepended BOM on import. > > But think of this as a minimal weight file formatting issue. You > get a file stream with a two-byte "header" that you interpret to > figure out the byte polarity of the data, and then you treat the > rest of the file stream as the "data", byte-swapping or not, and > feeding the results to string-based API's that can either treat > the "data" as one big long string, or, more usually, parse up the > contents according to whatever they are supposed to be doing. > > Further comments below. > > > > -----Original Message----- > > From: Rutt, T E (Tom) [mailto:terutt@lucent.com] > > Sent: Tuesday, May 16, 2000 12:05 AM > > To: 'arnold.winkler@unisys.com' > > Subject: Is our interpretation of UTF-16 encoding correct? > > > > > > Arnold, > > > > I hope you can take some time to help the OMG Interop RTF resolve an > urgent > > issue. > > > > With regard to encoding of UTF-16, the following proposal was forwarded > by > > our Xerox > > member. We are referring to the OSF codeset designation UTF-16 as our > > basis, but the > > ISO standard is what people think is "sanctimonious". > > > > We cannot use the IANA BE, LE variants, because we are (probably should > > change) > > using OSF as our codeset registration authority. > > I cannot comment on the constraints you may be under regarding > what you can and cannot normatively reference in your specifications. > > However, my general advice is to make sure that you "get it right" > and don't get stuck in some specification conundrum because of > what you think you have to refer to. > > > > > Here is what we are currently voting on: > > > > ------------ > > UTF-16 can be big endian or little endian but defaults to big endian.. > The > > wording > > of the ISO spec indicates (though it does not clearly say -- well, we > know > > how > > that goes) that by placing a BOM (byte order marker) at the front of the > > string, > > you can send it either way. So, our official interpretation of a UTF-16 > > string should be: > > Replace the "string" here with "serialized byte stream", and you get > closer > to the intent. > > > > > if the first two bytes are FE FF, it's big-endian; > > if FF FE, it's little-endian; > > if neither, it's big-endian. > > Otherwise, this is correct. > > Once you are dealing with *string*'s per se, however, you should not be > dealing with BOM's. > > > > > ---------------- > > > > The problem is, one member has asked a good question, > > > > "Is the BOM (if present) required to be removed from the transmitted > > encoding before passing > > the wstring up to the User through their normal Programming Language API > for > > WSTRING?" > > It should be removed from the *serialized byte stream* before the byte > stream > is reinterpreted as a properly byte-polarized UTF-16 wide *string* that > a string-oriented API handles. > > Once again, try to distinguish the file stream side of the issue from > the string side of the issue. The BOM is a *signature*, not to be > interpreted > as part of the content. > > And when you are using UTF-16 as an encoding *form* for your strings, > the BOM should *not* occur at the front of *any* string. That is for when > you are packing up Unicode UTF-16 textual data into a byte stream for > interchange. > > > > > The concern is that for application comparison of strings and such, > > Is the BOM a "white space" or is it always ignored by User application > > software? > > U+FEFF, when it appears inside strings (anyplace, not just at the > beginning of strings), is interpreted as a ZERO WIDTH NO-BREAK SPACE. That > is a legitimate character, and is not functioning as a byte-order-mark > (BOM) > in those instances. Ordinarily, a ZWNBSP would be treated as white space, > since it is a particular kind of "space", but it is not always ignored > by user application software. In particular, the whole point of using > a ZWNBSP in text is to tell a line-breaker not to place a line break at > a particular place in text (without having the visual gap that the regular > NBSP has). > > If you are doing a binary comparison of strings, then the presence or > absence of a U+FEFF character in a string obviously is going to make > a difference. If you are allocating memory for storage, the presence > or absence of a U+FEFF character obviously cannot be ignored. If you > are doing culturally significant sorting with weight tables, then > a U+FEFF character would typically be ignored, just as a ZERO WIDTH SPACE > (U+200B) would typically be ignored for such sorting. > > But the important thing is that ZWNBSP character in text should not be > there as a result of misinterpretation of BOM signature bytes on a > data stream that were not removed when a serialized UTF-16 byte stream > was turned into UTF-16 string(s) for in memory processing. > > > > > If it it significant for comparisons, then we should clarify that it is > > removed before passing > > the string to the application from the ORB decoder. > > It should *not* be there on strings. > > It *should* be removed from the beginning of serialized UTF-16 byte > streams that are being turned into strings. > > > > > I await your helpful response? > > I hope this was helpful. > > --Ken Whistler, Technical Director, Unicode, Inc. > > > > > > > -- > > Tom Rutt > > Lucent Technologies - Bell Labs > > Rm 4L-336 Tel: +1(732)949-7862 > > 101 Crawford Corner Rd Fax: +1(732)949-1196 > > Holmdel NJ, 07733 USA email: terutt@lucent.com > > > Sender: jon@corvette.floorboard.com Message-ID: <39238DE6.85FD7651@floorboard.com> Date: Wed, 17 May 2000 23:29:58 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: "Rutt, T E (Tom)" CC: "'interop@omg.org'" Subject: Re: FW: FW: Is our interpretation of UTF-16 encoding correct? References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: nRR!!oX1e9-MLe9][?!! "Rutt, T E (Tom)" wrote: > > I forward an answer to a question regarding UTF-16 encoding I asked > Arnold Winkler, an internationalization expert from Unisys. > > Based on the response below, Jon's interpretation is correct and I do > believe > we can clarify the text of our response to indicate that the orb adds and/or > strips > off the BOMS. Interesting. My reading of Arnold's response suggests that we could also choose to specify an alternative method, based on the fact that we have a byte order bit available in the GIOP message header and in the encapsulation header: Unicode strings are represented on the wire in UTF-16BE if the byte order bit is zero, and UTF-16LE if the byte order bit is one. This is the common sense encoding scheme that a lot of us wanted from the first. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Paul Kyzivat To: "'interop@omg.org'" Subject: RE: FW: FW: Is our interpretation of UTF-16 encoding correct? Date: Thu, 18 May 2000 08:45:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ji>e9'ONe9G" -----Original Message----- > From: Jonathan Biggar [mailto:jon@floorboard.com] > Sent: Thursday, May 18, 2000 2:30 AM > To: Rutt, T E (Tom) > Cc: 'interop@omg.org' > Subject: Re: FW: FW: Is our interpretation of UTF-16 encoding correct? > > > "Rutt, T E (Tom)" wrote: > > > > I forward an answer to a question regarding UTF-16 encoding I asked > > Arnold Winkler, an internationalization expert from Unisys. > > > > Based on the response below, Jon's interpretation is > correct and I do > > believe > > we can clarify the text of our response to indicate that > the orb adds and/or > > strips > > off the BOMS. > > Interesting. My reading of Arnold's response suggests that we could > also choose to specify an alternative method, based on the > fact that we > have a byte order bit available in the GIOP message header and in the > encapsulation header: > > Unicode strings are represented on the wire in UTF-16BE if the byte > order bit is zero, and UTF-16LE if the byte order bit is one. > > This is the common sense encoding scheme that a lot of us wanted from > the first. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > From: "Rutt, T E (Tom)" To: "'interop@omg.org'" , "'Paul Kyzivat'" Subject: RE: FW: FW: Is our interpretation of UTF-16 encoding correct? Date: Thu, 18 May 2000 09:25:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: bKj!!Q'$e9'gWd9F+,!! Paul An array of wchar has the problems you stated, however who would ever do that rather than wstring, which has only on BOM at the beginning of the entire string. wchar itself is rather "useless" since on the api one byte does not represent an entire character. I am confused, if you want to be efficient, then send your array of wchar as big endian rather than use the BOMS. I do not see a problem here! -- Tom Rutt Lucent Technologies - Bell Labs Rm 4L-336 Tel: +1(732)949-7862 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA email: terutt@lucent.com > ---------- > From: Paul Kyzivat[SMTP:paulk@roguewave.com] > Sent: Thursday, May 18, 2000 8:45 AM > To: 'interop@omg.org' > Subject: RE: FW: FW: Is our interpretation of UTF-16 encoding > correct? > > I agree with Jon. In spite of Winkler's claim that the BOM is a light > weight > way to specify byte order, it isn't the case for corba. > > Consider the following idl: > > typedef wchar Tag[64]; > > and then consider what has to go on the wire to represent an instance of > Tag. > Each of the 64 wchar values is encoded as a 1 byte count containing the > value 4, followed by two bytes for the BOM, followed by two bytes for the > character itself. So it takes 320 bytes to carry 128 bytes of data. > > Paul > > > -----Original Message----- > > From: Jonathan Biggar [mailto:jon@floorboard.com] > > Sent: Thursday, May 18, 2000 2:30 AM > > To: Rutt, T E (Tom) > > Cc: 'interop@omg.org' > > Subject: Re: FW: FW: Is our interpretation of UTF-16 encoding correct? > > > > > > "Rutt, T E (Tom)" wrote: > > > > > > I forward an answer to a question regarding UTF-16 encoding I asked > > > Arnold Winkler, an internationalization expert from Unisys. > > > > > > Based on the response below, Jon's interpretation is > > correct and I do > > > believe > > > we can clarify the text of our response to indicate that > > the orb adds and/or > > > strips > > > off the BOMS. > > > > Interesting. My reading of Arnold's response suggests that we could > > also choose to specify an alternative method, based on the > > fact that we > > have a byte order bit available in the GIOP message header and in the > > encapsulation header: > > > > Unicode strings are represented on the wire in UTF-16BE if the byte > > order bit is zero, and UTF-16LE if the byte order bit is one. > > > > This is the common sense encoding scheme that a lot of us wanted from > > the first. > > > > -- > > Jon Biggar > > Floorboard Software > > jon@floorboard.com > > jon@biggar.org > > > From: "Rutt, T E (Tom)" To: "Rutt, T E (Tom)" , "'Jonathan Biggar'" Cc: "'interop@omg.org'" Subject: RE: FW: FW: Is our interpretation of UTF-16 encoding correct? Date: Thu, 18 May 2000 09:30:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: E*ed9NdJ!!\A5e9O9`!! We already talked about this last RTF. It turns out that we point to the OSF codeset registry not IANA. IANA has utf-16 BE and LE variants To do what Jon is asking (which makes sense to me) would require changing the spec to use IANA as the registration authority rather than OSF. By the way, putting a BOM at the beginning of the entire string does not seem a problem I cannot see the reason to use array of wchar rather than string ( to address Paul K's concern) and even If it was used, it could be send big- endian. Anyway, changing registration pointer to IANA would be required to use the LE and BE variants. -- Tom Rutt Lucent Technologies - Bell Labs Rm 4L-336 Tel: +1(732)949-7862 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA email: terutt@lucent.com > ---------- > From: Jonathan Biggar[SMTP:jon@floorboard.com] > Sent: Thursday, May 18, 2000 2:29 AM > To: Rutt, T E (Tom) > Cc: 'interop@omg.org' > Subject: Re: FW: FW: Is our interpretation of UTF-16 encoding > correct? > > "Rutt, T E (Tom)" wrote: > > > > I forward an answer to a question regarding UTF-16 encoding I asked > > Arnold Winkler, an internationalization expert from Unisys. > > > > Based on the response below, Jon's interpretation is correct and I do > > believe > > we can clarify the text of our response to indicate that the orb adds > and/or > > strips > > off the BOMS. > > Interesting. My reading of Arnold's response suggests that we could > also choose to specify an alternative method, based on the fact that we > have a byte order bit available in the GIOP message header and in the > encapsulation header: > > Unicode strings are represented on the wire in UTF-16BE if the byte > order bit is zero, and UTF-16LE if the byte order bit is one. > > This is the common sense encoding scheme that a lot of us wanted from > the first. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > From: Paul Kyzivat To: "'interop@omg.org'" Subject: RE: FW: FW: Is our interpretation of UTF-16 encoding correct? Date: Thu, 18 May 2000 11:06:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 1JIe9mU7!!VD:!!(BM!! > -----Original Message----- > From: Rutt, T E (Tom) [mailto:terutt@lucent.com] > An array of wchar has the problems you stated, however who would > ever do that rather than wstring, which has only on BOM at the > beginning of the entire string. This is a modeling issue. A string is appropriate if the number of characters is permitted to vary. An array is appropriate if the number of characters is not permitted to vary. If one uses a string but doesn't permit the length to vary, then it is necessary to introduce added semantic rules that could be enforced as syntactic rules. > wchar itself is rather "useless" since on the api one byte does not > represent an entire character. The issue of one byte not representing a character is an issue for the mapping of char, not wchar. We were screwed w/r/t the mapping of char as soon as we permitted codesets for char that cannot be represented in 8 bits. This is less of a problem for wchar, at least in the giop 1.2 form, because there is provision to get as many bits onto the wire as required by the codeset. However, it is still a problem to the extent that wchar presumably has a fixed width in-memory representation regardless of what the negotiated codeset is. As long as we permit negotiation of a codeset that may require more bits than the size of a wchar then we have a problem. It seems to me that we have two choices: 1) we can eliminate wchar (and probably char as well) as an idl datatype 2) we can raise a marshalling exception when we get cases that don't work. I believe Bill J has advocated (1). If we were starting over I might choose that too. But given history, I don't think that is a viable choice. While (2) seems likely to lead to arbitrary failures, in practice it is probably quite workable. Most common usage will not run into trouble, and the cases that do cause trouble will teach people to limit use of wchar to cases that can work. It appears that the exception can only be detected and raised on the receiving end, when a value is received that is too big for the local representation of wchar. > I am confused, if you want to be efficient, then send your > array of wchar as big endian rather than use the BOMS. Yes, that was pretty dumb of me - save 40& of the space by always sending big endian. Unfortunately, with the giop 1.2 encoding an array of wchars still takes 50% more space than a wstring of the same characters. (When using UTF-16.) Paul From: "Rutt, T E (Tom)" To: "'Jonathan Biggar'" Cc: "'interop@omg.org'" Subject: RE: FW: FW: Is our interpretation of UTF-16 encoding correct? Date: Thu, 18 May 2000 12:36:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: ---------- > From: Rutt, T E (Tom) > Sent: Thursday, May 18, 2000 9:30 AM > To: Rutt, T E (Tom); 'Jonathan Biggar' > Cc: 'interop@omg.org' > Subject: RE: FW: FW: Is our interpretation of UTF-16 encoding > correct? > > We already talked about this last RTF. > > It turns out that we point to the OSF codeset registry not IANA. > > IANA has utf-16 BE and LE variants > > To do what Jon is asking (which makes sense to me) would require changing > the spec to use IANA as the registration authority rather than OSF. > > By the way, putting a BOM at the beginning of the entire string does not > seem > a problem > > I cannot see the reason to use array of wchar rather than string ( to > address > Paul K's concern) and even If it was used, it could be send big- endian. > > > Anyway, changing registration pointer to IANA would be required to use the > LE and BE > variants. > > > -- > Tom Rutt > Lucent Technologies - Bell Labs > Rm 4L-336 Tel: +1(732)949-7862 > 101 Crawford Corner Rd Fax: +1(732)949-1196 > Holmdel NJ, 07733 USA email: terutt@lucent.com > > > > > ---------- > > From: Jonathan Biggar[SMTP:jon@floorboard.com] > > Sent: Thursday, May 18, 2000 2:29 AM > > To: Rutt, T E (Tom) > > Cc: 'interop@omg.org' > > Subject: Re: FW: FW: Is our interpretation of UTF-16 encoding > > correct? > > > > "Rutt, T E (Tom)" wrote: > > > > > > I forward an answer to a question regarding UTF-16 encoding I asked > > > Arnold Winkler, an internationalization expert from Unisys. > > > > > > Based on the response below, Jon's interpretation is correct and I do > > > believe > > > we can clarify the text of our response to indicate that the orb adds > > and/or > > > strips > > > off the BOMS. > > > > Interesting. My reading of Arnold's response suggests that we could > > also choose to specify an alternative method, based on the fact that we > > have a byte order bit available in the GIOP message header and in the > > encapsulation header: > > > > Unicode strings are represented on the wire in UTF-16BE if the byte > > order bit is zero, and UTF-16LE if the byte order bit is one. > > > > This is the common sense encoding scheme that a lot of us wanted from > > the first. > > > > -- > > Jon Biggar > > Floorboard Software > > jon@floorboard.com > > jon@biggar.org > > > Date: Thu, 18 May 2000 21:38:05 +0100 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: "Rutt, T E (Tom)" , "'interop@omg.org'" Subject: Re: FW: FW: Is our interpretation of UTF-16 encoding correct? References: <39238DE6.85FD7651@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ]oQ!!_B%"!S(/e9P,F!! Jon, The problem with this is that UTF-16 strings do not work this way when they show up elsewhere. For example, in a little-endian message or encapsulation, a UTF-16 string without a byte order marker would be treated as big-endian, whereas with your proposal it would be little-endian in the ExceptionDetailMessage service context but big-endian elsewhere. This context sensitivity would create added complexity in the unmarshalling code. I see no reason to go to a UTF16BE/LE encoding for this service context (which uses wstring, not array of wchar) unless we do this across the board whenever UTF-16 is used. And the latter would be a backward-incompatible change in the example that I gave above. Simon Jonathan Biggar wrote: > > "Rutt, T E (Tom)" wrote: > > > > I forward an answer to a question regarding UTF-16 encoding I asked > > Arnold Winkler, an internationalization expert from Unisys. > > > > Based on the response below, Jon's interpretation is correct and I do > > believe > > we can clarify the text of our response to indicate that the orb adds and/or > > strips > > off the BOMS. > > Interesting. My reading of Arnold's response suggests that we could > also choose to specify an alternative method, based on the fact that we > have a byte order bit available in the GIOP message header and in the > encapsulation header: > > Unicode strings are represented on the wire in UTF-16BE if the byte > order bit is zero, and UTF-16LE if the byte order bit is one. > > This is the common sense encoding scheme that a lot of us wanted from > the first. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Sender: jbiggar@corvette.floorboard.com Message-ID: <392461F3.2FA987B2@floorboard.com> Date: Thu, 18 May 2000 14:34:43 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: "Rutt, T E (Tom)" , "'interop@omg.org'" Subject: Re: FW: FW: Is our interpretation of UTF-16 encoding correct? References: <39238DE6.85FD7651@floorboard.com> <392454AD.4DE07C10@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: e,"e9/kC!!##~e9l$Oe9 Simon Nash wrote: > > Jon, > The problem with this is that UTF-16 strings do not work this way when they > show up elsewhere. For example, in a little-endian message or encapsulation, > a UTF-16 string without a byte order marker would be treated as big-endian, > whereas with your proposal it would be little-endian in the > ExceptionDetailMessage service context but big-endian elsewhere. This context > sensitivity would create added complexity in the unmarshalling code. I see no > reason to go to a UTF16BE/LE encoding for this service context (which uses > wstring, not array of wchar) unless we do this across the board whenever > UTF-16 is used. And the latter would be a backward-incompatible change in the > example that I gave above. I suppose I am suggesting that we make this change globally. If we have a different codeset id for it, then it can coexist with the older less efficient encoding. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Paul Kyzivat To: "'interop@omg.org'" Subject: RE: FW: FW: Is our interpretation of UTF-16 encoding correct? Date: Fri, 19 May 2000 08:28:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: m`[!!&++e9UIUd9! From: Jonathan Biggar [mailto:jon@floorboard.com] > I suppose I am suggesting that we make this change globally. > If we have > a different codeset id for it, then it can coexist with the older > less > efficient encoding. Yes. I believe we should have a default codeset of wchar/wstring that is UTF-16BE/LE following the byte order of the message/encapsulation. If this takes some new registration, so be it. Other codesets should still be possible via negotiation, or in the case of encapsulations as part of their specification. Paul From: "Rutt, T E (Tom)" To: "'interop@omg.org'" Subject: Lucent vote on interop rtf vote 5 Date: Fri, 19 May 2000 11:56:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: JJM!!$+G!!$d(!!&oUd9 Lucent votes yes on all issues, with the clarification that the BOM is added/removed by the encoder before passing thru the language binding, and that the service context is made avaialable to interceptors. The issue 3405b is on encoding for UTF-16, which is now clear. We have no issue here. Now on, the previously voted 3405a, we agreed on utf-16. This is important, because it allows both big and little endian to be passed. What if the orb gets the exception text from another endian creature, it might need to pass it in a different endianness than its own native one. Thus i think that the LE/BE availability is yet another new issue, which we can resolve and make available for negotiation or for future encapsulation defs. -- Tom Rutt Lucent Technologies - Bell Labs Rm 4L-336 Tel: +1(732)949-7862 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA email: terutt@lucent.com From: Jeffrey Mischkinsky Message-Id: <200005191653.JAA20995@wheel.dcn.davis.ca.us> Subject: Re: FW: FW: Is our interpretation of UTF-16 encoding correct? To: paulk@roguewave.com (Paul Kyzivat) Date: Fri, 19 May 2000 09:53:34 -0700 (PDT) Cc: interop@omg.org ('interop@omg.org') In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BEA4@bos1.noblenet.com> from "Paul Kyzivat" at May 19, 2000 08:28:31 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: [URd9~!7e9Sf?e9,I,!! 'Paul Kyzivat' writes: > > > From: Jonathan Biggar [mailto:jon@floorboard.com] > > > I suppose I am suggesting that we make this change globally. > > If we have > > a different codeset id for it, then it can coexist with the older less > > efficient encoding. > > Yes. I believe we should have a default codeset of wchar/wstring that is > UTF-16BE/LE following the byte order of the message/encapsulation. If this > takes some new registration, so be it. Other codesets should still be > possible via negotiation, or in the case of encapsulations as part of their > specification. Hi, I've been lurking in this discussion, but I figure now's the time to chime in. This seems like an appealing approach to me, but I've been down these "appealing garden paths" before :-), so I figure there must be some downsides: backwards compatibilitiy?, multiple GIOP levels on the same connection, ... I'd like some assurances that changing the default is not going to have some unintended consequences that will cause us to go through procedural gymnastics to fix. once burned, twice cautious!! cheers, jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 From: Paul Kyzivat To: interop@omg.org Subject: RE: FW: FW: Is our interpretation of UTF-16 encoding correct? Date: Fri, 19 May 2000 14:14:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: BW4e9(ZC!!(*i!!AKH!! > From: Jeffrey Mischkinsky [mailto:jmischki@wheel.dcn.davis.ca.us] > Hi, > I've been lurking in this discussion, but I figure now's > the time to chime in. > > This seems like an appealing approach to me, but I've been > down these > "appealing garden paths" before :-), so I figure there must be > some > downsides: backwards compatibilitiy?, multiple GIOP levels > on the same > connection, ... > I'd like some assurances that changing the default is not > going to have some > unintended consequences that will cause us to go through > procedural > gymnastics to fix. once burned, twice cautious!! Jeff, Caution is a good thing. In this case I don't see a problem. Until now there has been no default codeset for wchar/wstring. There is still danger in chosing the wrong default of course. But I feel we are suffering for not having a default. Paul From: "Rutt, T E (Tom)" To: "Rutt, T E (Tom)" , "'Bob Kukura'" Cc: "'interop@omg.org'" Subject: RE: Vote 5 for Interop RTF Date: Fri, 19 May 2000 13:05:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: 2Ucd9in[d9IM8e9hL;e9 > ---------- > From: Bob Kukura[SMTP:kukura@iona.com] > Sent: Thursday, May 18, 2000 9:56 PM > To: Rutt, T E (Tom) > Cc: 'interop@omg.org' > Subject: Re: Vote 5 for Interop RTF > > IONA votes as follows: > > 1962 - Yes > > 3405b - No - There still seems to be ongoing debate about using the > stream's byte order, and using a BOM in the wchar encoding seems less > than optimal. I do think a resolution on this as soon as possible is > critical, so I may change my vote tomorrow if I am convinced that use of > the BOM (or big-endian) for both wchar and wstring is tollerable, or is > clearly already required for UTF-16. I just realized that the due date for three week rule for oslo is this monday. Thus the results of this vote are it for this interim report. I believe that UTF-16 is what we have available at this time, and it is well defined in the industry just as Bill J. clarified it for us. Thus the LE/BE variants (which by the way lock you in since a bom is disallowed) used in codeset negotiation could be added in the next go around giving us time to register them for use in negotiation. Thus if the 3405B fails we will have UTF-16 left as it is today, with the interpretation of Bill in the Discussion of resolved issue 3405A. > -- > Tom Rutt > Lucent Technologies - Bell Labs > Rm 4L-336 Tel: +1(732)949-7862 > 101 Crawford Corner Rd Fax: +1(732)949-1196 > Holmdel NJ, 07733 USA email: terutt@lucent.com > Date: Fri, 19 May 2000 22:05:06 +0100 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: "Rutt, T E (Tom)" , "'interop@omg.org'" Subject: Re: FW: FW: Is our interpretation of UTF-16 encoding correct? References: <39238DE6.85FD7651@floorboard.com> <392454AD.4DE07C10@hursley.ibm.com> <392461F3.2FA987B2@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: :Ch!!j!P!!B$m!!IJ%e9 Jon, Jonathan Biggar wrote: > > Simon Nash wrote: > > > > Jon, > > The problem with this is that UTF-16 strings do not work this way when they > > show up elsewhere. For example, in a little-endian message or encapsulation, > > a UTF-16 string without a byte order marker would be treated as big-endian, > > whereas with your proposal it would be little-endian in the > > ExceptionDetailMessage service context but big-endian elsewhere. This context > > sensitivity would create added complexity in the unmarshalling code. I see no > > reason to go to a UTF16BE/LE encoding for this service context (which uses > > wstring, not array of wchar) unless we do this across the board whenever > > UTF-16 is used. And the latter would be a backward-incompatible change in the > > example that I gave above. > > I suppose I am suggesting that we make this change globally. If we have > a different codeset id for it, then it can coexist with the older less > efficient encoding. > This would require registration of a new codeset id with OSF. We should also look at existing uses of UTF-16 (e.g., as the fallback codeset for TCS-W) and decide if we want to replace this by the new codeset or allow both as alternatives. This is a bigger issue than just the new service context that is being added by issue 3405. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb To: Paul Kyzivat cc: "Interop RTF (E-mail)" Subject: Re: Vote 5 for Interop RTF In-Reply-To: Your message of "Wed, 17 May 2000 05:15:18 PDT." <9B164B713EE9D211B6DC0090273CEEA926BE98@bos1.noblenet.com> From: Bill Janssen Message-Id: <00May30.154927pdt."3438"@watson.parc.xerox.com> Date: Tue, 30 May 2000 15:49:28 PDT Content-Type: text X-UIDL: 14H!![VQd9gkDe9A0,!! > Issue 3405b: CDR Encoding for UTF-16 for wchar and wstring > > NO - I support the comment made by (I think) Bob Kukura, > that we need to get a wide encoding in place that > doesn't require the prefix, that follows the byte order of > the containing message, and that works for wchar as well > as wstring. I think we'll need to define a new format, then, and register it with the OSF codeset registry. Paul, perhaps you and Bob would be interested in forming a subcommittee to propose that new format? Bill To: Jonathan Biggar cc: Simon Nash , Michi Henning , "Rutt, T E (Tom)" , Interoperability RTF Subject: Re: Announcement of Interop 2kPlus RTF Vote 5 In-Reply-To: Your message of "Tue, 16 May 2000 13:18:49 PDT." <3921AC91.40A4D784@floorboard.com> From: Bill Janssen Message-Id: <00May30.154631pdt."3438"@watson.parc.xerox.com> Date: Tue, 30 May 2000 15:46:38 PDT Content-Type: text X-UIDL: @Yad9HFA!!p=Qe9MO;e9 (I'm back!) > Simon Nash wrote: > > > > Michi, > > I don't see anything in my email concerning a friendly amendment from Jon. > > I think Michi means my request for a clarification on 3405b that the > byte order marker be stripped from the UTF-16 string by the ORB before > it is delivered to application code. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Hmmm. I wonder if the byte order mark should be either stripped or added by the ORB -- it complicates marshalling a bit, and the intent of the UTF-16 spec seems to be that the particular BOM used is ignored by the application. Bill To: "Rutt, T E (Tom)" cc: "'interop@omg.org'" Subject: Re: FW: FW: Is our interpretation of UTF-16 encoding correct? In-Reply-To: Your message of "Wed, 17 May 2000 21:02:17 PDT." From: Bill Janssen Message-Id: <00May30.155402pdt."3438"@watson.parc.xerox.com> Date: Tue, 30 May 2000 15:54:08 PDT Content-Type: text X-UIDL: N'e!!Gi>e9n4gd9J8[d9 OK, that looks good enough for me. So the ORB *should* add and remove the BOM during marshalling. Bill To: Paul Kyzivat cc: "'interop@omg.org'" Subject: Re: FW: FW: Is our interpretation of UTF-16 encoding correct? In-Reply-To: Your message of "Thu, 18 May 2000 05:44:00 PDT." <9B164B713EE9D211B6DC0090273CEEA926BE9E@bos1.noblenet.com> From: Bill Janssen Message-Id: <00May30.155613pdt."3438"@watson.parc.xerox.com> Date: Tue, 30 May 2000 15:56:18 PDT Content-Type: text X-UIDL: \: I agree with Jon. In spite of Winkler's claim that the BOM is a light weight > way to specify byte order, it isn't the case for corba. > > Consider the following idl: > > typedef wchar Tag[64]; > Ah, but wchar is a bogon. That type (and the char type) don't really make sense in an API definition language, for all of these reasons. Bill To: Jonathan Biggar cc: "Rutt, T E (Tom)" , "'interop@omg.org'" Subject: Re: FW: FW: Is our interpretation of UTF-16 encoding correct? In-Reply-To: Your message of "Wed, 17 May 2000 23:38:14 PDT." <39238DE6.85FD7651@floorboard.com> From: Bill Janssen Message-Id: <00May30.155517pdt."3438"@watson.parc.xerox.com> Date: Tue, 30 May 2000 15:55:19 PDT Content-Type: text X-UIDL: &bEe9o5*e9Y@Je91g0e9 > Unicode strings are represented on the wire in UTF-16BE if the byte > order bit is zero, and UTF-16LE if the byte order bit is one. > > This is the common sense encoding scheme that a lot of us wanted > from > the first. I think we could have that, if we wrote it down somewhere and registered it with the OSF. But I'd rather stick with the same thing that a lot of other people are using. Bill To: "Rutt, T E (Tom)" cc: "'Jonathan Biggar'" , "'interop@omg.org'" Subject: Re: FW: FW: Is our interpretation of UTF-16 encoding correct? In-Reply-To: Your message of "Thu, 18 May 2000 09:39:12 PDT." From: Bill Janssen Message-Id: <00May30.155858pdt."3438"@watson.parc.xerox.com> Date: Tue, 30 May 2000 15:58:59 PDT Content-Type: text X-UIDL: g5Ae9ZnGe9M;k!!/p8!! > I just thought, If we really want the spec to read "utf-16BE" for big endian > bit set in > encaps, and LE if little endian set, then we should do it, and get the > proper registration > done in OSF or change the reg authority to IANA and get up to the rest of > the Industry. Note that just changing the registry to IANA wouldn't do it. You need to define a new variant of UTF-16 where the byte order is determined independently of the "serialized byte stream" used to hold the string. None of the variants registered with IANA do that. UCS-4 might be the closest for that. Bill To: interop@omg.org Subject: defining a new variant of UTF-16 Sender: Bill Janssen From: Bill Janssen Mime-Version: 1.0 Message-Id: <00May30.160242pdt."3438"@watson.parc.xerox.com> Date: Tue, 30 May 2000 16:02:48 PDT Content-Type: text/plain; charset=US-ASCII X-UIDL: 9TA!!bBH!!X2Kd9fbh!! I'd suggest that if we do do this, we register it both with the OSF registry and with IANA. IANA seems to be more "live"; we should definitely consider switching to it in a future rev. Bill From: Paul Kyzivat To: "'interop@omg.org'" Subject: RE: FW: FW: Is our interpretation of UTF-16 encoding correct? Date: Wed, 31 May 2000 09:16:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: UE6e9e8(!!~:M!!:j0e9 I know you have said this in the past, and I see there are pragmatic reasons for it. But there are also pragmatic reasons for having char and wchar in idl. Without those, we have no way to specify a "string" of a specific fixed length (as opposed to one that can vary up to a fixed maximum). We normally use array for that. In any case, does it really make sense to talk about a string without being able to talk about the elements of the string? This gross encoding of a wchar wouldn't be so bad if we had a more optimum way to encode an array of wchar. Paul > -----Original Message----- > From: Bill Janssen [mailto:janssen@parc.xerox.com] > Sent: Tuesday, May 30, 2000 6:56 PM > To: Paul Kyzivat > Cc: 'interop@omg.org' > Subject: Re: FW: FW: Is our interpretation of UTF-16 encoding > correct? > > > > I agree with Jon. In spite of Winkler's claim that the BOM > is a light weight > > way to specify byte order, it isn't the case for corba. > > > > Consider the following idl: > > > > typedef wchar Tag[64]; > > > > Ah, but wchar is a bogon. That type (and the char type) don't really > make sense in an API definition language, for all of these reasons. > > Bill > To: Paul Kyzivat cc: "'interop@omg.org'" Subject: Re: FW: FW: Is our interpretation of UTF-16 encoding correct? In-Reply-To: Your message of "Wed, 31 May 2000 06:14:26 PDT." <9B164B713EE9D211B6DC0090273CEEA926BEDD@bos1.noblenet.com> From: Bill Janssen Message-Id: <00May31.131455pdt."3438"@watson.parc.xerox.com> Date: Wed, 31 May 2000 13:14:57 PDT Content-Type: text X-UIDL: @*N!!f7 In any case, does it really make sense to talk about a string without being > able to talk about the elements of the string? Actually, I think it does. It makes more sense from a complexity-management point of view to think about the elements of the string as being substrings, not characters. As for fixed length strings, I'm (a) not sure that they really exist, and (b) should properly be handled by a parameter on the string definition constructor which specifies a minimum length. Bill