Issue 292: vec10 and CORBA_sequence_long (c_mapping-rtf) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: vec10 and CORBA_sequence_long: are these distinct types?Would they have distinct typecodes and distinct entries in the Interface Repository? Resolution: Revised Text: Actions taken: October 22, 1996: received issue Discussion: End of Annotations:===== Sender: Chris.Smith@uab.ericsson.se Message-ID: <3BF0F26E.B42FE38C@uab.ericsson.se> Date: Tue, 13 Nov 2001 11:14:06 +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: Jishnu Mukerji , orb_revision@omg.org Subject: Re: Issue 292 References: <3BEC096B.8FF88ED5@hp.com> <3BEF9666.9F6FD7A6@uab.ericsson.se> <3BC734C9.378FE12F@hp.com> Content-Type: multipart/mixed; boundary="------------C2476CDE68660A21007F6FF1" X-UIDL: WYKe9,4kd97g0!!"S'e9 Here is the text of Ke Jins original proposal, which I would like to propose myself. I have found a few typos in the IDL which I have corrected. Jishnu - how shold we address the language mapping issue for the native type UserExceptionBase? There exist obvious mappings for most languages, but they probably arent specified in the existing documents. Chris 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 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 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 { ReplyDisposition 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; }; [] Chris.Smith.vcf