Issue 2929: Removing type specific exception holder" and detail changes (messaging-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: This message includes a short summary and a list of changes in the spec. document. It has been pointed out that type specific exception holder offers little use and introduces many problems and complicities. Some of these problems have been discussed by Matthew Mihic in issue 2628 and his recent message on DSI callbacks. To preserv type specific exception holder and fix its problems would need more changes beyond the scope of messaging specification itself and would make things more complicate. Therefore, we suggest to simply remove it. Resolution: see below Revised Text: Changes tracked against formal/01-09-59 (the latest Messaging Chapter) are: ---------------------------------------------------- 1. On page 22-14, the second bullet, : A type-specific ExceptionHolder valuetype is generated for delivery of exception replies to applications that use the Callback model. This generated ExceptionHolder has operations that raise the system and user exceptions that were returned from the target. The implementation of this ExceptionHolder is provided by the messaging aware ORB. The language specific generated code corresponds to a valuetype as if it were defined in IDL as specified in Section 22.7.2 "Type-Specific ExceptionHolder Mapping" on page 22-21 should be removed. 2. On page 22-20 (beginning of section 22.7) the original text of: ... Therefore, exception replies are propagated to the ReplyHandler in the form of a type specific ExceptionHolder valuetype instance that contains the marshaled exception as its state and has generated operations for raiseing the encapsulated exception in the manner dictated by the programming language's mapping from IDL. change to: ... Therefore, exception replies are propagated to the ReplyHandler in the form of a Messaging::ExceptionHolder valuetype instance that contains the marshaled exception as its state and has raise_exception() and raise_exception_with_list() methods for raising the encapsulated exception. 3. On page 22-20, the entire section 22.7.1 changes to: 22.7.1 Messaging::ExceptionHolder valuetype The Messaging::ExceptionHolder valuetype encapsulates the exception data and enough information to turn that data back into a raised exception. // IDL module Messaging { // ... all the other stuff native UserExceptionBase; valuetype ExceptionHolder { void raise_exception() raises (UserExceptionBase); void raise_exception_with_list( in CORBA::ExceptionList exc_list, raises (UserExceptionBase); private boolean is_system_exception; private boolean byte_order; private sequence<octet> marshaled_exception; }; }; * raise_exception(). This method is used by applications to raise exception from the encapsulated marshaled_exception member. * raise_exception_with_list(). If is_system_exception is true, this function is same as raise_exception(). Otherwise, this method raises an exception from the marshaled_exception using an application provided user exception list. It is useful and should only be used when the given exception holder is not from a skeleton reply handler's xxx_excep() method. For instance, it is from a DSI reply handler servant or from another ORB runtime. In these cases, the exception holder may not have an internal user exception list available. * UserExceptionBase. Language mapping of this native type should allow any user exception to be raised from this method. For instance, it is mapped to CORBA::UserException. in C++ and to org.omg.CORBA.UserException in java. As usual, system exceptions do not need to be in the raises clause for raising them from this method. 4. On page 22-21, remove entire sections 22.7.2 and 22.7.3 5. On page 22-24, the section 22.8.2: changes: void <operName>_excep( in AMI_<ifaceName>ExceptionHolder excep_holder); .... void get_<attrName>_excep( in AMI_<ifaceName>ExceptionHolder excep_holder); .... void set_<attrName>_excep( in AMI_<ifaceName>ExceptionHolder excep_holder); to: void <operName>_excep( in Messaging::ExceptionHolder excep_holder); .... void get_<attrName>_excep( in Messaging::ExceptionHolder excep_holder); .... void set_<attrName>_excep( in Messaging::ExceptionHolder excep_holder); 6. On page 22-24/22-25, the section 22.8.3: Change all of (there are 7 instances of them): AMI_StockManagerExceptionHolder in the example IDL into: Messaging::ExceptionHolder 8. On page 22-32. remove entire section 22.11.3.1 9. On page 22-33, the section 22.11.3.2, Change all of (there are 7 instances of them): AMI_StockManagerExceptionHolder_ptr in the C++ mapping example into: Messaging::ExceptionHolder_ptr 10. On page 22-34/22-35/22-36, the section 22.11.3.3, Change all of (there are 14 instances of them): AMI_StockManagerExceptionHolder_ptr in the C++ mapping example into: Messaging::ExceptionHolder_ptr And also change all of (there are 7 of them): excep_holder->raise_xxxx(); (where xxx is different operation names) into: excep_holder->raise_exception(); 11. In page 22-47, section 22.14, Change the ReplyDestination struct in the Messaging IDL module from struct ReplyDestination { ReplyDisposition handler_type; Messaging::ReplyHandler handler; sequence<string> typed_exception_holder_repids; }; into: ... struct ReplyDestination { ReplyDisposition handler_type; Messaging::ReplyHandler handler; }; 12. In page 22-50, section 22.14.1.3, remove the last bullet (i.e. the one about typed_excep_holder_repids). 13. In page 22-58, section 22.14.3.6, Change words in the first paragraph from: ... The single argument to this request is the generated ExceptionHolder value[type]. The type information of this ExceptionHolder is specified in the ReplyDestination's typed_excep_holder_repids member. The state of the exception holder is exactly that of the base Messaging::ExceptionHolder. into: ... The single argument to this request is the Messaging::ExceptionHolder valuetype. 14. page 22-69, section A.1 , changes the ExceptionHolder IDL definition to: native UserExceptionBase; valuetype ExceptionHolder { void raise_exception() raises (UserExceptionBase); void raise_exception_with_list( in CORBA::ExceptionList exc_list) raises (UserExceptionBase); private boolean is_system_exception; private boolean byte_order; sequence<octet> marshaled_exception; }; ... 15. page 22-70, section A.2 , changes the ReplyDestination struct to: ... struct ReplyDestination { ReplyDisposition handler_type; Messaging::ReplyHandler handler; }; 16. Replace the first sentence of paragraph 2 in section 3.12.3 with: The <scoped_name>s in the raises expression must be previously defined exceptions or native types. If a native type is used as an exception for an operation, the operation must appear in either a local interface or a valuetype. 17. Replace the first sentence of paragraph 4 in section 3.10.5 with: A native type may be used only to define operation parameters, results, and exceptions. If a native type is used for an exception, it must be mapped to a type in a programming language that can be used as an exception. 18. Add a new section to the Java language mapping specification as follows: 1.22 Java Mapping for CORBA Messaging 1.22.1 Introduction The CORBA messaging specification creates new requirements for the Java mapping. The Java mapping must define what code needs to be generated for sendc and sendp operations consistent with the current standards for ordinary static invocations, and the standard APIs that must be supported for portable AMI stubs. This work is still in progress, so this chapter is largely a placeholder in the current version of this specification. 1.22.2 Mapping of native types Messaging::UserExceptionBase is mapped to org.omg.CORBA.UserException. Actions taken: September 21, 1999: received issue May 13, 2002: closed issue Discussion: It has been pointed out that type specific exception holder offers little use and introduces many problems and complexities. Some of these problems have been discussed by Matthew Mihic in issue 2628 and his message on DSI callbacks in the archive for Issue 2929. To preserve type specific exception holder and fix its problems would need more changes beyond the scope of messaging specification itself and would make things more complicated . Therefore Ke Jin of Inprise proposed a solution a while back, which has now been revised to point out the editing revisions against the latest Messaging Chapter, which suggests simply removing it. The Summary of the main points of the proposal: 1. Remove type specific exception holders from the current Messaging specification and use an extended generic exception holder where a type specific one was used. Rational: One of the main intentions of type specific holders is to have an exception list at interface granularity (if the list is kept by the exception holder) or method granularity (if separate lists are kept for each raise_xxx() methods of the exception holder) instead of a global exception list. To achieve the same function without using type specific exception holders, we suggest, an ORB can keep a user exception list(interface level) or lists (method level) in the reply handler itself. The generic exception holder's local (i.e. in reply handler's local ORB) implementation can have an internal user exception list data member which will be set to refer to one of above given lists (by language mapping code) before the skeleton making an upcall of xxx_excep() method which passes this generic exception holder as parameter. 2. Extend the generic exception holder by adding raise_exception() and raise_exception_with_list() methods. The raise_exception() replaces the raise_xxx() in those old type specific holders. The raise_exception_with_list(), largely from Matthew Mihic's suggestion, is used by a DSI reply handler server to raise exception using an application provided exception list. Rationale: The IDL mapping of raise_exception() and raise_exception_with_list() methods should allow any CORBA exceptions (i.e. system or user) be raised from this method. The raises clause of these method should not to be limited to a specific set of IDL exceptions. As such, it is defined as: module Messaging { ... native UserExceptionBase; valuetype ExceptionHolder { void raise_exception() raises (UserExceptionBase); void raise_exception_with_list( in CORBA::ExceptionList exc_list) raises (UserExceptionBase); ... }; }; Language mappings should choose suitable native UserExceptionBase type (E.g. map to CORBA::UserException in C++ and to org.omg.CORBA.UserException in java). As usual, CORBA::SytemException (or omg.org.CORBA.SystemException) doesn't need to be in the clause for raising it from the method. Above changes not only solve issue 2628 and eleminate issues 2524, 2658 but also largely simplify the Messaging spec.. End of Annotations:===== Date: Tue, 21 Sep 1999 14:18:29 -0700 From: Ke Jin Organization: Inprise Corporation X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: juergen@omg.org Subject: [Fwd: Summary on "removing type specific exception holder" and detail changes:] Content-Type: multipart/mixed; boundary="------------FDB045602558A1023554C475" X-UIDL: 16f7bea28fa7f25914060bc4acc6bb42 Juergen, The attached message was sent to issues and messaging-rtf two months ago. So far, it hasn't been listed as a issue. If there is no solution to the problems, then, I would like to see it can be listed. Thanks, Ke -- Ke Jin Inprise Corporation kejin@inprise.com San Mateo, CA 94404 1+ (650) 358-2409 Message-ID: <37936C3B.6D08A38F@inprise.com> Date: Mon, 19 Jul 1999 11:19:39 -0700 From: Ke Jin Organization: Inprise Corporation X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: messaging-rtf@omg.org Subject: Summary on "removing type specific exception holder" and detail changes: Content-Type: multipart/mixed; boundary="------------367F536B0210B33D300F9CF6" See attached file -- Ke Jin Inprise Corporation kejin@inprise.com San Mateo, CA 94404 1+ (650) 358-2409 Proposal to remove type specific exception holder This message includes a short summary and a list of changes in the spec. document. It has been pointed out that type specific exception holder offers little use and introduces many problems and complicities. Some of these problems have been discussed by Matthew Mihic in issue 2628 and his recent message on DSI callbacks. To preserv type specific exception holder and fix its problems would need more changes beyond the scope of messaging specification itself and would make things more complicate. Therefore, we suggest to simply remove it. Summary of main points of our proposal: 1. Remove type specific exception holder from the current Messaging specification and use an extended generic exception holder where a type specific one was used. Rational: One of main intention of type specific holders is to have an exception list at interface granularity (if the list is kept by the exception holder) or method granularity (if separate lists are kept for each raise_xxx() methods of the exception holder) instead of a global exception list. To achieve the same function without using type specific exception holder, we suggest, an ORB can keep user exception list(interface level) or lists (method level) in reply handler itself. The generic exception holder's local (i.e. in reply handler's local ORB) implement can have an internal user exception list data member which will be set to refer to one of above given lists (by language mapping code) before the skeleton making an upcall of xxx_excep() method which passes this generic exception holder as parameter. 2. Extend the generic exception holder by adding raise_exception() and raise_exception_with_list() methods. The raise_exception() replaces the raise_xxx() in those old type specific holders. The raise_exception_with_list(), largely from Mattheww Mihic's suggestion, is used by a DSI reply handler server to raise exception using an application provided exception list. Rational: The IDL mapping of raise_exception() and raise_exception_with_list() methods should allow any CORBA exceptions (i.e. system or user) be raised from this method. The raises clause of these method should not to be limited to a specific set of IDL exceptions. As such, it is defined as: module Messaging { ... native UserExceptionBase; valuetype ExceptionHolder { void raise_exception() raises (UserExceptionBase); void raise_exception_with_list( in CORBA::ExceptionList exc_list) raises (UserExceptionBase); ... }; }; Language mappings should choose suitable native UserExceptionBase type (E.g. map to CORBA::UserException in C++ and to org.omg.CORBA.UserException in java). As usual, CORBA::SytemException (or omg.org.CORBA.SystemException) doesn't need to be in the clause for raising it from the method. Above changes not only solve issue 2628 and eleminate issues 2524, 2658 but also largely simplify the Messaging spec.. Detail Messaging spec. (orbos/98-05-05) changes are: ---------------------------------------------------- 1. On page 58-59 (beginning of section 6.4) the original text of: ... Therefore, exception replies are propagated to the ReplyHandler in the form of a type specific ExceptionHolder value[type] instance that contains the marshaled exception as its state and has generated operations for raiseing the encapsulated exception in the manner dictated by the programming language's mapping from IDL. change to: ... Therefore, exception replies are propagated to the ReplyHandler in the form of a Messaging::ExceptionHolder valuetype instance that contains the marshaled exception as its state and has raise_exception() and raise_exception_with_list() methods for raising the encapsulated exception. 2. On page 59, the entire section 6.4.1 changes to: 6.4.1 Messaging::ExceptionHolder valuetype The Messaging::ExceptionHolder valuetype encapsulates the exception data and enough information to turn that data back into a raised exception. // IDL module Messaging { // ... all the other stuff native UserExceptionBase; valuetype ExceptionHolder { void raise_exception() raises (UserExceptionBase); void raise_exception_with_list( in CORBA::ExceptionList exc_list, raises (UserExceptionBase); private boolean is_system_exception; private boolean byte_order; private sequence marshaled_exception; }; }; * raise_exception(). This method is used by applications to raise exception from the encapsulated marshaled_exception member. * raise_exception_with_list(). If is_system_exception is true, this function is same as raise_exception(). Otherwise, this method raises an exception from the marshaled_exception using an application provided user exception list. It is useful and should only be used when the given exception holder is not from a skeleton reply handler's xxx_excep() method. For instance, it is from a DSI reply handler servant or from another ORB runtime. In these cases, the exception holder may not have an internal user exception list available. * UserExceptionBase. Language mapping of this native type should allow any user exception to be raised from this method. For instance, it is mapped to CORBA::UserException. in C++ and to org.omg.CORBA.UserException in java. As usual, system exceptions do not need to be in the raises clause for raising them from this method. 3. On page 59-60, remove entire sections 6.4.2 and 6.4.3 4. On page 62, the section 6.5.2: changes: void _excep( in AMI_ExceptionHolder excep_holder); .... void get__excep( in AMI_ExceptionHolder excep_holder); .... void set__excep( in AMI_ExceptionHolder excep_holder); to: void _excep( in Messaging::ExceptionHolder excep_holder); .... void get__excep( in Messaging::ExceptionHolder excep_holder); .... void set__excep( in Messaging::ExceptionHolder excep_holder); 5. On page 64, the section 6.5.3: Change all of (there are 7 instances of them): AMI_StockManagerExceptionHolder in the example IDL into: Messaging::ExceptionHolder 6. On page 73. remove entire section 6.8.2.1 7. On page 74, the section 6.8.2.2, Change all of (there are 7 instances of them): AMI_StockManagerExceptionHolder_ptr in the C++ mapping example into: Messaging::ExceptionHolder_ptr 8. On page 76 - 79, the section 6.8.2.3, Change all of (there are many instances of them): AMI_StockManagerExceptionHolder_ptr in the C++ mapping example into: Messaging::ExceptionHolder_ptr And also change all of (there are also many of them): excep_holder->raise_xxxx(); into: excep_holder->raise_exception(); 9. In page 91, section 7.3, Change the ReplyDestination struct in the Messaging IDL module into: ... struct ReplyDestination { ReplyDispostion handler_type; Messaging::ReplyHandler handler; }; 10.In page 94, section 7.3.1.3, remove the last paragraph (i.e. the one about typed_excep_holder_repids). 11.In page 102, section 7.3.3.5, Change words in the first paragraph from: ... The single argument to this request is the generated ExceptionHolder value[type]. The type information of this ExceptionHolder is specified in the ReplyDestination's typed_excep_holder_repids member. The state of the exception holder is exactly that of the base Messaging::ExceptionHolder. into: ... The single argument to this request is the Messaging::ExceptionHolder valuetype. 12.page 143, section 10.3, changes the ExceptionHolder IDL definition to: native UserExceptionBase; valuetype ExceptionHolder { void raise_exception() raises (UserExceptionBase); void raise_exception_with_list( in CORBA::ExceptionList exc_list) raises (UserExceptionBase); private boolean is_system_exception; private boolean byte_order; sequence marshaled_exception; }; ... 13.page 144, section 10.4, changes the ReplyDestination struct to: ... struct ReplyDestination { ReplyDisposition handler_type; Messaging::ReplyHandler handler; }; ... Date: Mon, 07 May 2001 17:03:36 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Subject: Issue 2929 sense of the RTF vote coming up Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: G==e9hM`d9RQU!!"6i!! Folks, The archive of issue 2929 at: http://cgi.omg.org/issues/issue2929.txt contains a complete proposal for removing type specific exception holders that were introduced in the messaging spec, but then were found to be of little value and more trouble than one had bargained for. The changes are somewhat elaborate to get rid of them. The pros of getting rid of them are: They resolve a number of very difficult issues and largely simplifies the Messaging spec.. The cons are: The changes are significant and if there were any full implementations of messaging deployed, probably breaks them. So the question is, should we proceed in this direction? If we want to do this then I will re-frame the proposed resolution in terms of the current chapter and section numbers. But before I do that work I would like to make sure that this is what we want to do. So the following question will appear in the next vote to get a sense of the RTF: We should work towards adopting a resolution to issue 2929 that consists of removing type specific exception holders and associated changes as outlined in the archive for issue 2929. [YES, NO, ABSTAIN]. So please familiarize yourselves with this issue over the next week or so, so that you can give an informed opinion on how we should proceed with this one. Thanks, Jishnu. X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Received: from albatross-ext.wise.edt.ericsson.se (194.237.142.116) by hobbit.omg.org asmtp(1.0) id 10407; Tue, 08 May 2001 02:32:13 -0400 (EDT) Received: from ms.uab.ericsson.se. (ms.uab.ericsson.se [134.138.201.16]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f486RNN03830; Tue, 8 May 2001 08:27:23 +0200 (MEST) Received: from uabs31i1c55.uab.ericsson.se. (uabs31i1c55 [134.138.186.55]) by ms.uab.ericsson.se. (8.11.1/8.11.1/uab-3.5) with ESMTP id f486RNW11221; Tue, 8 May 2001 08:27:23 +0200 (MET DST) Received: from uab.ericsson.se by uabs31i1c55.uab.ericsson.se. (8.8.8/client-1.3uab2) id IAA25519; Tue, 8 May 2001 08:27:22 +0200 (MET DST) Sender: Chris.Smith@uab.ericsson.se Message-ID: <3AF791CA.74347DEB@uab.ericsson.se> Date: Tue, 08 May 2001 08:27:22 +0200 From: Chris Smith Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.76C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv, en-US MIME-Version: 1.0 To: jishnu_mukerji@hp.com CC: orb_revision@omg.org Subject: Re: Issue 2929 sense of the RTF vote coming up References: <3AF70DA8.40C07CC4@hp.com> Content-Type: multipart/mixed; boundary="------------7D1AE5367DF739CC81854133" X-UIDL: 9]Ne9Zndd97k]d9n_hd9 > The pros of getting rid of them are: > > They resolve a number of very difficult issues and largely > simplifies > the Messaging spec.. > > The cons are: > > The changes are significant and if there were any full > implementations > of messaging deployed, probably breaks them. We have a widely deployed implementation. To say the changes would "probably break it" would be an understatement :-) Another con is of course introducing another native (which I think we agree is not something to do lightly). Ke Jins description didnt appear to discuss the language mappings of UserExceptionBase. There may be issues of language mappins that cannot cope with exception inheritance - I dont know. > > So the question is, should we proceed in this direction? If we want > to > do this then I will re-frame the proposed resolution in terms of the > current chapter and section numbers. But before I do that work I > would > like to make sure that this is what we want to do. We did discuss this many times in the Messaging RTF face to face meetings but never came to anything better than that we had. Somebody also suggested trying to "shoehorn" the exceptions into an Any (since at least that can be done in Java), but is even worse that Ke Jins proposal in my opinion. > > So the following question will appear in the next vote to get a > sense of > the RTF: > > We should work towards adopting a resolution to issue 2929 that > consists > of removing type specific exception holders and associated changes > as > outlined in the archive for issue 2929. [YES, NO, ABSTAIN]. I am not completely against going in this direction, but to be frank I think I need a bit more time to consider the implications of this, since it is such a big change, so I definitely dont want to vote on a resolution to this in the next vote. Trying to discuss this proposal is definitely a good thing though. > > So please familiarize yourselves with this issue over the next week > or > so, so that you can give an informed opinion on how we should > proceed > with this one. > > Thanks, > > Jishnu. [] Chris.Smith.vcf Date: Tue, 08 May 2001 11:05:34 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Chris Smith Cc: orb_revision@omg.org Subject: Re: Issue 2929 sense of the RTF vote coming up References: <3AF70DA8.40C07CC4@hp.com> <3AF791CA.74347DEB@uab.ericsson.se> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: [6Td9bb!e9&<[!!7fL!! Chris, Thanks for the feedback. That is exactly what I was looking for. I think it would be better for me to reword the sense of the RTF vote to say something like: There is a significant possiblity that a resolution to 2929 may be out of scope of what an RTF can do. So before we spend futher time on it, it would be good to know if the RTF feels that the proposed changes are within scope of an RTF's charter. To this the voters are requested to express their opinion by voting on the following question as they see fit. Should issue 2929 be discussed further (the alternative being closing it no change) [YES, NO, ABSTAIN] I am sure people should be able to expres an opinion along these lines. Comments? Thanks, Jishnu. Chris Smith wrote: > > > The pros of getting rid of them are: > > > > They resolve a number of very difficult issues and largely simplifies > > the Messaging spec.. > > > > > The cons are: > > > > The changes are significant and if there were any full implementations > > of messaging deployed, probably breaks them. > > We have a widely deployed implementation. To say the changes would > "probably break it" would be an understatement :-) > > Another con is of course introducing another native (which I think we > agree is not something to do lightly). Ke Jins description didnt > appear to discuss the language mappings of UserExceptionBase. There may > be issues of language mappins that cannot cope with exception > inheritance - > I dont know. > > > > > So the question is, should we proceed in this direction? If we want to > > do this then I will re-frame the proposed resolution in terms of the > > current chapter and section numbers. But before I do that work I would > > like to make sure that this is what we want to do. > > We did discuss this many times in the Messaging RTF face to face > meetings > but never came to anything better than that we had. Somebody also > suggested trying > to "shoehorn" the exceptions into an Any (since at least that can be > done > in Java), but is even worse that Ke Jins proposal in my opinion. > > > > > So the following question will appear in the next vote to get a sense of > > the RTF: > > > > We should work towards adopting a resolution to issue 2929 that consists > > of removing type specific exception holders and associated changes as > > outlined in the archive for issue 2929. [YES, NO, ABSTAIN]. > > I am not completely against going in this direction, but to be frank I > think > I need a bit more time to consider the implications of this, since it is > such a big change, so I definitely dont want to vote on a resolution to > this in the next vote. Trying to discuss this proposal is definitely a > good > thing though. Date: Wed, 9 May 2001 11:06:35 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: Chris Smith , orb_revision@omg.org Subject: Re: Issue 2929 sense of the RTF vote coming up In-Reply-To: <3AF80B3E.7D123ACE@hp.com> Message-ID: Organization: Object Oriented Concepts - An IONA Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Zb+e9g"hd9$pod9TB*!! On Tue, 8 May 2001, Jishnu Mukerji wrote: > Should issue 2929 be discussed further (the alternative being closing it > no change) [YES, NO, ABSTAIN] > > I am sure people should be able to expres an opinion along these lines. > > Comments? I think we should fix this in the RTF. It's broken and can't possibly work. Looks like prime RTF material to me ;-) Cheers, Michi. -- Michi Henning +61 7 3324 9633 Object Oriented Concepts - An IONA Company +61 4 1118 2700 (mobile) Suite 4, 8 Martha St +61 7 3324 9799 (fax) Camp Hill 4152 michi.henning@iona.com Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi Sender: Chris.Smith@uab.ericsson.se Message-ID: <3BC3F1B8.4F8260BF@uab.ericsson.se> Date: Wed, 10 Oct 2001 08:59:04 +0200 From: Chris Smith Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.77C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv, en-US MIME-Version: 1.0 To: jishnu_mukerji@hp.com CC: orb_revision@omg.org, java-rtf@omg.org Subject: Re: Most current issues list for Core RTF References: <3BC3655C.E74278D6@hp.com> Content-Type: multipart/mixed; boundary="------------4F18E8C29142F5D4CB33F1D4" X-UIDL: $=Le9[W@e9=S"e9HjD!! Jishnu, We have been looking at various ways of "migrating" old "type specific" exception holders (and the users who have developed applications against them) over to the proposed solution to 2929. I think we have found a way now, so I would be happy for the RTF to look at this again now. I believe one of the most important parts of this solution is to make sure the necessary additions are made to the Java portability layer so that the Async stuff can be included in portable stub code. I dont know the best way to get this looked at in the Java-rtf - I think there was an issue written, but I am not a member of Java-rtf.... Regards Chris [] Chris.Smith.vcf Date: Wed, 9 Jan 2002 16:54:32 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Issue 2929 To: orb_revision@omg.org Cc: ken.cavanaugh@sun.com MIME-Version: 1.0 Content-MD5: pwfnX2S4tyDPfrFLixFzkg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: ;]od9!ZT!!C!T!!~fh!! In reviewing the proposed resolution to issue 2929 for impact on the Java language mapping, I have discovered what appears to be a significant problem. Point 2. in the resolution defines the following IDL: module Messaging { ... native UserExceptionBase; valuetype ExceptionHolder { void raise_exception() raises (UserExceptionBase); void raise_exception_with_list( in CORBA::ExceptionList exc_list) raises (UserExceptionBase); ... }; }; However, this use of a native type is illegal in IDL. From CORBA 2.5, section 3.10.5, paragraph 4 (CORBA 2.6 appears to be identical in these sections): A native type may be used only to defines operation parameters and results. Even if we argue that exceptions are part of the results, we also have section 3.12.3, paragraph 2: The s in the raises expression must be previously defined exceptions. This applies to valuetypes as well as interfaces because section 3.8.1.2 states that a value can contain anything that an interface can, plus a few additional kinds of elements. I see no way this can be legal IDL with the current rules. On the other hand, I also don't see any problem with using a native as an exception type. We could update the proposal with a couple of additions: 1. Replace the first sentence of paragraph 2 in section 3.12.3 with: The s in the raises expression must be previously defined exceptions or native types. If a native type is used as an exception for an operation, the operation must appear in either a local interface or a valuetype. 2. Replace the first sentence of paragraph 4 in section 3.10.5 with: A native type may be used only to define operation parameters, results, and exceptions. If a native type is used for an exception, it must be mapped to a type in a programming language that can be used as an exception. Perhaps this could be incorporated as a friendly amendment to the proposed resolution for 2929? Ken. Date: Wed, 9 Jan 2002 17:06:36 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Java mapping changes for issue 2929 To: orb_revision@omg.org Cc: java-rtf@omg.org MIME-Version: 1.0 Content-MD5: gictw6YyDM14x06CA5/xvg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: o`d!!BWJe9$9,e9E`Td9 Since the proposed resolution for 2929 introduces a new native type, all language mappings need to be updated for it. What really needs to happen here is we need to add a new section to the Java mapping spec to decsribe the mapping for AMI sendc and sendp. A number of issues need to be handled here, especially 3068. I think it is best to create the new section and add just this issue for now. We will need to write the rest of the chapter in the new Java RTF, as we have not had time yet to work out all of the details. Proposal: Add a new section to the Java language mapping specification as follows: 1.22 Java Mapping for CORBA Messaging 1.22.1 Introduction The CORBA messaging specification creates new requirements for the Java mapping. The Java mapping must define what code needs to be generated for sendc and sendp operations consistent with the current standards for ordinary static invocations, and the standard APIs that must be supported for portable AMI stubs. This work is still in progress, so this chapter is largely a placeholder in the current version of this specification. 1.22.2 Mapping of native types Messaging::UserExceptionBase is mapped to org.omg.CORBA.UserException. Ken. Sender: Chris.Smith@uab.ericsson.se Message-ID: <3C3D47F3.BAFB6770@uab.ericsson.se> Date: Thu, 10 Jan 2002 08:51:15 +0100 From: Chris Smith Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.77C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv, en-US MIME-Version: 1.0 To: Ken Cavanaugh CC: orb_revision@omg.org Subject: Re: Issue 2929 References: <200201100054.g0A0sWI20045@ha2sca-mail1.SFBay.Sun.COM> Content-Type: multipart/mixed; boundary="------------29CEC827DB6A9F2A59D605A1" X-UIDL: 1E_!!!]H!!LL+!!^B[d9 I think its friendly. Ken Cavanaugh wrote: > > In reviewing the proposed resolution to issue 2929 for impact on the Java > language mapping, I have discovered what appears to be a significant problem. > > Point 2. in the resolution defines the following IDL: > > module Messaging { > ... > > native UserExceptionBase; > valuetype ExceptionHolder { > void raise_exception() > raises (UserExceptionBase); > void raise_exception_with_list( > in CORBA::ExceptionList exc_list) > raises (UserExceptionBase); > ... > }; > }; > > > However, this use of a native type is illegal in IDL. From CORBA 2.5, > section 3.10.5, paragraph 4 (CORBA 2.6 appears to be identical in these sections): > > A native type may be used only to defines operation parameters and > results. > > Even if we argue that exceptions are part of the results, we also have > section 3.12.3, paragraph 2: > > The s in the raises expression must be previously > defined exceptions. > > This applies to valuetypes as well as interfaces because section 3.8.1.2 > states that a value can contain anything that an interface can, plus a few > additional kinds of elements. > > I see no way this can be legal IDL with the current rules. > > On the other hand, I also don't see any problem with using a native as an > exception type. We could update the proposal with a couple of additions: > > 1. Replace the first sentence of paragraph 2 in section 3.12.3 with: > > The s in the raises expression must be previously > defined exceptions or native types. If a native type is used > as an exception for an operation, the operation must appear in > either a local interface or a valuetype. > > 2. Replace the first sentence of paragraph 4 in section 3.10.5 with: > > A native type may be used only to define operation parameters, > results, and exceptions. If a native type is used for an exception, > it must be mapped to a type in a programming language that can be > used as an exception. > > Perhaps this could be incorporated as a friendly amendment to the proposed > resolution for 2929? > > Ken. > [] Chris.Smith.vcf