Issue 3640: target_is_a wrong? (interceptors-rtf) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: The current spec says that target_is_a may be invoked from send_rely, send_exception, and send_other. This appears to be impossible because these interception points run after postinvoke(), but once postinvoke() was called, the servant may no longer exist (because it is legal to call "delete servant" in postinvoke()). So, it appears that target_is_a cannot be available in these places. Resolution: Incorporate change and close issue. Revised Text: In table 21-2 ServerRequestInfo Validity, on page 21-28 of ptc/2000-04-05, change the rows for target_most_derived_interface and target_is_a. Also add a new footnote. Revised Text: Table for those rows change to (with footnote 4): receive_request_ service_contexts receive_request send_reply send_exception send_other 4 4 4 no yes no no no and the new footnote is: The operation is not available in this interception point because the necessary information requires access to the target object's servant, which may no longer be available to the ORB. For example, if the object's adapter is a POA that uses a ServantLocator, then the ORB invokes the interception point after it calls ServantLocator::postinvoke(). Actions taken: May 23, 2000: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== Date: Wed, 24 May 2000 09:11:22 +1000 (EST) From: Michi Henning Reply-To: interceptors-ftf@omg.org To: interceptors-ftf@omg.org cc: issues@omg.org Subject: target_is_a wrong? Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: P'0e9kY`d9,&:!!Sc?!! The current spec says that target_is_a may be invoked from send_rely, send_exception, and send_other. This appears to be impossible because these interception points run after postinvoke(), but once postinvoke() was called, the servant may no longer exist (because it is legal to call "delete servant" in postinvoke()). So, it appears that target_is_a cannot be available in these places. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: butek@us.ibm.com 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 JAA15138 for ; Wed, 24 May 2000 09:17:41 -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 JAA91674 for ; Wed, 24 May 2000 09:37:06 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E9.004ACD4D ; Wed, 24 May 2000 09:37:02 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568E9.004ACC88.00@d54mta04.raleigh.ibm.com> Date: Wed, 24 May 2000 09:36:57 -0400 Subject: Re: target_is_a wrong? Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: (%Me9"7bd9,]]!!?&E!! I can go along with that. If those points really needed to know what the servant is, then they can cache the info they get from receive_request. Russell Butek butek@us.ibm.com Michi Henning on 05/23/2000 06:11:22 PM Please respond to interceptors-ftf@omg.org To: interceptors-ftf@omg.org cc: issues@omg.org Subject: target_is_a wrong? The current spec says that target_is_a may be invoked from send_rely, send_exception, and send_other. This appears to be impossible because these interception points run after postinvoke(), but once postinvoke() was called, the servant may no longer exist (because it is legal to call "delete servant" in postinvoke()). So, it appears that target_is_a cannot be available in these places. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: butek@us.ibm.com Received: from e21.nc.us.ibm.com (e21.raleigh.ibm.com [9.37.2.58]) by admin.ny.us.ibm.com. (8.9.3/8.9.3) with ESMTP id IAA34078 for ; Mon, 5 Jun 2000 08:25:03 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA42486 for ; Mon, 5 Jun 2000 08:17:09 -0500 Received: from d54mta01.raleigh.ibm.com (d54mta01.raleigh.ibm.com [9.67.228.33]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id IAA25440 for ; Mon, 5 Jun 2000 08:26:42 -0400 Received: by d54mta01.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568F5.00445C22 ; Mon, 5 Jun 2000 08:26:40 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@emerald.omg.org Message-ID: <852568F5.00445AC3.00@d54mta01.raleigh.ibm.com> Date: Mon, 5 Jun 2000 08:26:35 -0400 Subject: Re: issue 3640 -- Interceptors FTF issue Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: Q_B!!f)+!!SdF!![9-!! Michi, While writing up a formal resolution for this issue, I came up with a possible alternate proposal. It is not impossible that target_is_a can be safely invoked from send_reply, send_exception, send_other as the issue states. An invocation of target_is_a may or may not work depending on whether delete_servant has been called. There is already a footnote in the table for send_exception and send_other: "3 If the servant locator caused a location forward, or raised an exception, this attribute/operation may not be available in this interception point. NO_RESOURCES with a standard minor code of 1 will be raised if it is not available." I propose the following: 1. Place footnote 3 on send_reply as well. 2. Change the text of the footnote to include the delete servant scenario: "3 If the servant locator caused a location forward, or raised an exception, or deleted the servant, this attribute/operation may not be available in this interception point. NO_RESOURCES with a standard minor code of 1 will be raised if it is not available." As I've said below, I believe this also applies to object_id, adapter_id, and target_most_derived_interface. What do you think? Russell Butek butek@us.ibm.com Russell Butek/Austin/IBM@IBMUS on 06/02/2000 08:24:33 AM > > Michi, > > Given that target_is_a should be unavailable in the send_XXX interception > points, would you also agree that object_id, adapter_id(?), > target_most_derived_interface should also be unavailable? > > Russell Butek > butek@us.ibm.com > > > Juergen Boldt on 05/25/2000 03:10:43 PM > > > > This is issue # 3640 > > > > target_is_a wrong? > > > > The current spec says that target_is_a may be invoked from send_rely, > > send_exception, and send_other. > > > > This appears to be impossible because these interception points run > > after postinvoke(), but once postinvoke() was called, the servant may > > no longer exist (because it is legal to call "delete servant" in > postinvoke()). > > > > So, it appears that target_is_a cannot be available in these places. > > > From: Paul Kyzivat To: interceptors-ftf@emerald.omg.org Subject: RE: issue 3640 -- Interceptors FTF issue Date: Mon, 5 Jun 2000 09:16:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: aX^d9V'7e9U7dd9(b0e9 Russell, Maybe I misunderstand, but I think there is a problem here. There is no way that the infrastructure supporting PI can know if a servant locator has deleted the servant in its postinvoke method. Therefore there is no way to inform interceptors of whether target_is_a is available in this situation. Paul > -----Original Message----- > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Sent: Monday, June 05, 2000 8:27 AM > To: interceptors-ftf@emerald.omg.org > Subject: Re: issue 3640 -- Interceptors FTF issue > > > > > Michi, > > While writing up a formal resolution for this issue, I came up with a > possible alternate proposal. > > It is not impossible that target_is_a can be safely invoked from > send_reply, send_exception, send_other as the issue states. > An invocation > of target_is_a may or may not work depending on whether > delete_servant has > been called. There is already a footnote in the table for > send_exception > and send_other: > > "3 If the servant locator caused a location forward, or raised an > exception, this attribute/operation > may not be available in this interception point. NO_RESOURCES with a > standard > minor code of 1 will be raised if it is not available." > > I propose the following: > > 1. Place footnote 3 on send_reply as well. > > 2. Change the text of the footnote to include the delete > servant scenario: > > "3 If the servant locator caused a location forward, or raised an > exception, or deleted > the servant, this attribute/operation may not be available in this > interception point. > NO_RESOURCES with a standard minor code of 1 will be raised > if it is not > available." > > As I've said below, I believe this also applies to object_id, > adapter_id, > and target_most_derived_interface. What do you think? > > Russell Butek > butek@us.ibm.com > > > Russell Butek/Austin/IBM@IBMUS on 06/02/2000 08:24:33 AM > > > > Michi, > > > > Given that target_is_a should be unavailable in the > send_XXX interception > > points, would you also agree that object_id, adapter_id(?), > > target_most_derived_interface should also be unavailable? > > > > Russell Butek > > butek@us.ibm.com > > > > > > Juergen Boldt on 05/25/2000 03:10:43 PM > > > > > > This is issue # 3640 > > > > > > target_is_a wrong? > > > > > > The current spec says that target_is_a may be invoked > from send_rely, > > > send_exception, and send_other. > > > > > > This appears to be impossible because these interception > points run > > > after postinvoke(), but once postinvoke() was called, the > servant may > > > no longer exist (because it is legal to call "delete servant" in > > postinvoke()). > > > > > > So, it appears that target_is_a cannot be available in > these places. > > > > > > > Date: Tue, 6 Jun 2000 07:27:50 +1000 (EST) From: Michi Henning To: butek@us.ibm.com cc: interceptors-ftf@emerald.omg.org Subject: Re: issue 3640 -- Interceptors FTF issue In-Reply-To: <852568F5.00445AC3.00@d54mta01.raleigh.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ?Sjd9n-Ce9O!l!!OM%e9 On Mon, 5 Jun 2000 butek@us.ibm.com wrote: > I propose the following: > > 1. Place footnote 3 on send_reply as well. > > 2. Change the text of the footnote to include the delete servant > scenario: > > "3 If the servant locator caused a location forward, or raised an > exception, or deleted > the servant, this attribute/operation may not be available in this > interception point. > NO_RESOURCES with a standard minor code of 1 will be raised if it is > not > available." > > As I've said below, I believe this also applies to object_id, > adapter_id, > and target_most_derived_interface. What do you think? How would the interceptor know (or the ORB) whether the servant is still there? As far as I can see, all you would end up with is a dangling pointer... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA16134 for ; Tue, 6 Jun 2000 08:48:26 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id JAA27656 for ; Tue, 6 Jun 2000 09:01:01 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568F6.0047785A ; Tue, 6 Jun 2000 09:00:38 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@emerald.omg.org Message-ID: <852568F6.00467AFC.00@d54mta03.raleigh.ibm.com> Date: Tue, 6 Jun 2000 08:49:49 -0400 Subject: Re: issue 3640 -- Interceptors FTF issue Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: _SM!!\g]d9[T/!!''Sd9 Michi Henning on 06/05/2000 04:27:50 PM > > On Mon, 5 Jun 2000 butek@us.ibm.com wrote: > > > I propose the following: > > > > 1. Place footnote 3 on send_reply as well. > > > > 2. Change the text of the footnote to include the delete servant scenario: > > > > "3 If the servant locator caused a location forward, or raised an > > exception, or deleted > > the servant, this attribute/operation may not be available in this > > interception point. > > NO_RESOURCES with a standard minor code of 1 will be raised if it is not > > available." > > > > As I've said below, I believe this also applies to object_id, adapter_id, > > and target_most_derived_interface. What do you think? > > How would the interceptor know (or the ORB) whether the servant is still > there? As far as I can see, all you would end up with is a dangling pointer... > Hmmmm... what a pity CORBA isn't more sophisticated than that. The is_nil function would be handy here. Oh, well... if I'm full of hot air then I agree with you, target_is_a should simply be disallowed in the send_XXX points. By your silence I assume agreement that object_id, adapter_id, and target_most_derived_interface should behave in the same manner as target_is_a. Russell Butek butek@us.ibm.com Date: Wed, 7 Jun 2000 09:22:05 +1000 (EST) From: Michi Henning To: butek@us.ibm.com cc: interceptors-ftf@emerald.omg.org Subject: Re: issue 3640 -- Interceptors FTF issue In-Reply-To: <852568F6.00467AFC.00@d54mta03.raleigh.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 'l)!!0BMe9eLg!!W],!! On Tue, 6 Jun 2000 butek@us.ibm.com wrote: > > How would the interceptor know (or the ORB) whether the servant is still > > there? As far as I can see, all you would end up with is a dangling > pointer... > > > > Hmmmm... what a pity CORBA isn't more sophisticated than that. The is_nil > function would be handy here. > > Oh, well... if I'm full of hot air then I agree with you, target_is_a > should simply be disallowed in the send_XXX points. > > By your silence I assume agreement that object_id, adapter_id, and > target_most_derived_interface should behave in the same manner as > target_is_a. target_is_a and target_most_derived_interface would have to be treated the same way because you need the servant for those. I think that object_id and adapter_id can still work, because the information returned by those is in the IOR. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA25482 for ; Wed, 7 Jun 2000 07:56:09 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id IAA30846 for ; Wed, 7 Jun 2000 08:08:44 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568F7.0042B724 ; Wed, 7 Jun 2000 08:08:42 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@emerald.omg.org Message-ID: <852568F7.0042AFB6.00@d54mta03.raleigh.ibm.com> Date: Wed, 7 Jun 2000 08:08:20 -0400 Subject: Re: issue 3640 -- Interceptors FTF issue Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: >J1e9ZAf!!6&Vd9Q"`d9 Michi Henning on 06/06/2000 06:22:05 PM > > On Tue, 6 Jun 2000 butek@us.ibm.com wrote: > > > > By your silence I assume agreement that object_id, adapter_id, and > > target_most_derived_interface should behave in the same manner as > > target_is_a. > > target_is_a and target_most_derived_interface would have to be treated > the same way because you need the servant for those. I think that object_id > and adapter_id can still work, because the information returned by those > is in the IOR. > adapter_id is in the IOR? I didn't think so. It certainly isn't specified to be. So you're saying the IOR is still available even if the target isn't? Isn't that an implementation detail that may not be true? It certainly isn't true in our ORB. 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 e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA16206 for ; Thu, 22 Jun 2000 08:28:03 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id IAA36096 for ; Thu, 22 Jun 2000 08:38:00 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256906.00456414 ; Thu, 22 Jun 2000 08:37:56 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <85256906.00456061.00@d54mta03.raleigh.ibm.com> Date: Thu, 22 Jun 2000 08:37:45 -0400 Subject: Re: issue 3640 -- Interceptors FTF issue Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: OV7!!AL'e97XLe9,1fd9 I'm resending this question because no-one responded. I can agree that object_id shouldn't be treated the same as target_is_a and target_most_derived_interface, but I still think adapter_id should be. Russell Butek butek@us.ibm.com ---------------------- Forwarded by Russell Butek/Austin/IBM on 06/22/2000 07:37 AM --------------------------- Russell Butek/Austin/IBM@IBMUS on 06/07/2000 07:08:20 AM To: interceptors-ftf@emerald.omg.org cc: Subject: Re: issue 3640 -- Interceptors FTF issue Michi Henning on 06/06/2000 06:22:05 PM > > On Tue, 6 Jun 2000 butek@us.ibm.com wrote: > > > > By your silence I assume agreement that object_id, adapter_id, and > > target_most_derived_interface should behave in the same manner as > > target_is_a. > > target_is_a and target_most_derived_interface would have to be treated > the same way because you need the servant for those. I think that object_id > and adapter_id can still work, because the information returned by those > is in the IOR. > adapter_id is in the IOR? I didn't think so. It certainly isn't specified to be. So you're saying the IOR is still available even if the target isn't? Isn't that an implementation detail that may not be true? It certainly isn't true in our ORB. Russell Butek butek@us.ibm.com Reply-To: From: "Nick Sharman" To: Subject: RE: issue 3640 -- Interceptors FTF issue Date: Thu, 22 Jun 2000 16:24:57 +0100 Message-ID: <000e01bfdc5e$05fa27a0$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <85256906.00456061.00@d54mta03.raleigh.ibm.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 6KK!!%`W!!4+Wd9\cD!! Russell, Object ids are only unique within an adapter- certainly for POAs, where ids can be user defined, and so I think both adapter id and object id are embedded (in an implementation-defined way) within the object_key of an IOR IIOP profile. Looking at it another way, the servant for an object is managed directly or indirectly by some adapter, so to find the object (from its object_id) you first have to find the adapter (using the adapter_id). Regards Nick > -----Original Message----- > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Sent: Thursday, June 22, 2000 1:38 PM > To: interceptors-ftf@omg.org > Subject: Re: issue 3640 -- Interceptors FTF issue > > > > > I'm resending this question because no-one responded. I can agree that > object_id shouldn't be treated the same as target_is_a and > target_most_derived_interface, but I still think adapter_id should be. > > Russell Butek > butek@us.ibm.com > > ---------------------- Forwarded by Russell Butek/Austin/IBM on 06/22/2000 > 07:37 AM --------------------------- > > > > Russell Butek/Austin/IBM@IBMUS on 06/07/2000 07:08:20 AM > > > To: interceptors-ftf@emerald.omg.org > cc: > > Subject: Re: issue 3640 -- Interceptors FTF issue > > > > > > > > > Michi Henning on 06/06/2000 06:22:05 PM > > > > On Tue, 6 Jun 2000 butek@us.ibm.com wrote: > > > > > > By your silence I assume agreement that object_id, adapter_id, and > > > target_most_derived_interface should behave in the same manner as > > > target_is_a. > > > > target_is_a and target_most_derived_interface would have to be treated > > the same way because you need the servant for those. I think that > object_id > > and adapter_id can still work, because the information returned by those > > is in the IOR. > > > > adapter_id is in the IOR? I didn't think so. It certainly isn't > specified > to be. > > So you're saying the IOR is still available even if the target isn't? > Isn't that an implementation detail that may not be true? It certainly > isn't true in our ORB. > > 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 e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA25616 for ; Mon, 26 Jun 2000 08:04:45 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id IAA29662 for ; Mon, 26 Jun 2000 08:26:05 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525690A.00444D94 ; Mon, 26 Jun 2000 08:26:03 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <8525690A.004449CD.00@d54mta03.raleigh.ibm.com> Date: Mon, 26 Jun 2000 08:25:46 -0400 Subject: Issue 3640 - target_is_a wrong? - resolution Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: n&Ae9+0L!!H6Vd9N@""! Here's a crack at the resolution for this issue: In table 21-2 ServerRequestInfo Validity, on page 21-28 of ptc/2000-04-05, change the rows for target_most_derived_interface and target_is_a to: receive_request_ service_contexts receive_request send_reply send_exception send_other no yes no no no Does anyone think we need a footnote explaining why it is no for the last 3? Russell Butek butek@us.ibm.com Reply-To: From: "Nick Sharman" To: Subject: RE: Issue 3640 - target_is_a wrong? - resolution Date: Mon, 26 Jun 2000 16:26:58 +0100 Message-ID: <000401bfdf82$f8191880$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: <8525690A.004449CD.00@d54mta03.raleigh.ibm.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Uk&!!_I4!!II]d9HCgd9 Russell, It wouldn't hurt - the issue summary is pretty close - and may save us or our successors having to deal with "why isn't target_is_a available in send_reply?" issues in future! I suggest: The operation is not available in this interception point because the necessary information requires access to the target object's servant, which may no longer be available to the ORB. For example, if the object's adapter is a POA that uses a ServantLocator, then the ORB invokes the interception point after it calls ServantLocator::postinvoke(). Regards Nick > -----Original Message----- > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Sent: Monday, June 26, 2000 1:26 PM > To: interceptors-ftf@omg.org > Subject: Issue 3640 - target_is_a wrong? - resolution > > > > > Here's a crack at the resolution for this issue: > > In table 21-2 ServerRequestInfo Validity, on page 21-28 of ptc/2000-04-05, > change the rows for target_most_derived_interface and target_is_a to: > > receive_request_ > service_contexts receive_request send_reply send_exception send_other > no yes no no no > > > Does anyone think we need a footnote explaining why it is no for the last > 3? > > 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 e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA46062 for ; Mon, 26 Jun 2000 15:32:45 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id PAA44728 for ; Mon, 26 Jun 2000 15:42:48 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525690A.006C480C ; Mon, 26 Jun 2000 15:42:43 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <8525690A.006BF7C9.00@d54mta03.raleigh.ibm.com> Date: Mon, 26 Jun 2000 15:39:15 -0400 Subject: RE: Issue 3640 - target_is_a wrong? - resolution Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: b?7e9ZKOe93M)!!7G:e9 "Nick Sharman" on 06/26/2000 10:26:58 AM > > It wouldn't hurt - the issue summary is pretty close - and may save us or > our successors having to deal with "why isn't target_is_a available in > send_reply?" issues in future! I suggest: > > The operation is not available in this interception point because the > necessary information requires access to the target object's servant, > which may no longer be available to the ORB. For example, if the > object's adapter is a POA that uses a ServantLocator, then the ORB > invokes the interception point after it calls > ServantLocator::postinvoke(). > Sounds good to me. This would become footnote #4 on this table. Russell Butek butek@us.ibm.com