Issue 3642: Affects of INS on Interceptors - resolve_initial_references (interceptors-rtf) Source: International Business Machines (Mr. Russell Butek, ) Nature: Uncategorized Issue Severity: Summary: This is an interceptor issue, but it is related to the INS work. The interceptor spec (ptc/2000-04-05) adds register_initial_reference to the ORB interface (section 21.8, page 21-46). The Interoperable Naming Service spec (ptc/99-12-03) adds arguments to ORB_init: -ORBInitRef and -ORBDefaultInitRef (section 4.8, page 4-44). Both affect resolve_initial_references. They do not look mutually exclusive. If they are not, then all that has to be decided is the resolution order. The INS spec says: -------------------- 4.8.4.1 Default Resolution Order The default order for processing a call to CORBA::ORB::resolve_initial_references for a given <ObjectID> is: 1. Resolve with -ORBInitRef for this <ObjectID> if possible 2. Resolve with an -ORBDefaultInitRef entry if possible 3. Resolve with pre-configured ORB settings. ------------------- Where would objects added with register_initial_references fit in this list? 0? 2.5? Consider that register_initial_reference can be called after ORB_init AND during ORB_init in the ORB Initializers (section 21.7, page 21-40). I don't know if that makes a difference, but keep it in mind. Resolution: Place the register_initial_reference entry in the resolution order list at point 2.5. Revised Text: Change document #ptc/2000-04-05, page 4-25, section titled "Default Resolution Order" from: The default order for processing a call to CORBA::ORB::resolve_initial_references for a given <ObjectID> is: 1. Resolve with -ORBInitRef for this <ObjectID> if possible 2. Resolve with an -ORBDefaultInitRef entry if possible 3. Resolve with pre-configured ORB settings. to: The default order for processing a call to CORBA::ORB::resolve_initial_references for a given <ObjectID> is: 1. Resolve with -ORBInitRef for this <ObjectID> if possible 2. Resolve with an -ORBDefaultInitRef entry if possible 3. Resolve with a register_initial_reference entry if possible 4. Resolve with pre-configured ORB settings. Actions taken: May 24, 2000: received issue October 17, 2000: Incorporate change and close issue. However, this is modified b January 9, 2001: closed issue Discussion: End of Annotations:===== From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA09070; Wed, 24 May 2000 11:59:36 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id MAA76338; Wed, 24 May 2000 12:19:44 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E9.0059B058 ; Wed, 24 May 2000 12:19:38 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org, issues@omg.org, naming_ftf@omg.org Message-ID: <852568E9.0059AE88.00@d54mta04.raleigh.ibm.com> Date: Wed, 24 May 2000 12:19:31 -0400 Subject: Affects of INS on Interceptors - resolve_initial_references Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 1Qg!!K9m!!)e"e9`Uhd9 This is an interceptor issue, but it is related to the INS work. The interceptor spec (ptc/2000-04-05) adds register_initial_reference to the ORB interface (section 21.8, page 21-46). The Interoperable Naming Service spec (ptc/99-12-03) adds arguments to ORB_init: -ORBInitRef and -ORBDefaultInitRef (section 4.8, page 4-44). Both affect resolve_initial_references. They do not look mutually exclusive. If they are not, then all that has to be decided is the resolution order. The INS spec says: -------------------- 4.8.4.1 Default Resolution Order The default order for processing a call to CORBA::ORB::resolve_initial_references for a given is: 1. Resolve with -ORBInitRef for this if possible 2. Resolve with an -ORBDefaultInitRef entry if possible 3. Resolve with pre-configured ORB settings. ------------------- Where would objects added with register_initial_references fit in this list? 0? 2.5? Consider that register_initial_reference can be called after ORB_init AND during ORB_init in the ORB Initializers (section 21.7, page 21-40). I don't know if that makes a difference, but keep it in mind. Russell Butek butek@us.ibm.com From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA27014; Fri, 2 Jun 2000 09:27:56 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id JAA24228; Fri, 2 Jun 2000 09:47:42 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568F2.004BC68B ; Fri, 2 Jun 2000 09:47:40 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org, naming_ftf@omg.org Message-ID: <852568F2.004BC466.00@d54mta04.raleigh.ibm.com> Date: Fri, 2 Jun 2000 09:47:32 -0400 Subject: Issue 3642 proposal Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: `7Ee9",h!!Lf#e9cY;!! Assuming no-one has an objection to the interceptor's ORB.register_initial_references coexisting with INS's -ORBInitRef and -ORBDefaultInitRef, I propose that the default resolution order presented on page 4-44 of the INS spec be modified from: 4.8.4.1 Default Resolution Order The default order for processing a call to CORBA::ORB::resolve_initial_references for a given is: 1. Resolve with -ORBInitRef for this if possible 2. Resolve with an -ORBDefaultInitRef entry if possible 3. Resolve with pre-configured ORB settings. to: 4.8.4.1 Default Resolution Order The default order for processing a call to CORBA::ORB::resolve_initial_references for a given is: 1. Resolve with -ORBInitRef for this if possible 2. Resolve with an -ORBDefaultInitRef entry if possible 3. Resolve with a register_initial_reference entry if possible 4. Resolve with pre-configured ORB settings. Russell Butek butek@us.ibm.com Reply-To: From: "Nick Sharman" To: , Subject: RE: Issue 3642 proposal Date: Fri, 2 Jun 2000 15:25:31 +0100 Message-ID: <005501bfcc9e$68894970$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <852568F2.004BC466.00@d54mta04.raleigh.ibm.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: dc>!!d]^!!V&Yd90_Me9 Russell, I agree. Regards Nick > -----Original Message----- > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Sent: Friday, June 02, 2000 2:48 PM > To: interceptors-ftf@omg.org; naming_ftf@omg.org > Subject: Issue 3642 proposal > > > > > Assuming no-one has an objection to the interceptor's > ORB.register_initial_references coexisting with INS's -ORBInitRef and > -ORBDefaultInitRef, I propose that the default resolution order presented > on page 4-44 of the INS spec be modified from: > > 4.8.4.1 Default Resolution Order > > The default order for processing a call to > CORBA::ORB::resolve_initial_references for a given is: > 1. Resolve with -ORBInitRef for this if possible > 2. Resolve with an -ORBDefaultInitRef entry if possible > 3. Resolve with pre-configured ORB settings. > > to: > > 4.8.4.1 Default Resolution Order > > The default order for processing a call to > CORBA::ORB::resolve_initial_references for a given is: > 1. Resolve with -ORBInitRef for this if possible > 2. Resolve with an -ORBDefaultInitRef entry if possible > 3. Resolve with a register_initial_reference entry if possible > 4. Resolve with pre-configured ORB settings. > > Russell Butek > butek@us.ibm.com > > > Date: Mon, 19 Jun 2000 17:30:09 -0230 From: Matthew Newhook To: issues@omg.org Cc: interceptors-ftf@omg.org Subject: resolution order (resolution to issue 3642) Message-ID: <20000619173009.A9737@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us Content-Type: text/plain; charset=us-ascii X-UIDL: &b(e9+^Od9=Eid9>f:!! Hi, The resolution to issue #3642 is as follows: 4.8.4.1 Default Resolution Order The default order for processing a call to CORBA::ORB::resolve_initial_references for a given is: 1. Resolve with -ORBInitRef for this if possible 2. Resolve with an -ORBDefaultInitRef entry if possible 3. Resolve with a register_initial_reference entry if possible 4. Resolve with pre-configured ORB settings. This resolution makes no sense. The -ORBDefaultInitRef parameter cannot override register_initial_reference and pre-configured settings since it is a default parameter in itself. The way in which -ORBDefaultInitRef works is that the initial reference is constructed using the partial URL style IOR. So if the default init ref is: corbaloc::myhost.com:10000 and the initial reference object-id is "foo" then the created initial reference for "foo" would be corbaloc::myhost.com:10000/foo Since this mechanism is aimed at creating "default" or fallback initial references it must be the last fallback in any resolution order. Consider, for instance, the OTS which will need to register an OTS Current. Since this is a local reference the OTS implementation will need to register an initial reference using register_initial_reference. In addition, assume that the user specified a default initial reference as above (corbaloc::myhost.com:10000). The order as defined in the resolution says that the initial reference for OTSCurrent is corbaloc::myhost.com:10000/OTSCurrent Which is clearly wrong. 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, 20 Jun 2000 10:00:28 -0230 From: Matthew Newhook To: issues@omg.org, interceptors-ftf@omg.org Subject: Re: resolution order (resolution to issue 3642) Message-ID: <20000620100028.F13408@ooc.com> References: <20000619173009.A9737@ooc.com> <20000620103407.B23805@ooc.com.au> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <20000620103407.B23805@ooc.com.au> Content-Type: text/plain; charset=us-ascii X-UIDL: [;#"!)~F!!$T7!!~p`d9 Hi, On Tue, Jun 20, 2000 at 10:34:08AM +1000, Ted McFadden wrote: >[...] > I agree that the the suggested resolution order is problematic. > > register_initial_reference is not exactly a clean fit in with the > `bootstrapping' intentions of ORBInitRef and ORBDefaultInitRef. > > The INS spec did add a paragraph to the core chapter 4 (?), > "ORB Configured Resolution Order" that states an ORB is free to > ignore ORBDefaultInitRef, but not ORBInitRef, for those > references that it makes no sense for. > > Locality constrained objects should fall into this category, however > unless the ORB has a list of the local/special ObjectIDs this won't > help much. > > Given this, register_initial_reference should be first in the > resolution list. > > This would be a problem for an application that does something > like: > register_initial_reference("NameService", myNameService); > > to register a basic service such as naming or trader, but I'm not > sure I have a lot of sympathy for something coded like that. I also think that ORB pre-configured items have to come before ORBDefaultInitRef. Since that is meant to signify a fallback and is a partial IOR that is completed by the resolve initial reference object-id is must be last. Otherwise, how does it work? Having the ORB call _non_existent or something like that on the constructed IOR is not an option. > Cheers, > -- > Ted McFadden tmcf@ooc.com.au > Object Oriented Concepts http://www.ooc.com > Suite 4 904 Stanley St. +61-7-3891-5744 > East Brisbane 4169, QLD. Australia 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, 20 Jun 2000 10:34:08 +1000 From: Ted McFadden To: Matthew Newhook Cc: issues@omg.org, interceptors-ftf@omg.org Subject: Re: resolution order (resolution to issue 3642) Message-ID: <20000620103407.B23805@ooc.com.au> Mail-Followup-To: Matthew Newhook , issues@omg.org, interceptors-ftf@omg.org References: <20000619173009.A9737@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0i In-Reply-To: <20000619173009.A9737@ooc.com>; from matthew@ooc.com on Mon, Jun 19, 2000 at 05:30:09PM -0230 Content-Type: text/plain; charset=us-ascii X-UIDL: 1d1!!2e'!!N^Ce9cMR!! On Mon, Jun 19, 2000 at 05:30:09PM -0230, Matthew Newhook wrote: > Hi, > > The resolution to issue #3642 is as follows: > > 4.8.4.1 Default Resolution Order > > The default order for processing a call to > CORBA::ORB::resolve_initial_references for a given is: > 1. Resolve with -ORBInitRef for this if possible > 2. Resolve with an -ORBDefaultInitRef entry if possible > 3. Resolve with a register_initial_reference entry if possible > 4. Resolve with pre-configured ORB settings. > > > This resolution makes no sense. The -ORBDefaultInitRef parameter cannot > override register_initial_reference and pre-configured settings since it > is a default parameter in itself. > > The way in which -ORBDefaultInitRef works is that the initial reference > is constructed using the partial URL style IOR. So if the default init > ref is: > > corbaloc::myhost.com:10000 > > and the initial reference object-id is "foo" then the created initial > reference for "foo" would be > > corbaloc::myhost.com:10000/foo > > Since this mechanism is aimed at creating "default" or fallback initial > references it must be the last fallback in any resolution order. > > Consider, for instance, the OTS which will need to register an OTS > Current. Since this is a local reference the OTS implementation will > need to register an initial reference using register_initial_reference. > In addition, assume that the user specified a default initial reference > as above (corbaloc::myhost.com:10000). > > The order as defined in the resolution says that the initial reference > for OTSCurrent is > > corbaloc::myhost.com:10000/OTSCurrent > > Which is clearly wrong. I agree that the the suggested resolution order is problematic. register_initial_reference is not exactly a clean fit in with the `bootstrapping' intentions of ORBInitRef and ORBDefaultInitRef. The INS spec did add a paragraph to the core chapter 4 (?), "ORB Configured Resolution Order" that states an ORB is free to ignore ORBDefaultInitRef, but not ORBInitRef, for those references that it makes no sense for. Locality constrained objects should fall into this category, however unless the ORB has a list of the local/special ObjectIDs this won't help much. Given this, register_initial_reference should be first in the resolution list. This would be a problem for an application that does something like: register_initial_reference("NameService", myNameService); to register a basic service such as naming or trader, but I'm not sure I have a lot of sympathy for something coded like that. Cheers, Ted. > > 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 -- Ted McFadden tmcf@ooc.com.au Object Oriented Concepts http://www.ooc.com Suite 4 904 Stanley St. +61-7-3891-5744 East Brisbane 4169, QLD. Australia From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA16228 for ; Fri, 16 Jun 2000 08:46:37 -0500 Received: from d54mta02.raleigh.ibm.com (d54mta02.raleigh.ibm.com [9.67.228.34]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id JAA34922 for ; Fri, 16 Jun 2000 09:07:37 -0400 Received: by d54mta02.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256900.00481ADF ; Fri, 16 Jun 2000 09:07:34 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <85256900.00481436.00@d54mta02.raleigh.ibm.com> Date: Sat, 17 Jun 2000 19:33:05 +0100 Subject: Re: Interceptors Vote 3 reminder Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 6d&e9@',!!8DY!!mYA!! Matthew, Your "no" vote is in the minority, but I'll still try to explain why the order is what it is. -ORBDefaultInitRef is a command-line argument. In many systems command line arguments tend to take precedence over programmatic state. Since register_initial_reference is a programmatic state, it falls below -ORBDefaultInitRef. I see your point that, given the name of the parameter, it seems like it should be lower, but by virtue of being a command line argument, it has been placed where it is. Russell Butek butek@us.ibm.com Matthew Newhook on 06/14/2000 09:38:58 PM To: Russell Butek/Austin/IBM@IBMUS cc: interceptors-ftf@omg.org Subject: Re: Interceptors Vote 3 reminder Hi Russell, I'm confused by the text of 3642. -ORBDefaultInitRef is #2? That cannot be right... This should be a fallback if none of the others produce a match. I'm pretty sure that it should be last. OOC votes no on 3642, yes on all other issues. Matthew On Thu, Jun 15, 2000 at 06:53:30PM +0100, butek@us.ibm.com wrote: > > > Just a reminder. The interceptor FTF 3rd vote closes Thursday, June 15, at > noon, Oslo time (GMT+1). If you're a voter and are here in Oslo, you can > cast your ballot at the FTF meeting. Otherwise please email your ballot by > the deadline. > > http://www.omg.org/pub/interceptors_ftf/votes/interceptorsftfvote3.htm > > Russell Butek > butek@us.ibm.com > -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725