From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org, issues@omg.org Message-ID: <852568A4.00553E1F.00@d54mta08.raleigh.ibm.com> Date: Thu, 16 Mar 2000 09:23:09 -0600 Subject: PI needs the ORB to be available in IDL Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: jLid9OPQ!!)Wl!!Bm3!! Portable interceptor implementations need access to the ORB. In order to accomplish this, the ORB must be defined in IDL There are four possibilities that have been opined: 1. Define the ORB as "native ORB;" This puts the ORB into the IDL namespace. However, the ORB is still described in PIDL. This doesn't really help us to remove PIDL, some folks feel this is a misuse of native, but it would be sufficient for the requirements of PI. 2. Define an IDL wrapper for the ORB, call it proxyORB for now. proxyORB would contain exactly the same items that the PIDL ORB does, only defined in pure IDL. Advantages: this is a migration step toward getting rid of ORB PIDL if we encourage folks to use proxyORB rather than ORB. Disadvantages: dual maintenance; lots of work - too much for this FTF?; I don't think we know all the ramifications; where do you get a proxyORB? from the ORB? 3. Make the leap and redefine ORB in IDL now. This option is similar to option 2, but the IDL is not a wrapper, it's the real ORB. Advantages: no dual maintenance; we get rid of ORB PIDL right now. Disadvantages: BIG step - too big for this FTF?; lots of work; I don't think we know all the ramifications. 4. Make the ORB a primitive type like TypeCode. This seems to be generally undesired. It requires all compilers to change. Unless someone really likes this approach, I don't think we should even consider it. Russell Butek butek@us.ibm.com X-Sender: beckwb@192.84.85.3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 16 Mar 2000 10:17:14 -0500 To: butek@us.ibm.com From: Bill Beckwith Subject: Re: PI needs the ORB to be available in IDL Cc: interceptors-ftf@omg.org In-Reply-To: <852568A4.00553E1F.00@d54mta08.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: [#T!!37=e9)g\d9@S""! While I don't disagree with the assertion that ORB should at least be made something like a local interface this level of change seems way beyond the scope of an FTF. -- Bill At 10:23 AM 3/16/00 , butek@us.ibm.com wrote: > > >Portable interceptor implementations need access to the ORB. In order to >accomplish this, the ORB must be defined in IDL There are four >possibilities that have been opined: > >1. Define the ORB as "native ORB;" > >This puts the ORB into the IDL namespace. However, the ORB is still >described in PIDL. This doesn't really help us to remove PIDL, some folks >feel this is a misuse of native, but it would be sufficient for the >requirements of PI. > >2. Define an IDL wrapper for the ORB, call it proxyORB for now. > >proxyORB would contain exactly the same items that the PIDL ORB does, only >defined in pure IDL. Advantages: this is a migration step toward getting >rid of ORB PIDL if we encourage folks to use proxyORB rather than ORB. >Disadvantages: dual maintenance; lots of work - too much for this FTF?; I >don't think we know all the ramifications; where do you get a proxyORB? >from the ORB? > >3. Make the leap and redefine ORB in IDL now. > >This option is similar to option 2, but the IDL is not a wrapper, it's the >real ORB. Advantages: no dual maintenance; we get rid of ORB PIDL right >now. Disadvantages: BIG step - too big for this FTF?; lots of work; I >don't think we know all the ramifications. > >4. Make the ORB a primitive type like TypeCode. > >This seems to be generally undesired. It requires all compilers to change. >Unless someone really likes this approach, I don't think we should even >consider it. > > >Russell Butek >butek@us.ibm.com > > From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568B0.007B771B.00@d54mta08.raleigh.ibm.com> Date: Tue, 28 Mar 2000 16:20:11 -0600 Subject: PI issues #3403, 3432, 3450 Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: -!f!!5D4e9acY!!NAZ!! Just a little bookkeeping. These three issues are really the same: PI needs the ORB to be available in IDL: http://www.omg.org/issues/interceptors-ftf.html#Issue3403 ORB access needed in IDL for Interceptors: http://www.omg.org/issues/interceptors-ftf.html#Issue3432 Getting rid of ORB PIDL: http://www.omg.org/issues/interceptors-ftf.html#Issue3450 Would anyone take umbrage if I closed 3432 and 3450 in favor of 3403? Jeff, your name is on 3450. Bob, yours is on 3432. Russell Butek butek@us.ibm.com From: Jeffrey Mischkinsky Message-Id: <200003282348.PAA13807@wheel.dcn.davis.ca.us> Subject: Re: PI issues #3403, 3432, 3450 To: butek@us.ibm.com Date: Tue, 28 Mar 2000 15:48:20 -0800 (PST) Cc: interceptors-ftf@omg.org In-Reply-To: <852568B0.007B771B.00@d54mta08.raleigh.ibm.com> from "butek@us.ibm.com" at Mar 28, 2000 04:20:11 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: S)f!!IHN!!8)3!!'9^d9 Russ, I don't have any objection (you can have all the glory :-). Seriously i'm not sure why the other 2 got labelled as separate issues. I think both were meant as comments on 3403. I do think that the text that is associated with 3450 and 3432 should be transferred as the comments are very relevant. jeff 'butek@us.ibm.com' writes: > > > > Just a little bookkeeping. These three issues are really the same: > > PI needs the ORB to be available in IDL: > http://www.omg.org/issues/interceptors-ftf.html#Issue3403 > ORB access needed in IDL for Interceptors: > http://www.omg.org/issues/interceptors-ftf.html#Issue3432 > Getting rid of ORB PIDL: > http://www.omg.org/issues/interceptors-ftf.html#Issue3450 > > Would anyone take umbrage if I closed 3432 and 3450 in favor of > 3403? > Jeff, your name is on 3450. Bob, yours is on 3432. > > Russell Butek > butek@us.ibm.com > > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Tue, 18 Jul 2000 20:13:08 -0400 From: Jishnu Mukerji X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Harold Carr Cc: interceptors-ftf@omg.org Subject: Re: Issues 3403 and 3429 References: <200007172252.PAA05599@shorter.eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: pH_!!-@-!!1`Fe9/jbd9 Why can't you just leave them open as unresolved, like all other R/FTFs do? Of course the question is whether their non-resolution renders the porposal unimplementable or not, but if that is the case then they need to be resolved, not just closed no change. Harold Carr wrote: > These issues are the ORB/PIDL/IDL issue. No one has stepped forward > with a proposal and it is too late for something this big. I am > going > to include them in the next vote - we will vote on just closing them > in this FTF and suggest reopening them somewhere else (where, core > rtf?). > > If you feel otherwise, write a proposal we can vote on. > > Cheers, > Harold Date: Wed, 19 Jul 2000 08:45:17 -0230 From: Matthew Newhook To: Harold Carr Cc: Jishnu Mukerji , Harold Carr , interceptors-ftf@omg.org Subject: Re: Issues 3403 and 3429 Message-ID: <20000719084517.B29187@ooc.com> References: <200007172252.PAA05599@shorter.eng.sun.com> <3974F294.75052D1C@fpk.hp.com> <39752C28.D86FF61C@sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <39752C28.D86FF61C@sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: *oGe9[^4e9ee Being a new chair, I thought all issues had to be resolved to close the > FTF. Thanks for the info. In that case, it seems that the ORB/PIDL/IDL > issue will just go unresolved. PI can certainly be implemented without > an ORB being passed as an argument to interceptors. It may not be as > usable though. Actually I would prefer this come to a vote. What I would propose is that we deprecate the ORB-like methods in ORBInitInfo and add readonly attribute ORB the_orb; Or something like that. If that makes ORBInitInfo become PIDL then so be it. I think that we're all aware of the implications of that decision. We've run into problems because the ORB isn't available and our users have complained also. > H 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, 19 Jul 2000 07:54:25 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Jishnu Mukerji , Harold Carr , interceptors-ftf@omg.org Subject: Re: Issues 3403 and 3429 References: <200007172252.PAA05599@shorter.eng.sun.com> <3974F294.75052D1C@fpk.hp.com> <39752C28.D86FF61C@sun.com> <20000719084517.B29187@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 2nk!!j, > Hi, > > On Tue, Jul 18, 2000 at 09:18:48PM -0700, Harold Carr wrote: > > Being a new chair, I thought all issues had to be resolved to close the > > FTF. Thanks for the info. In that case, it seems that the ORB/PIDL/IDL > > issue will just go unresolved. PI can certainly be implemented without > > an ORB being passed as an argument to interceptors. It may not be as > > usable though. > > Actually I would prefer this come to a vote. What I would propose is > that we deprecate the ORB-like methods in ORBInitInfo and add > > readonly attribute ORB the_orb; > > Or something like that. If that makes ORBInitInfo become PIDL then so be > it. I think that we're all aware of the implications of that decision. > We've run into problems because the ORB isn't available and our users > have complained also. > > > H > > 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: Mon, 24 Jul 2000 18:13:00 -0230 From: Matthew Newhook To: Harold Carr Cc: interceptors-ftf@omg.org, juergen@omg.org, csi_submitters@concept5.com Subject: Re: Interceptors FTF end game plan Message-ID: <20000724181300.E23005@ooc.com> References: <200007211823.LAA03427@shorter.eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <200007211823.LAA03427@shorter.eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: 4HIe9P2Le9%m2!!@bO!! Hi, I think that we should include my proposal for issue 3403 in an earlier vote -- if that passes then some of the issues (for instance, 3322, 3429) below disappear Regards, Matthew On Fri, Jul 21, 2000 at 11:23:19AM -0700, Harold Carr wrote: >[...] > 3322 - ORBInitInfo::object_to_string > 3403 - ORB/PIDL > 3429 - ORB/PIDL > 3435 - Interceptors and finalization > 3545 - -ORBInitializer command line > 3599 - detail when request interceptorss called > 3601 - ORBInitInfo::arguments ambiguous > 3609 - Overriding POA policies > 3615 - ReceiveIORInterceptor > 3619 - Server Side points in same thread > > As stated above, I need to receive proposals by: > > 7/26: Vote 6 deadline to receive issue proposals > 8/2: Vote 7 deadline to receive issue proposals > > However, sooner is better if there is going to be any further > discussion. > > That's it. Keep voting - start writing. > > Cheers, > Harold > > ps: If anyone knows of other steps that need to be taken to close, > please let me know (such as voting on the final updated document - is > that necessary?, or writing an FTF report besides the spec). > > > > > > > > > > -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Mon, 24 Jul 2000 17:56:32 -0230 From: Matthew Newhook To: Harold Carr Cc: interceptors-ftf@omg.org Subject: Re: Issues 3403 and 3429 Message-ID: <20000724175632.F22660@ooc.com> References: <200007172252.PAA05599@shorter.eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <200007172252.PAA05599@shorter.eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: ^/(!!\2N!!DWpd9pied9 Hi, Proposal for issue 3403: Since I haven't seen any other proposals here is mine: The essence of the proposal is to deprecate the existing operations on the ORBInitInfo that mirror the ORBs methods, and to add an attribute to retrieve the ORB. I personally prefer this over other proposed methods such as making an ORBProxy, and other such indirect things. Proposal: --- In section 21.7.2: Mark the following methods, exceptions and types as deprecated. Also mark the equivalent sections as deprecated. register_initial_reference resolve_initial_references DuplicateName InvalidName ObjectId codec_factory Add: readonly attribute CORBA::ORB orb; Add a new section to describe this attribute: This attribute is the ORB being initialized. --- Regards, Matthew On Mon, Jul 17, 2000 at 03:52:23PM -0700, Harold Carr wrote: > > These issues are the ORB/PIDL/IDL issue. No one has stepped forward > with a proposal and it is too late for something this big. I am going > to include them in the next vote - we will vote on just closing them > in this FTF and suggest reopening them somewhere else (where, core > rtf?). > > If you feel otherwise, write a proposal we can vote on. > > Cheers, > Harold > -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Mon, 24 Jul 2000 13:44:39 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Harold Carr , interceptors-ftf@omg.org Subject: Re: Issues 3403 and 3429 References: <200007172252.PAA05599@shorter.eng.sun.com> <20000724175632.F22660@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: K^?e9pOF!!3L-e96e^d9 Matthew, I can put your text as is in the next vote. But perhaps you'd like to extend it a bit? For instance, just how "initialized" is the ORB being passed in - in other words, what can one do and not do with it? Also, since ORBInitInfo would become PIDL we would need language mappings for at least C++ and Java. Thanks, Harold ps: I do not think we mark things as deprecated - I think we just remove them if they pass the vote. Matthew Newhook wrote: > > Hi, > > Proposal for issue 3403: > > Since I haven't seen any other proposals here is mine: The essence of > the proposal is to deprecate the existing operations on the ORBInitInfo > that mirror the ORBs methods, and to add an attribute to retrieve > the ORB. I personally prefer this over other proposed methods such as > making an ORBProxy, and other such indirect things. > > Proposal: > > --- > In section 21.7.2: > > Mark the following methods, exceptions and types as deprecated. Also > mark the equivalent sections as deprecated. > > register_initial_reference > resolve_initial_references > DuplicateName > InvalidName > ObjectId > codec_factory > > Add: > > readonly attribute CORBA::ORB orb; > > Add a new section to describe this attribute: > > This attribute is the ORB being initialized. > --- > > Regards, Matthew > > On Mon, Jul 17, 2000 at 03:52:23PM -0700, Harold Carr wrote: > > > > These issues are the ORB/PIDL/IDL issue. No one has stepped forward > > with a proposal and it is too late for something this big. I am going > > to include them in the next vote - we will vote on just closing them > > in this FTF and suggest reopening them somewhere else (where, core > > rtf?). > > > > If you feel otherwise, write a proposal we can vote on. > > > > Cheers, > > Harold > > > > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Tue, 25 Jul 2000 07:18:20 +1000 (EST) From: Michi Henning To: Harold Carr cc: Matthew Newhook , Harold Carr , interceptors-ftf@omg.org Subject: Re: Issues 3403 and 3429 In-Reply-To: <397CAAB7.F29D5AF3@sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: %_Me9~3;e9IA7e9V,E!! On Mon, 24 Jul 2000, Harold Carr wrote: > Matthew, > > I can put your text as is in the next vote. But perhaps you'd like > to > extend it a bit? For instance, just how "initialized" is the ORB > being > passed in - in other words, what can one do and not do with it? > Also, > since ORBInitInfo would become PIDL we would need language mappings > for > at least C++ and Java. In the absence of a specific mapping for a PIDL type in a language mapping, the default mapping rules apply, so we needn't say anything, I think. 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, 24 Jul 2000 17:54:00 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning Cc: Harold Carr , Matthew Newhook , Harold Carr , interceptors-ftf@omg.org Subject: Re: Issues 3403 and 3429 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 65Ke9jZM!!R_M!!Le^d9 Michi Henning wrote: > > On Mon, 24 Jul 2000, Harold Carr wrote: > > > Matthew, > > > > I can put your text as is in the next vote. But perhaps you'd like to > > extend it a bit? For instance, just how "initialized" is the ORB being > > passed in - in other words, what can one do and not do with it? Also, > > since ORBInitInfo would become PIDL we would need language mappings for > > at least C++ and Java. > > In the absence of a specific mapping for a PIDL type in a language mapping, > the default mapping rules apply, so we needn't say anything, I think. Except for the ORBInitInfo::this_orb as in readonly attribute ORB this_orb; or some such. That requires a special mention in the way opf mapping since an ORB does not have a standard language mapping. Jishnu. From: Jeffrey Mischkinsky Message-Id: <200007242202.PAA00596@wheel.dcn.davis.ca.us> Subject: Re: Issues 3403 and 3429 To: michi@ooc.com.au (Michi Henning) Date: Mon, 24 Jul 2000 15:02:49 -0700 (PDT) Cc: harold.carr@sun.com (Harold Carr), matthew@ooc.com (Matthew Newhook), harold.carr@eng.sun.com (Harold Carr), interceptors-ftf@omg.org In-Reply-To: from "Michi Henning" at Jul 25, 2000 07:18:20 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: YIIe9B3pd9^lOe9glBe9 'Michi Henning' writes: > > On Mon, 24 Jul 2000, Harold Carr wrote: > > > Matthew, > > > > I can put your text as is in the next vote. But perhaps you'd like to > > extend it a bit? For instance, just how "initialized" is the ORB being > > passed in - in other words, what can one do and not do with it? Also, > > since ORBInitInfo would become PIDL we would need language mappings for > > at least C++ and Java. > > In the absence of a specific mapping for a PIDL type in a language mapping, > the default mapping rules apply, so we needn't say anything, I think. ahem... but i beg to differ. There are no default rules WRT PIDL that of which i am aware. Some language mappings wave their hands and say something like use the "normal" rules whereever possible, but that is just intent. This is one of the things that makes pidl so evil. cheers, jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Mon, 24 Jul 2000 19:39:48 -0230 From: Matthew Newhook To: Jeffrey Mischkinsky Cc: Michi Henning , Harold Carr , Harold Carr , interceptors-ftf@omg.org Subject: Re: Issues 3403 and 3429 Message-ID: <20000724193948.E23944@ooc.com> References: <200007242202.PAA00596@wheel.dcn.davis.ca.us> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <200007242202.PAA00596@wheel.dcn.davis.ca.us> Content-Type: text/plain; charset=us-ascii X-UIDL: !e9c5gd9e&md9 Hi, On Mon, Jul 24, 2000 at 03:02:49PM -0700, Jeffrey Mischkinsky wrote: > [...] > ahem... but i beg to differ. There are no default rules WRT PIDL that of > which i am aware. > > Some language mappings wave their hands and say something like use the "normal" > rules whereever possible, but that is just intent. > > This is one of the things that makes pidl so evil. Personally, I think it's more evil to introduce a second ORB that looks like the real ORB but isn't ;) Anyway, I can provide language mappings for ORBInitInfo for both C++ & Java (cut & paste from the IDL translator should do the job nicely). > cheers, > jeff > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff@persistence.com +1 650-372-3604 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: Mon, 24 Jul 2000 15:59:02 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Matthew Newhook , Harold Carr , interceptors-ftf@omg.org Subject: Re: Issues 3403 and 3429 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: "Je!!+b@e94QTd9/\Vd9 Great. That makes things simpler. Could you point me to the chapter/verse that specifies the default mapping rules? Thanks, Harold Michi Henning wrote: > > On Mon, 24 Jul 2000, Harold Carr wrote: > > > Matthew, > > > > I can put your text as is in the next vote. But perhaps you'd like to > > extend it a bit? For instance, just how "initialized" is the ORB being > > passed in - in other words, what can one do and not do with it? Also, > > since ORBInitInfo would become PIDL we would need language mappings for > > at least C++ and Java. > > In the absence of a specific mapping for a PIDL type in a language mapping, > the default mapping rules apply, so we needn't say anything, I think. > > 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, 25 Jul 2000 09:56:38 +1000 (EST) From: Michi Henning To: Harold Carr cc: Matthew Newhook , Harold Carr , interceptors-ftf@omg.org Subject: Re: Issues 3403 and 3429 In-Reply-To: <397CCA36.37DEF5CF@sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 5m@!!0O:!!Ji9e9!2N!! On Mon, 24 Jul 2000, Harold Carr wrote: > Great. That makes things simpler. Could you point me to the > chapter/verse that specifies the default mapping rules? Hmmm... Not everyone seems to agree with me :-) For C++, there is no chapter and verse. If there isn't a special mapping for some PIDL type, you just use the normal one... 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, 25 Jul 2000 03:04:15 -0400 From: Jishnu Mukerji X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook Cc: Jeffrey Mischkinsky , Michi Henning , Harold Carr , Harold Carr , interceptors-ftf@omg.org Subject: Re: Issues 3403 and 3429 References: <200007242202.PAA00596@wheel.dcn.davis.ca.us> <20000724193948.E23944@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: FCI!!EHDe9/2Wd9L6~e9 Matthew Newhook wrote: > Hi, > > On Mon, Jul 24, 2000 at 03:02:49PM -0700, Jeffrey Mischkinsky wrote: > > [...] > > ahem... but i beg to differ. There are no default rules WRT PIDL >that of > > which i am aware. > > > > Some language mappings wave their hands and say something like use >the "normal" > > rules whereever possible, but that is just intent. > > > > This is one of the things that makes pidl so evil. > > Personally, I think it's more evil to introduce a second ORB that >looks > like the real ORB but isn't ;) Anyway, I can provide language >mappings > for ORBInitInfo for both C++ & Java (cut & paste from the IDL >translator > should do the job nicely). Matthew, The portion that you can get out of an IDL translator is not the interesting part. The thing that you won't get out of a typical IDL translator is the interesting part, namely, the mapping of the moral equivalent of "_get_this_orb", which returns the ORB which is not something that a standard normal IDL compiler can deal with. That is what you need to provide a language mapping for explicitly. The rest, as you say, is cut and paste from the IDL translator. For the sake of completeness, it would be a good idea to include C++ and Java mappings for the entire ORBInitInfo interface, both the standard part and the special part. Cheers, Jishnu. Reply-To: From: "Nick Sharman" To: "Matthew Newhook" Cc: Subject: RE: Issues 3403 and 3429 Date: Tue, 25 Jul 2000 09:48:40 +0100 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <20000724175632.F22660@ooc.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: !$fd9TIC!!PN#e9>jbd9 > -----Original Message----- > From: Matthew Newhook [mailto:matthew@ooc.com] > > --- > In section 21.7.2: > > Mark the following methods, exceptions and types as deprecated. Also > mark the equivalent sections as deprecated. > > register_initial_reference > resolve_initial_references > DuplicateName > InvalidName > ObjectId > codec_factory We are working towards the first (formal) version of this spec, why not just delete these? It would be a pity to include obsolete code from the start! I appreciate there are vendors with code out in the field, and they will not want to withdraw these features immediately - but they can support these extra, non-standard, as long as they need anyway. But I agree with Matthew - making this PIDL is probably the right answer (I notice that the three AB members who've responded haven't rejected it on moral grounds!) Regards Nick Date: Tue, 25 Jul 2000 07:18:15 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: nick.sharman@peerlogic.com CC: Matthew Newhook , interceptors-ftf@omg.org Subject: Re: Issues 3403 and 3429 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: i9p!!ge6e9;A:e9!ORd9 Nick Sharman wrote: > > > -----Original Message----- > > From: Matthew Newhook [mailto:matthew@ooc.com] > > > > --- > > In section 21.7.2: > > > > Mark the following methods, exceptions and types as deprecated. Also > > ... > We are working towards the first (formal) version of this spec, why not just > delete these? It would be a pity to include obsolete code from the start! Yes, removing them is the way to go... H Date: Tue, 25 Jul 2000 11:59:54 -0230 From: Matthew Newhook To: interceptors-ftf@omg.org Subject: Issue 3403 update Message-ID: <20000725115954.A28168@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us Content-Type: text/plain; charset=us-ascii X-UIDL: )n)!!:==e980Td9OkJe9 Hi, Please see the below proposal. Comments welcome. As written the vote would be No, Proposal A, or Proposal B. Best Regards, Matthew Proposal: In section 21.7.2: Delete the following methods, exceptions and types. register_initial_reference resolve_initial_references codec_factory InvalidName ObjectId Add: readonly attribute CORBA::ORB orb; Add a new section to describe this attribute: This attribute is the ORB being initialized. In addition I propose two additions to the section: Proposal A: The ORB shall be considered partially constructed in that any method invocations on objects created by this ORB will not have request interceptors called. Calling work_pending()/perform_work()/run()/shutdown() or destroy() on the ORB is not permitted and shall have undefined results. Proposal B: The ORB shall be considered partially constructed in that no method invocations on objects created by this ORB are permitted. Calling work_pending()/perform_work()/run()/shutdown() or destroy() on the ORB is not permitted and shall have undefined results. I prefer Proposal A since not being able to make method invocations implies that things that narrowing of object references is not permitted. What this essentially means is that interceptors probably cannot be fully initialized in the ORB initializer. PIDL Mapping for C++: [I'm not sure exactly how this should look -- this is essentially trimmed output from out IDL translator] namespace PortableInterceptor { class ORBInitInfo : virtual public CORBA::Object { public: static inline ORBInitInfo_ptr _duplicate(ORBInitInfo_ptr p) { if(p) p -> _OB_incRef(); return p; } static inline ORBInitInfo_ptr _nil() { return 0; } static ORBInitInfo_ptr _narrow(CORBA::Object_ptr); static ORBInitInfo_ptr _narrow(CORBA::AbstractBase_ptr); struct DuplicateName : public CORBA::UserException { DuplicateName() { } DuplicateName(const DuplicateName&); DuplicateName& operator=(const DuplicateName&); static DuplicateName* _downcast(CORBA::Exception*); static const DuplicateName* _downcast(const CORBA::Exception*); virtual void _raise() const { throw *this; } virtual const char* _name() const; virtual const char* _rep_id() const; virtual char* _to_string() const; DuplicateName(const char*); }; virtual CORBA::StringSeq* arguments() = 0; virtual char* orb_id() = 0; virtual CORBA::ORB_ptr orb() = 0; virtual void add_client_request_interceptor(ClientRequestInterceptor_ptr interceptor) = 0; virtual void add_server_request_interceptor(ServerRequestInterceptor_ptr interceptor) = 0; virtual void add_ior_interceptor(IORInterceptor_ptr interceptor) = 0; virtual SlotId allocate_state_slot() = 0; virtual void register_policy_factory(CORBA::PolicyType type, PolicyFactory_ptr policy_factory) = 0; }; class ORBInitializer : virtual public CORBA::Object { public: static inline ORBInitializer_ptr _duplicate(ORBInitializer_ptr p) { if(p) p -> _OB_incRef(); return p; } static inline ORBInitializer_ptr _nil() { return 0; } static ORBInitializer_ptr _narrow(CORBA::Object_ptr); static ORBInitializer_ptr _narrow(CORBA::AbstractBase_ptr); virtual void pre_init(ORBInitInfo_ptr info) = 0; virtual void post_init(ORBInitInfo_ptr info) = 0; }; } // End of namespace PortableInterceptor namespace CORBA { inline void release(PortableInterceptor::ORBInitInfo_ptr p) { if(p) p -> _OB_decRef(); } inline Boolean is_nil(PortableInterceptor::ORBInitInfo_ptr p) { return p == 0; } } // End of namespace CORBA // // IDL:omg.org/PortableInterceptor/ORBInitializer:1.0 // namespace CORBA { inline void release(PortableInterceptor::ORBInitializer_ptr p) { if(p) p -> _OB_decRef(); } inline Boolean is_nil(PortableInterceptor::ORBInitializer_ptr p) { return p == 0; } } // End of namespace CORBA PIDL mapping for Java *** What should I include for this? -- I could, for instance, include trimmed output files for our IDL/Java translator. 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: Tue, 25 Jul 2000 10:37:42 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: nick.sharman@peerlogic.com Cc: Matthew Newhook , interceptors-ftf@omg.org Subject: Re: Issues 3403 and 3429 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: b\8!!Q > > -----Original Message----- > > From: Matthew Newhook [mailto:matthew@ooc.com] > > > > --- > > In section 21.7.2: > > > > Mark the following methods, exceptions and types as deprecated. Also > > mark the equivalent sections as deprecated. > > > > register_initial_reference > > resolve_initial_references > > DuplicateName > > InvalidName > > ObjectId > > codec_factory > > We are working towards the first (formal) version of this spec, why not just > delete these? It would be a pity to include obsolete code from the start! > > I appreciate there are vendors with code out in the field, and they will not > want to withdraw these features immediately - but they can support these > extra, non-standard, as long as they need anyway. The certification (such as there is) of an implementation is with reference to the product of the FTF, which presumably will include the new version of this interface. So I think it is all right to remove these operations. > But I agree with Matthew - making this PIDL is probably the right answer (I > notice that the three AB members who've responded haven't rejected it on > moral grounds!) Well.... it is of course completely and utterly rejected on moral grounds; But on practical grounds, this is the lesser of the several possible evils.:-) The ideal solution is not something that is within the scope of an R/FTF. Jishnu. Jishnu. Sender: Peter.Walker@eng.sun.com Message-ID: <397DAD50.B8E445BE@eng.Sun.COM> Date: Tue, 25 Jul 2000 08:08:00 -0700 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: nick.sharman@peerlogic.com, Matthew Newhook , interceptors-ftf@omg.org Subject: Re: Issues 3403 and 3429 References: <397DA636.EEF73094@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ?6md9G3-!!f"3!!li*e9 Jishnu Mukerji wrote: > > Nick Sharman wrote: > > > > But I agree with Matthew - making this PIDL is probably the right answer (I > > notice that the three AB members who've responded haven't rejected it on > > moral grounds!) > > Well.... it is of course completely and utterly rejected on moral > grounds; But on practical grounds, this is the lesser of the several > possible evils.:-) The ideal solution is not something that is within > the scope of an R/FTF. > I do however suggest that the FTF Report contain a justification for the use of PIDL so that the AB (or whoever) can judge the "evil" at the proper time. Peter. -- ================================================================== Peter J. Walker Sun Microsystems, Inc. Senior Staff Engineer, Enterprise Java. Software Systems Group. Cupertino, CA. pwalker@eng.Sun.com http://java.sun.com/j2ee Phone (408)517-5679 ================================================================== Sender: jis@fpk.hp.com Message-ID: <397DB01D.C1CCB886@fpk.hp.com> Date: Tue, 25 Jul 2000 11:19:57 -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: Peter Walker Cc: nick.sharman@peerlogic.com, Matthew Newhook , interceptors-ftf@omg.org Subject: Re: Issues 3403 and 3429 References: <397DA636.EEF73094@fpk.hp.com> <397DAD50.B8E445BE@eng.Sun.COM> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: !VA!!"F=!!i@m!!fKQd9 Peter Walker wrote: > > Jishnu Mukerji wrote: > > > > Nick Sharman wrote: > > > > > > But I agree with Matthew - making this PIDL is probably the right answer (I > > > notice that the three AB members who've responded haven't rejected it on > > > moral grounds!) > > > > Well.... it is of course completely and utterly rejected on moral > > grounds; But on practical grounds, this is the lesser of the several > > possible evils.:-) The ideal solution is IMHO not something that is within > > the scope of an R/FTF. > > > > I do however suggest that the FTF Report contain a justification for the > use of PIDL so that the AB (or whoever) can judge the "evil" at the > proper time. Absolutely. Just because some AB members initmately familiar with the problem are not complaining, does not mean that the AB won't complain.:-) Afterall 3 is a relatively small minority in a body of 11 extremely opinionated minds. So adequate justification should indeed be provided in the FTF report. Ideally, the three alternatives that were considered and rejected should be summarized with reasons for rejection. Cheers, Jishnu. From: Jeffrey Mischkinsky Message-Id: <200007251553.IAA00824@wheel.dcn.davis.ca.us> Subject: Re: Issues 3403 and 3429 To: jis@fpk.hp.com (Jishnu Mukerji) Date: Tue, 25 Jul 2000 08:53:58 -0700 (PDT) Cc: Peter.Walker@eng.sun.com (Peter Walker), nick.sharman@peerlogic.com, matthew@ooc.com (Matthew Newhook), interceptors-ftf@omg.org In-Reply-To: <397DB01D.C1CCB886@fpk.hp.com> from "Jishnu Mukerji" at Jul 25, 2000 11:19:57 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: CSWd9K&#e9+a~e9_Jj!! 'Jishnu Mukerji' writes: > > Peter Walker wrote: > > > > Jishnu Mukerji wrote: > > > > > > Nick Sharman wrote: > > > > > > > > But I agree with Matthew - making this PIDL is probably the right answer (I > > > > notice that the three AB members who've responded haven't rejected it on > > > > moral grounds!) > > > > > > Well.... it is of course completely and utterly rejected on moral > > > grounds; But on practical grounds, this is the lesser of the several > > > possible evils.:-) The ideal solution is IMHO not something that is within > > > the scope of an R/FTF. > > > > > > > I do however suggest that the FTF Report contain a justification for the > > use of PIDL so that the AB (or whoever) can judge the "evil" at the > > proper time. > > Absolutely. Just because some AB members initmately familiar with the problem are not complaining, > does not mean that the AB won't complain.:-) Or that any of those 3 won't :-) Determining the meaning of silence is somewhat problematic :-) No, that was not a hint!!! jeff >Afterall 3 is a relatively small minority in a body of > 11 extremely opinionated minds. So adequate justification should >indeed be provided in the FTF > report. Ideally, the three alternatives that were considered and >rejected should be summarized with > reasons for rejection. > > Cheers, > > Jishnu. > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Wed, 26 Jul 2000 11:49:36 +1000 (EST) From: Michi Henning To: Nick Sharman cc: Matthew Newhook , interceptors-ftf@omg.org Subject: RE: Issues 3403 and 3429 In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: A@1!!!L+e9L_>e9:':!! On Tue, 25 Jul 2000, Nick Sharman wrote: > But I agree with Matthew - making this PIDL is probably the right answer (I > notice that the three AB members who've responded haven't rejected it on > moral grounds!) Is this some blunt attempt at shoring up support just in case? (I'm only joking... :-) Cheers, Michi. Date: Wed, 26 Jul 2000 14:21:19 -0230 From: Matthew Newhook To: interceptors-ftf@omg.org Subject: Re: Issue 3403 update Message-ID: <20000726142119.F7684@ooc.com> References: <20000725115954.A28168@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <20000725115954.A28168@ooc.com> Content-Type: text/plain; charset=us-ascii X-UIDL: b~Be9K8dd95V_d9P&P!! Hi, Any comments? I'd appreciate some feedback ASAP on how to do the language mappings... I mean I can attach the entire IDL/Java output for the new ORBInitInfo interface -- but that's quite a bit of code. Regards, Matthew On Tue, Jul 25, 2000 at 11:59:54AM -0230, Matthew Newhook wrote: > Hi, > > Please see the below proposal. Comments welcome. As written the vote > would be No, Proposal A, or Proposal B. > > Best Regards, Matthew > > Proposal: > > In section 21.7.2: > > Delete the following methods, exceptions and types. > > register_initial_reference > resolve_initial_references > codec_factory > InvalidName > ObjectId > > Add: > > readonly attribute CORBA::ORB orb; > > Add a new section to describe this attribute: > > This attribute is the ORB being initialized. > > In addition I propose two additions to the section: > > Proposal A: > > The ORB shall be considered partially constructed in > that any method invocations on objects created by this > ORB will not have request interceptors called. Calling > work_pending()/perform_work()/run()/shutdown() or destroy() on the > ORB is not permitted and shall have undefined results. > > Proposal B: > > The ORB shall be considered partially constructed in that no > method invocations on objects created by this ORB are permitted. > Calling work_pending()/perform_work()/run()/shutdown() or destroy() > on the ORB is not permitted and shall have undefined results. > > I prefer Proposal A since not being able to make method invocations > implies that things that narrowing of object references is not > permitted. What this essentially means is that interceptors probably > cannot be fully initialized in the ORB initializer. > > PIDL Mapping for C++: > > [I'm not sure exactly how this should look -- this is essentially > trimmed output from out IDL translator] > > namespace PortableInterceptor > { > > class ORBInitInfo : virtual public CORBA::Object > { > public: > > static inline ORBInitInfo_ptr > _duplicate(ORBInitInfo_ptr p) > { > if(p) > p -> _OB_incRef(); > return p; > } > > static inline ORBInitInfo_ptr > _nil() > { > return 0; > } > > static ORBInitInfo_ptr _narrow(CORBA::Object_ptr); > static ORBInitInfo_ptr _narrow(CORBA::AbstractBase_ptr); > > struct DuplicateName : public CORBA::UserException > { > DuplicateName() { } > DuplicateName(const DuplicateName&); > DuplicateName& operator=(const DuplicateName&); > > static DuplicateName* _downcast(CORBA::Exception*); > static const DuplicateName* _downcast(const CORBA::Exception*); > virtual void _raise() const { throw *this; } > virtual const char* _name() const; > virtual const char* _rep_id() const; > virtual char* _to_string() const; > > DuplicateName(const char*); > }; > > virtual CORBA::StringSeq* arguments() = 0; > > virtual char* orb_id() = 0; > > virtual CORBA::ORB_ptr orb() = 0; > > virtual void add_client_request_interceptor(ClientRequestInterceptor_ptr interceptor) = 0; > > virtual void add_server_request_interceptor(ServerRequestInterceptor_ptr interceptor) = 0; > > virtual void add_ior_interceptor(IORInterceptor_ptr interceptor) = 0; > > virtual SlotId allocate_state_slot() = 0; > > virtual void register_policy_factory(CORBA::PolicyType type, > PolicyFactory_ptr policy_factory) = 0; > }; > > class ORBInitializer : virtual public CORBA::Object > { > public: > > static inline ORBInitializer_ptr > _duplicate(ORBInitializer_ptr p) > { > if(p) > p -> _OB_incRef(); > return p; > } > > static inline ORBInitializer_ptr > _nil() > { > return 0; > } > > static ORBInitializer_ptr _narrow(CORBA::Object_ptr); > static ORBInitializer_ptr _narrow(CORBA::AbstractBase_ptr); > > virtual void pre_init(ORBInitInfo_ptr info) = 0; > > virtual void post_init(ORBInitInfo_ptr info) = 0; > }; > > } // End of namespace PortableInterceptor > > namespace CORBA > { > > inline void > release(PortableInterceptor::ORBInitInfo_ptr p) > { > if(p) > p -> _OB_decRef(); > } > > inline Boolean > is_nil(PortableInterceptor::ORBInitInfo_ptr p) > { > return p == 0; > } > > } // End of namespace CORBA > > // > // IDL:omg.org/PortableInterceptor/ORBInitializer:1.0 > // > namespace CORBA > { > > inline void > release(PortableInterceptor::ORBInitializer_ptr p) > { > if(p) > p -> _OB_decRef(); > } > > inline Boolean > is_nil(PortableInterceptor::ORBInitializer_ptr p) > { > return p == 0; > } > > } // End of namespace CORBA > > PIDL mapping for Java > > *** What should I include for this? -- I could, for instance, include > trimmed output files for our IDL/Java translator. > > 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 -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Issue 3403 update Date: Wed, 26 Jul 2000 19:21:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: l2*e9,"*e992 -----Original Message----- > From: Matthew Newhook [mailto:matthew@ooc.com] > Sent: Wednesday, July 26, 2000 12:51 PM > To: interceptors-ftf@omg.org > Subject: Re: Issue 3403 update > > > Hi, > > Any comments? I'd appreciate some feedback ASAP on how to do the > language mappings... I mean I can attach the entire IDL/Java output > for the new ORBInitInfo interface -- but that's quite a bit of code. > > Regards, Matthew > > On Tue, Jul 25, 2000 at 11:59:54AM -0230, Matthew Newhook wrote: > > Hi, > > > > Please see the below proposal. Comments welcome. As > written the vote > > would be No, Proposal A, or Proposal B. > > > > Best Regards, Matthew > > > > Proposal: > > > > In section 21.7.2: > > > > Delete the following methods, exceptions and types. > > > > register_initial_reference > > resolve_initial_references > > codec_factory > > InvalidName > > ObjectId > > > > Add: > > > > readonly attribute CORBA::ORB orb; > > > > Add a new section to describe this attribute: > > > > This attribute is the ORB being initialized. > > > > In addition I propose two additions to the section: > > > > Proposal A: > > > > The ORB shall be considered partially constructed in > > that any method invocations on objects created by this > > ORB will not have request interceptors called. Calling > > work_pending()/perform_work()/run()/shutdown() or > destroy() on the > > ORB is not permitted and shall have undefined results. > > > > Proposal B: > > > > The ORB shall be considered partially constructed in that no > > method invocations on objects created by this ORB are permitted. > > Calling work_pending()/perform_work()/run()/shutdown() > or destroy() > > on the ORB is not permitted and shall have undefined results. > > > > I prefer Proposal A since not being able to make method invocations > > implies that things that narrowing of object references is not > > permitted. What this essentially means is that interceptors probably > > cannot be fully initialized in the ORB initializer. > > > > PIDL Mapping for C++: > > > > [I'm not sure exactly how this should look -- this is essentially > > trimmed output from out IDL translator] > > > > namespace PortableInterceptor > > { > > > > class ORBInitInfo : virtual public CORBA::Object > > { > > public: > > > > static inline ORBInitInfo_ptr > > _duplicate(ORBInitInfo_ptr p) > > { > > if(p) > > p -> _OB_incRef(); > > return p; > > } > > > > static inline ORBInitInfo_ptr > > _nil() > > { > > return 0; > > } > > > > static ORBInitInfo_ptr _narrow(CORBA::Object_ptr); > > static ORBInitInfo_ptr _narrow(CORBA::AbstractBase_ptr); > > > > struct DuplicateName : public CORBA::UserException > > { > > DuplicateName() { } > > DuplicateName(const DuplicateName&); > > DuplicateName& operator=(const DuplicateName&); > > > > static DuplicateName* _downcast(CORBA::Exception*); > > static const DuplicateName* _downcast(const > CORBA::Exception*); > > virtual void _raise() const { throw *this; } > > virtual const char* _name() const; > > virtual const char* _rep_id() const; > > virtual char* _to_string() const; > > > > DuplicateName(const char*); > > }; > > > > virtual CORBA::StringSeq* arguments() = 0; > > > > virtual char* orb_id() = 0; > > > > virtual CORBA::ORB_ptr orb() = 0; > > > > virtual void > add_client_request_interceptor(ClientRequestInterceptor_ptr > interceptor) = 0; > > > > virtual void > add_server_request_interceptor(ServerRequestInterceptor_ptr > interceptor) = 0; > > > > virtual void add_ior_interceptor(IORInterceptor_ptr > interceptor) = 0; > > > > virtual SlotId allocate_state_slot() = 0; > > > > virtual void register_policy_factory(CORBA::PolicyType type, > > PolicyFactory_ptr > policy_factory) = 0; > > }; > > > > class ORBInitializer : virtual public CORBA::Object > > { > > public: > > > > static inline ORBInitializer_ptr > > _duplicate(ORBInitializer_ptr p) > > { > > if(p) > > p -> _OB_incRef(); > > return p; > > } > > > > static inline ORBInitializer_ptr > > _nil() > > { > > return 0; > > } > > > > static ORBInitializer_ptr _narrow(CORBA::Object_ptr); > > static ORBInitializer_ptr _narrow(CORBA::AbstractBase_ptr); > > > > virtual void pre_init(ORBInitInfo_ptr info) = 0; > > > > virtual void post_init(ORBInitInfo_ptr info) = 0; > > }; > > > > } // End of namespace PortableInterceptor > > > > namespace CORBA > > { > > > > inline void > > release(PortableInterceptor::ORBInitInfo_ptr p) > > { > > if(p) > > p -> _OB_decRef(); > > } > > > > inline Boolean > > is_nil(PortableInterceptor::ORBInitInfo_ptr p) > > { > > return p == 0; > > } > > > > } // End of namespace CORBA > > > > // > > // IDL:omg.org/PortableInterceptor/ORBInitializer:1.0 > > // > > namespace CORBA > > { > > > > inline void > > release(PortableInterceptor::ORBInitializer_ptr p) > > { > > if(p) > > p -> _OB_decRef(); > > } > > > > inline Boolean > > is_nil(PortableInterceptor::ORBInitializer_ptr p) > > { > > return p == 0; > > } > > > > } // End of namespace CORBA > > > > PIDL mapping for Java > > > > *** What should I include for this? -- I could, for > instance, include > > trimmed output files for our IDL/Java translator. > > > > 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 -- 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, 26 Jul 2000 21:24:05 -0230 From: Matthew Newhook To: Paul Kyzivat Cc: interceptors-ftf@omg.org Subject: Re: Issue 3403 update Message-ID: <20000726212405.B11179@ooc.com> References: <9B164B713EE9D211B6DC0090273CEEA926BF4C@bos1.noblenet.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BF4C@bos1.noblenet.com> Content-Type: text/plain; charset=us-ascii X-UIDL: P3Ne9Ra6e9;OWd9ELfd9 Hi Paul, On Wed, Jul 26, 2000 at 07:21:06PM -0400, Paul Kyzivat wrote: > Maybe I missed something, but it seems to me that this > has simply opened the can of worms; disposed of one > and left the others crawling around. > > You distinguish the two alternatives by whether objects > created by the orb may be called. I meant object-references associated with the ORB -- for instance, calling resolve_initial_references and then _narrow, or string_to_object and then some RPC call. > But the orb doesn't > create objects - object adapters (i.e. POAs) do. > (With the exception of those created with string_to_object.) Well, there are lots of other ways to get object-references other than string_to_object. An RPC call that returns object-references, for instance. > This brings up the point we have discussed (but not > nailed down) about the interaction of interceptors with > Object Adapters and the creation of object references. > > So, we need to specify whether resolve_initial_references("RootPOA") > may be called on the orb. And if so, we need to discuss how > functional the root POA is. (Can create_POA be called?) And what > about POAManager? (You need to call activate on it to use any > objects created in the root POA.) > > This is a transitivity problem - opening up access to the ORB > opens up access to everything reachable from the ORB. > > I am not opposed to this in general, but it is going to be a mess > to specify this strongly enough to be useful. I can only speak for our ORB implementation -- and I don't think we need to restrict the user from resolving the root POA, creating new POAs, or whatever. > Paul 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: Thu, 27 Jul 2000 16:00:58 -0230 From: Matthew Newhook To: Harold Carr Cc: interceptors-ftf@omg.org Subject: Re: SUN's vote on vote 6 Message-ID: <20000727160058.A18585@ooc.com> References: <200007271749.KAA04433@shorter.eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <200007271749.KAA04433@shorter.eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: SUN votes as follows: > > 3403: NO - > Introducing PIDL will probably cause the spec not to be > adopted. We've already introduced PIDL -- why is this different? > I think a separate RFP to handle the ORB/PIDL/IDL > problem is in order. Plus, this involves "ORB State" which is > ill-defined. Perhaps the ORB/PIDL/IDL RFP can also define ORB > states. Then, in a future revision of PI, the ORB can be > passed > in in a well-defined state. This ORB state argument makes no sense to me. What is the argument here? The user can already resolve the root POA (through ORBInitInfo::resolve_initial_references). The user can already make method invocations -- the spec simply doesn't say what happens. The new stuff the user can do: - Call object_to_string/string_to_object (this is generally agreed upon as a needed thing anyway). - Call run/shutdown, etc. My proposal says that this is illegal -- so what's the new problem here? Not making the ORB available is a terrific pain in the ass for end-users and developers. We've already had loads of complaints about this from our users. I urge everyone to carefully consider the options on this proposal. If in the future the ORB is changed to locality constrained IDL whatever then the ORBInitInfo then becomes IDL again. > Cheers, > Harold 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: Fri, 28 Jul 2000 11:44:58 -0230 From: Matthew Newhook To: Paul Kyzivat Cc: interceptors-ftf@omg.org Subject: Re: Issue 3403 update Message-ID: <20000728114458.B22680@ooc.com> References: <9B164B713EE9D211B6DC0090273CEEA926BF5B@bos1.noblenet.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BF5B@bos1.noblenet.com> Content-Type: text/plain; charset=us-ascii X-UIDL: ;N9e9F_Fe9^WAe9FL$!! Hi Paul, On Thu, Jul 27, 2000 at 07:10:34PM -0400, Paul Kyzivat wrote: > [...] > > I can only speak for our ORB implementation -- and I don't > > think we need to restrict the user from resolving the root POA, creating > > new POAs, or whatever. I want to point out that this is nothing new -- this problem already exists since resolve_initial_references is currently available on the ORBInitInfo interface. This should really be a seperate issue. > I don't think it is a matter of restricting. > It is a matter of defining what happens of you do these things? > > If you create POAs, then use them to create object references, and > then > invoke on those object references: > > - how are the profiles in those object references going to be > initialized? > > - does the answer to the above depend on when it is done during > orbinit? > > - will object references created by those same POAs after orbinit is > complete use the same ior template as those created earlier? > > It isn't useful to imply that these things are legal but not specify > the > semantics of doing them. Agreed. Actually, probably the most sensible thing to say is that the user isn't permitted to resolve the root POA. Then all these problems go away. > Paul 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 From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Issue 3403 update Date: Thu, 27 Jul 2000 19:10:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: W8%!!Xd:e9PPod9T__d9 see below Paul > -----Original Message----- > From: Matthew Newhook [mailto:matthew@ooc.com] > Sent: Wednesday, July 26, 2000 7:54 PM > To: Paul Kyzivat > Cc: interceptors-ftf@omg.org > Subject: Re: Issue 3403 update > > > Hi Paul, > > On Wed, Jul 26, 2000 at 07:21:06PM -0400, Paul Kyzivat wrote: > > Maybe I missed something, but it seems to me that this > > has simply opened the can of worms; disposed of one > > and left the others crawling around. > > > > You distinguish the two alternatives by whether objects > > created by the orb may be called. > > I meant object-references associated with the ORB -- for instance, > calling resolve_initial_references and then _narrow, or > string_to_object and then some RPC call. OK. You mean any reference managed by the orb. > I can only speak for our ORB implementation -- and I don't > think we need to restrict the user from resolving the root POA, > creating > new POAs, or whatever. I don't think it is a matter of restricting. It is a matter of defining what happens of you do these things? If you create POAs, then use them to create object references, and then invoke on those object references: - how are the profiles in those object references going to be initialized? - does the answer to the above depend on when it is done during orbinit? - will object references created by those same POAs after orbinit is complete use the same ior template as those created earlier? It isn't useful to imply that these things are legal but not specify the semantics of doing them. Paul From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Issue 3403 update Date: Mon, 31 Jul 2000 08:40: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: 7ZM!!m`Le9b"E!!%]0!! > From: Matthew Newhook [mailto:matthew@ooc.com] > > It isn't useful to imply that these things are legal but > not specify the > > semantics of doing them. > > Agreed. Actually, probably the most sensible thing to say is that the > user isn't permitted to resolve the root POA. Then all these > problems go > away. That is a start. But it isn't immediately obvious (to me anyway) what other definitions/restrictions need to be in place to make things well defined. (Another one might be resolution of the various Currents - POACurrent, TransactionCurrent, SecurityCurrent, etc. Until the interceptors have been initialized these may not be usable.) As someone else pointed out, we are gradually developing more and more requirements for an ORB state model: - what states an orb has - how transitions between states occur - what is permissible in each state - behavior when things not permissible in a state are attempted Hiding the orb during initialization is one way to sidestep the need to define this, but I think it is probably better to simply confront it. Paul From: "Nick Sharman" To: "OMG Interceptors RTF" , "OMG ORB Core RTF" Subject: Issue 3772 (and also PI issues 3403, 3322 and 3429) Date: Thu, 30 Nov 2000 13:12:44 -0000 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 0GL!!M6"!!ccn!!Rb5e9 All, Michi has identified a need for access to a POA's owning ORB (issue 3772). In parallel, members of the Portable Interceptors RTF have identified a need for access to the ORB-being-initialized from an ORBInitInfo (issues 3403, 3429). That would remove the need to duplicate ORB's operations on ORBInitInfo, as we have with e.g. resolve_initial_references() and as Matthew has suggested for object_to_string()/string_to_object() (issue 3332). The obvious approach is to add an operation e.g. "CORBA::ORB the_orb();" just to POA and ORBInitInfo; that stumbles on the fact that ORB is PIDL, not IDL. That leads to the suggestion (issues 3403, 3429) that we convert ORB itself to IDL. However, RTF members are concerned that such a change, unless very carefully managed, would break every CORBA application. We would have to introduce a new ORB type (CORBA_3::ORB?) that coexisted with the old PIDL ORB, probably for a long time. As none of us has yet come up with a concrete proposal, I suggest we pursue Bob Kukura's alternative approach (on issue 3772's thread): to add an ORB accessor to Object. This sidesteps the IDL/PIDL issue, since Object is an IDL keyword but is already defined in PIDL, so this approach doesn't make anything worse. I would suggest the signature "CORBA::ORB _orb();", because it then makes the implementation in Java trivial. All stubs have to extend org.omg.CORBA.portable.ObjectImpl and all local interface implementations have to extend org.omg.CORBA.LocalObject, both of which define such a method. All that needs doing is to add an abstract method (or a non-final one that thoes NO_IMLEMENT to org.omg.CORBA.Object, and we're done. Well, nearly done. We're OK for non-local interfaces, but the one's we're particularly interested in are both local interfaces. I see two options here: (1) In Ch. 4, say that _orb() on local objects is undefined (and may raise NO_IMPLEMENT) unless specified otherwise on particular interfaces, and then call out POA and ORBInitInfo as interfaces where it is defined in Chs. 11 & 21. (2) try to specify what happens based on some broad categories of local objects, of which I see three: - those created necessarily by the ORB vendor (e.g. POA, ORBInitInfo); - those possibly created in an iterceptor (e.g. various interfaces derived from Policy & Current); - those created by application developers (e.g. ServantManagers). (1) is simpler of course, and enough for our immediate needs; we could look to broaden it into (2) later if necessary. How about it? If we think it's worth pursuing, and if I'm in the rechartered ORB RTF, I volunteer to work up a detailed proposal (based on (1), unless there's a clamour for (2)). Regards Nick Nick Sharman Architect, LiveContent BROKER Critical Path UK Tel: +44 (0) 161 333 4073 UK Fax: +44 (0) 161 333 4001 E-mail: mailto:nick.sharman@cp.net Web: http://www.cp.net Date: Thu, 2 May 2002 22:23:50 -0700 (PDT) From: Harold Carr To: corba-rtf@omg.org Subject: Issues 3322, 3403, 3429 PI/ORB/PIDL Hello, Issues 3322, 3403, 3429 all essentially say that interceptors and ORBInitializers need access to the ORB they are associated with. I see two problems: 1. For ORBInitializers it would need to be specified how much of that ORB can be used (since ORBInitializers are executed during ORB.init) or that pre and post_init are the last two things ORB.init does so that it is fully initialized - except interceptors would not be executed is any outcalls occur in an ORBInitializer). The BIGGER problem is: 2. The ORB is PIDL so cannot be given to interceptor local interfaces. There has been much talk in the past on how to solve the ORB/PIDL problem. I think the consensus was to define a new ORB local interface and deprecate the existing ORB/PIDL. You would still do ORB.init and then obtain the local interface ORB via resolve_initial_references. Or something like that. If someone is willing to deal with the ORB/PIDL problem then we can subsequently deal with PI issues 3322, 3403, 3429. Otherwise those issues should be closed no change. Also, it would be good to have use cases for issues 3322, 3403, 3429 - particularly in the transaction and security areas. Cheers, Harold Date: Thu, 24 Oct 2002 17:46:53 -0400 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Issues 3772 and 3403 Discussion http://cgi.omg.org/issues/issue3772.txt talk about an ORB accessor on the POA interface http://cgi.omg.org/issues/issue3403.txt talk about PI needing access to ORB as an attribute. The discussion in both got terribly bogged down in PIDL vs. IDL philosophy, theology and other esoteric matters. Reading the vast archive, I get the impression that most of the pragmatic needs are adequately addressed by an "ORB" accessor to the Object pseudo-interface, and appears to cause relatively little upheaval all across the board. So should we take this on and do it? Or alternatively, should we simply punt? Of course, punting is the easiest of them all.:-) Thanks, Jishnu. Reply-To: "Michi Henning" From: "Michi Henning" To: "Jishnu Mukerji" , Subject: Re: Issues 3772 and 3403 Discussion Date: Fri, 25 Oct 2002 07:56:31 +1000 Organization: Triodia Technologies X-Mailer: Microsoft Outlook Express 6.00.2800.1106 > http://cgi.omg.org/issues/issue3772.txt talk about an ORB accessor on > the POA interface > > http://cgi.omg.org/issues/issue3403.txt talk about PI needing access to > ORB as an attribute. > > The discussion in both got terribly bogged down in PIDL vs. IDL > philosophy, theology and other esoteric matters. > > Reading the vast archive, I get the impression that most of the > pragmatic needs are adequately addressed by an "ORB" accessor to the > Object pseudo-interface, and appears to cause relatively little upheaval > all across the board. > > So should we take this on and do it? Or alternatively, should we simply > punt? Of course, punting is the easiest of them all.:-) Well, not surprisingly, I still believe that an ORB accessor would really be useful. Rather than putting the accessor on the POA or Object interfaces, I think a better place may be POA::Current. At any rate, an ORB accessor anywhere is better than none -- and I've been annoyed for years at the mess my code ends up as because of the inability to get at the ORB. The discussions about PIDL vs IDL are academic, IMO. There is no technical difficulty in providing access to the ORB. Cheers, Michi. -- Michi Henning Ph: +61 4 1118-2700 Triodia Technologies http://www.triodia.com/staff/michi From: Shahzad Aslam-mir To: "'Michi Henning'" , Jishnu Mukerji , corba-rtf@omg.org Subject: RE: Issues 3772 and 3403 Discussion Date: Thu, 24 Oct 2002 15:04:37 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Why not CORBA::Current ? or in my case RTCORBA::Current ? -----Original Message----- From: Michi Henning [mailto:michi@triodia.com] Sent: Thursday, October 24, 2002 2:57 PM To: Jishnu Mukerji; corba-rtf@omg.org Subject: Re: Issues 3772 and 3403 Discussion > http://cgi.omg.org/issues/issue3772.txt talk about an ORB accessor on > the POA interface > > http://cgi.omg.org/issues/issue3403.txt talk about PI needing access to > ORB as an attribute. > > The discussion in both got terribly bogged down in PIDL vs. IDL > philosophy, theology and other esoteric matters. > > Reading the vast archive, I get the impression that most of the > pragmatic needs are adequately addressed by an "ORB" accessor to the > Object pseudo-interface, and appears to cause relatively little upheaval > all across the board. > > So should we take this on and do it? Or alternatively, should we simply > punt? Of course, punting is the easiest of them all.:-) Well, not surprisingly, I still believe that an ORB accessor would really be useful. Rather than putting the accessor on the POA or Object interfaces, I think a better place may be POA::Current. At any rate, an ORB accessor anywhere is better than none -- and I've been annoyed for years at the mess my code ends up as because of the inability to get at the ORB. The discussions about PIDL vs IDL are academic, IMO. There is no technical difficulty in providing access to the ORB. Cheers, Michi. -- Michi Henning Ph: +61 4 1118-2700 Triodia Technologies http://www.triodia.com/staff/michi Sender: jbiggar@Resonate.com Date: Thu, 24 Oct 2002 15:49:38 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Issues 3772 and 3403 Discussion Jishnu Mukerji wrote: > > http://cgi.omg.org/issues/issue3772.txt talk about an ORB accessor on > the POA interface > > http://cgi.omg.org/issues/issue3403.txt talk about PI needing access to > ORB as an attribute. > > The discussion in both got terribly bogged down in PIDL vs. IDL > philosophy, theology and other esoteric matters. > > Reading the vast archive, I get the impression that most of the > pragmatic needs are adequately addressed by an "ORB" accessor to the > Object pseudo-interface, and appears to cause relatively little upheaval > all across the board. > > So should we take this on and do it? Or alternatively, should we simply > punt? Of course, punting is the easiest of them all.:-) I think putting an ORB accessor on Object is the best approach, but we need to deal with local objects. At least one local object must have no ORB associated with it (OrbInitializer), but if we don't have the ability to get the ORB from most local objects, the utility is greatly diminished. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 24 Oct 2002 22:05:19 +0000 From: Harold Carr X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en To: Michi Henning CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Issues 3793, 3772 and 3403 Discussion hello It would be good to have the ORB available from within interceptors, from within ORBInitializers (although timing good be a sticky point to agree on). That said, putting the accessor on POA::Current would not be too useful. Putting the accessor on the Object interface would probably be most applicable. One could resolve the name service in an initializer then get the ORB from its reference. I'm not sure about IORInterceptors right now, but that would need to be addressed too. Note I've included issue 3793 in this discussion since there would then be no need to add register_value_factory to ORBInitInfo. Cheers, Harold Michi Henning wrote: > > > http://cgi.omg.org/issues/issue3772.txt talk about an ORB accessor on > > the POA interface > > > > http://cgi.omg.org/issues/issue3403.txt talk about PI needing access to > > ORB as an attribute. > > > > The discussion in both got terribly bogged down in PIDL vs. IDL > > philosophy, theology and other esoteric matters. > > > > Reading the vast archive, I get the impression that most of the > > pragmatic needs are adequately addressed by an "ORB" accessor to the > > Object pseudo-interface, and appears to cause relatively little upheaval > > all across the board. > > > > So should we take this on and do it? Or alternatively, should we simply > > punt? Of course, punting is the easiest of them all.:-) > > Well, not surprisingly, I still believe that an ORB accessor would really be > useful. Rather than putting the accessor on the POA or Object interfaces, > I think a better place may be POA::Current. At any rate, an ORB accessor > anywhere is better than none -- and I've been annoyed for years at the > mess my code ends up as because of the inability to get at the ORB. > > The discussions about PIDL vs IDL are academic, IMO. There is no > technical difficulty in providing access to the ORB. > > Cheers, > > Michi. > > -- > Michi Henning Ph: +61 4 1118-2700 > Triodia Technologies http://www.triodia.com/staff/michi Date: Mon, 28 Oct 2002 16:29:17 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Re: Issues 3793, 3772 and 3403 Discussion Harold Carr wrote: > > hello > > It would be good to have the ORB available from within interceptors, > from within ORBInitializers (although timing good be a sticky point to > agree on). That said, putting the accessor on POA::Current would not be > too useful. Putting the accessor on the Object interface would probably > be most applicable. One could resolve the name service in an > initializer then get the ORB from its reference. I'm not sure about > IORInterceptors right now, but that would need to be addressed too. > > Note I've included issue 3793 in this discussion since there would then > be no need to add register_value_factory to ORBInitInfo. So does someone want to take a crack at proposing some concrete text changes for this? Or do we have to wait until either Jon or I can make time?:-) Please use formal/-2-06-01 as the base document for all proposals. Thanks, Jishnu. Date: Mon, 28 Oct 2002 16:52:04 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Shahzad Aslam-mir Cc: "'Michi Henning'" , corba-rtf@omg.org Subject: Re: Issues 3772 and 3403 Discussion Shahzad Aslam-mir wrote: > > Why not CORBA::Current ? or in my case RTCORBA::Current ? 'Cause they are not PIDL? Jishnu. Sender: jon@floorboard.com Date: Wed, 13 Nov 2002 18:56:28 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: corba-rtf@omg.org Subject: Re: Discussion of Resolution of issues 3403, 3772, 3793 and 3322 Jishnu Mukerji wrote: > > OK, now for the tough one. Here is a rough outline upon which to build > the resolution that fixes all of those ORB accessor related issue, i.e. > issues 3403, 3772, 3793 and 3322. > > I need help in nailing down the changes in the Portable Interceptor > chapter. The POA Chapter changes should be pretty straightforward. > Basically any help in completing items 4, 5 and 6 below would be most > appreciated. What else do we need to tweak? Comments inline. > ________________________________________________________________________ > Resolution: Access to ORB is to be provided by adding an ORB accessor > operation to the Object interface. This has the virtue of keeping the > PIDL-ness of the ORB contained by the PIDL-ness of the Object interface, > and yet allows straightforward way of providing access to the ORB from > any object local or otherwise. > > Since both PI and POA are local interfaces, this automatically provides > a means of accessing the ORB from these, and consequently also provides > a means for getting access to all ORB operations from these local > objects and hence addresses the concerns raised in issues 3403, 3793 and > 3322. So all these issues should be resolved in a single block and > closed simultaneously with this issue. > > This resolution will require the definition f language mapping of the > new extended Object interface. The resolution of this issue shall be > conditional upon the availability of at least one language mapping for > the extended Object interface. > > Revised Text: In formal/02-06-01 make the following changes: > > 1. In the IDL for interface Object at its end on page 4-14 immediately > following the line that reads: > > "Object get_component ();" > > insert the following line of IDL: > > "ORB get_ORB();" OK. > 2. Insert the following section immediately following section 4.3.12, > and bu,ping the following section numbers up by one: > > "4.3.13 Getting the ORB > > ORB get_ORB(); > > This operation returns the local ORB that is handling this particular > Object Reference. For certain local objects this operation returns an > ORB as documented in section 4.3.14. For the rest it returns > OBJECT_NOT_EXIST with standard minor code X1." Should we assume that the default for local objects is that they *have* an ORB or that they *do not have* an ORB? Or do we need to check specifically on a case by case basis? Or perhaps the best way is by rule: local objects that are explicitly created in user code have no ORB associated with them, local objects created by the ORB implementation *do* have an ORB associated with them. I think this gets the answer right for the PortableServer and PortableInterceptor local objects. It also has an added bonus that existing language binding mechanisms for creating local objects won't become obsolete. > 3. In old section 4.3.13 "LocalObject" in the bullet list under the > second bullet add the line: > > " o get_ORB - returns the ORB as documented for certain specific > local objects, and for the rest returns the system exception > OBJECT_NOT_EXIST with standard minor code X1." > > 4. In appendix section A.5 add a new minor code X1 to OBJECT_NOT_EXIST > which says "There is no meaningful association of an ORB with this local > object." > > 5. In the POA Chapter document the fact that the get_ORB operation for > the POA returns the ORB that the POA is associated with. And all other local objects in PortableServer except for AdapterActivator, ServantManager, ServantActivator and ServantLocator. > 6. In the Portable Interceptor chapter document the fact that the > get_ORB operation associated with any Interceptor returns the ORB that > the interceptor is managed by. Not quite. There will be no ORB associated with the *Interceptor, PolicyFactory, or ORBInitializer interfaces. There can be an ORB associated with all of the *Info and Current interfaces. > Specify which operations of the ORB are > available for use at what time using this reference that is returned > in > a PI. This is the sticky one. > 7. Specify any other changes that need to be made in Chapter 21 Portable > Interceptors to integrate the ORB returned from the Portable > Interceptor interface. > > Actions taken: Resolve and close this issue simultaneously with 3403, > 3793 and 3322 subject to the availability of at least one language > mapping for the new accessor operation. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 13 Nov 2002 18:08:11 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Discussion of Resolution of issues 3403, 3772, 3793 and 3322 OK, now for the tough one. Here is a rough outline upon which to build the resolution that fixes all of those ORB accessor related issue, i.e. issues 3403, 3772, 3793 and 3322. I need help in nailing down the changes in the Portable Interceptor chapter. The POA Chapter changes should be pretty straightforward. Basically any help in completing items 4, 5 and 6 below would be most appreciated. What else do we need to tweak? Thanks, Jishnu. ________________________________________________________________________ Resolution: Access to ORB is to be provided by adding an ORB accessor operation to the Object interface. This has the virtue of keeping the PIDL-ness of the ORB contained by the PIDL-ness of the Object interface, and yet allows straightforward way of providing access to the ORB from any object local or otherwise. Since both PI and POA are local interfaces, this automatically provides a means of accessing the ORB from these, and consequently also provides a means for getting access to all ORB operations from these local objects and hence addresses the concerns raised in issues 3403, 3793 and 3322. So all these issues should be resolved in a single block and closed simultaneously with this issue. This resolution will require the definition f language mapping of the new extended Object interface. The resolution of this issue shall be conditional upon the availability of at least one language mapping for the extended Object interface. Revised Text: In formal/02-06-01 make the following changes: 1. In the IDL for interface Object at its end on page 4-14 immediately following the line that reads: "Object get_component ();" insert the following line of IDL: "ORB get_ORB();" 2. Insert the following section immediately following section 4.3.12, and bu,ping the following section numbers up by one: "4.3.13 Getting the ORB ORB get_ORB(); This operation returns the local ORB that is handling this particular Object Reference. For certain local objects this operation returns an ORB as documented in section 4.3.14. For the rest it returns OBJECT_NOT_EXIST with standard minor code X1." 3. In old section 4.3.13 "LocalObject" in the bullet list under the second bullet add the line: " o get_ORB - returns the ORB as documented for certain specific local objects, and for the rest returns the system exception OBJECT_NOT_EXIST with standard minor code X1." 4. In appendix section A.5 add a new minor code X1 to OBJECT_NOT_EXIST which says "There is no meaningful association of an ORB with this local object." 5. In the POA Chapter document the fact that the get_ORB operation for the POA returns the ORB that the POA is associated with. 6. In the Portable Interceptor chapter document the fact that the get_ORB operation associated with any Interceptor returns the ORB that the interceptor is managed by. Specify which operations of the ORB are available for use at what time using this reference that is returned in a PI. 7. Specify any other changes that need to be made in Chapter 21 Portable Interceptors to integrate the ORB returned from the Portable Interceptor interface. Actions taken: Resolve and close this issue simultaneously with 3403, 3793 and 3322 subject to the availability of at least one language mapping for the new accessor operation. Date: Thu, 14 Nov 2002 03:02:50 +0000 From: Harold Carr X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en To: Jonathan Biggar CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Discussion of Resolution of issues 3403, 3772, 3793 and 3322 > > Specify which operations of the ORB are > > available for use at what time using this reference that is > > returned in > > a PI. > > This is the sticky one. For *RequestInterceptors I'd be happy to just say all operations are available (of course, register_initial_reference is already NOT available on ORBInitInfo, so it's not that easy). I think it is harder for IORInterceptors since what they do comes earlier in the initialization process. H Sender: jon@floorboard.com Date: Wed, 13 Nov 2002 19:49:07 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: Harold Carr CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Discussion of Resolution of issues 3403, 3772, 3793 and 3322 Harold Carr wrote: > > > > Specify which operations of the ORB are > > > available for use at what time using this reference that is returned in > > > a PI. > > > > This is the sticky one. > > For *RequestInterceptors I'd be happy to just say all operations are > available (of course, register_initial_reference is already NOT > available on ORBInitInfo, so it's not that easy). > > I think it is harder for IORInterceptors since what they do comes > earlier in the initialization process. Not inevitably. I would expect a "normal" ORB implementation strategy to not create the RootPOA until the client asks for its reference, and I wouldn't expect the IORInterceptor to run until that time. That would seem to be after all ORBInitializer::pre_init calls are complete, no? And since Interceptors aren't formally installed into the ORB until after post_init is called, doesn't that mean that the first time that an IORInterceptor can run is *after* ORB_init returns? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 13 Nov 2002 21:21:14 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Discussion of Resolution of issues 3403, 3772, 3793 and 3322 To: jishnu@hp.com, jon@floorboard.com Cc: corba-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >From: Jonathan Biggar >X-Accept-Language: en >MIME-Version: 1.0 >To: Jishnu Mukerji >CC: corba-rtf@omg.org >Subject: Re: Discussion of Resolution of issues 3403, 3772, 3793 and >3322 >Content-Transfer-Encoding: 7bit > > >> 2. Insert the following section immediately following section 4.3.12, >> and bu,ping the following section numbers up by one: >> >> "4.3.13 Getting the ORB >> >> ORB get_ORB(); >> >> This operation returns the local ORB that is handling this particular >> Object Reference. For certain local objects this operation returns an >> ORB as documented in section 4.3.14. For the rest it returns >> OBJECT_NOT_EXIST with standard minor code X1." > >Should we assume that the default for local objects is that they *have* >an ORB or that they *do not have* an ORB? Or do we need to check >specifically on a case by case basis? > >Or perhaps the best way is by rule: local objects that are explicitly >created in user code have no ORB associated with them, local objects >created by the ORB implementation *do* have an ORB associated with >them. I think this gets the answer right for the PortableServer and >PortableInterceptor local objects. It also has an added bonus that >existing language binding mechanisms for creating local objects won't >become obsolete. > I would rather not create two different classes of local interface implementations, with one for ordinary users and one for ORB implementors. Instead, I would rather extend the mapping to provide a creation model for local interfaces that supports assigning an ORB to a local object if desired. This can be done quite easily in Java by adding an extra constructor to the generated LocalBase class that takes an ORB as an argument (or we could add a set_ORB method to the base class in the Java mapping). In any case, we will handle that in the Java RTF, but I do not want to create two different models for how local objects are created. We will still need to say which local objects support get_ORB() for all of the local objects. Ken. Date: Thu, 14 Nov 2002 17:08:58 +0000 From: Harold Carr X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en To: Jonathan Biggar CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Discussion of Resolution of issues 3403, 3772, 3793 and 3322 Hello Jonathan, > > For *RequestInterceptors I'd be happy to just say all operations are > > available (of course, register_initial_reference is already NOT > > available on ORBInitInfo, so it's not that easy). > > > > I think it is harder for IORInterceptors since what they do comes > > earlier in the initialization process. > > Not inevitably. I would expect a "normal" ORB implementation strategy > to not create the RootPOA until the client asks for its reference, and I Agreed - that's the way we do it... > wouldn't expect the IORInterceptor to run until that time. That would > seem to be after all ORBInitializer::pre_init calls are complete, no? Originally what I was thinking was that the java to idl mapping has a "full value descriptor" which has an object listening to help with unmarshaling if needed. I was thinking that perhaps that object needed to be created during initialization and thus would need a POA. But the spec doesn't say how that object is implemented - therefore an implementation is free to use a proprietary adapter - thus no need to run IORInterceptors. > > And since Interceptors aren't formally installed into the ORB until > after post_init is called, doesn't that mean that the first time > that an > IORInterceptor can run is *after* ORB_init returns? Yes, that is true. I stand corrected. Thanks, Harold Date: Wed, 27 Nov 2002 13:28:53 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: CORBA Core RTF Subject: Discussion of sense of RTF issues so far So far we have voted on 4 sense of RTF issues. Here is a little update on what follows from those: 1. R1: Issues dealing with making ORB available to POA, PIs and Access to ValueFactory from PI. related issues: Issue 3403: PI needs the ORB to be available in IDL (Interceptors) Issue 3772: ORB accessor on POA? Issue 3793: No way to register value factory from ORB initializer (Interceptors) and also 3322. Status: We have been slowly putting together a concrete resolution. It is almost ready to go and should appear in vote 10 or 11. 2. R2 Regarding how to resolve issue 2772 Related Issue 2772 Status: It looks like the general feeling was that 2772 should be fixed as suggested in R2. We are awaiting a concrete draft resolution from Jon Biggar. As soon as it is available we will put it to vote. 3. R3: On the matter of how to resolve Issue 3097. Status: There is considerable reluctance on part of the voters to create a new version of GIOP to solve this problem, even though R3 did pass by a thin margin. But the fact that No's + Abstains outnumber Yesses by a significant margin should give us significant pause before we proceed down the path proposed in R3. We need to decide how to handle this one. Choices are leave it open (least desirable) or close with documentation of the problem in the specification. 4. R4: On the matter of how to resolve Issue 4169. Status: This one passed decisively. Jon had some objections that can probably be mitigated with some thought. It is upto Harold to come up with a complete draft resolution for this, in consultation with Jon. As soon as the draft is available we will put it to vote.