Issue 643: return of invalid Servant as result of incarnate() or preinvoke() (port-rtf) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: Spec does not address case when ServantManager returns an invalid Servant to POA as result of an incarnate() or preinvoke() operation. Spec should be clarified Resolution: Accepted for Portability 2.3 RTF Revised Text: Revision: Page 9-34, 9.3.4 ServantManager Interface. Add a Actions taken: August 4, 1997: received issue July 30, 1998: closed issue Discussion: End of Annotations:===== Return-Path: Sender: jon@sems.com Date: Mon, 04 Aug 1997 14:06:48 -0700 From: Jonathan Biggar Organization: Seagate Software, Network & Storage Management Group To: port-rtf@omg.org, issues@omg.org Subject: Another portablility issue The spec does not address the case where a ServantManager (either ServantActivator or ServantLocator) returns an invalid Servant to the POA as the result of an incarnate() or preinvoke() operation. The servant could be invalid either because it is null (for C++ or C), or because it is the wrong type of static servant for the object reference. The spec should be clarified by stating that in this case, the OBJ_ADAPTER system exception will be returned to the invoker. Jon Biggar jon@sems.com Return-Path: From: "Daniel R. Frantz" To: Subject: Proposed resolutions for Issues 642 and 643 Date: Mon, 29 Jun 1998 17:49:19 -0400 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 There are some few enhancement issues that seem reasonable and easy to accommodate. Some are lacking the exact words. To make them more specific, I've drawn up the following wording changes. We can decide later whether we want the enhancements. I'll try to get more later. Dan ----------------- Issue 643: Return of invalid Servant as result of incarnate() or preinvoke(). Nature: Clarification Summary: Spec does not address case when ServantManager returns an invalid Servant to POA as result of an incarnate() or preinvoke() operation. The POA should return OBJ_ADAPTER. Resolution: Accepted for Portability 2.3 RTF Revision: Page 9-34, 9.3.4 ServantManager Interface. Add a paragraph just before the subsection "Locality Constraints": If a ServantManager returns an invalid Servant to the POA as the result of an incarnate() or preinvoke() operation, the POA will return the OBJ_ADAPTER system exception as the result of the request. A Servant can be invalid either because it is null (or the equivalent in a language mapping), or because it is the wrong type of static servant for the object reference. (The POA cannot determine correctness of a Servant for DSI.) Return-Path: Date: Tue, 30 Jun 1998 07:20:32 +0100 From: jhierro@jam.tid.es (Juan Jose Hierro Sureda) To: port-rtf@omg.org Subject: Re: Proposed resolutions for Issues 642 and 643 X-Sun-Charset: US-ASCII > > There are some few enhancement issues that seem reasonable and easy > to > accommodate. Some are lacking the exact words. To make them more > specific, I've drawn up the following wording changes. We can decide > later whether we want the enhancements. I'll try to get > more later. > > Dan > ======================================================== > I vote yes to adoption of the proposed resolutions: > > Issue 642: If the POAManager has no way to query its current > state, then the programmer may have to develop his own > parallel data structure to keep track of the current > state of the POAManager. Since the POAManager must > know its own state, there doesn't appear to be any > reason not to be able to query it. > Nature: Enhancement > Resolution: Accepted for Portability 2.3 RTF. > Revision: Page 9-19, Section 9.3.2 "POAManager Interface". Add > at end of section: > > get_state > > enum State { HOLDING, ACTIVE, DISCARDING, > INACTIVE }; > State get_state(); > > This operation returns the state of the POA > manager. > > Page 9-40, Section 9.4 "IDL for PortableServer > module". After the line "exception > AdapterInactive();", add the line > > enum State { HOLDING, ACTIVE, DISCARDING, > INACTIVE }; > > After the three lines of the deactivate operation add > the line: > > State get_state(); > > ----------------- > > Issue 643: Return of invalid Servant as result of incarnate() or > preinvoke(). > Nature: Clarification > Summary: Spec does not address case when ServantManager returns > an invalid Servant to POA as result of an incarnate() > or preinvoke() operation. The POA should return > OBJ_ADAPTER. > Resolution: Accepted for Portability 2.3 RTF > Revision: Page 9-34, 9.3.4 ServantManager Interface. Add a > paragraph just before the subsection "Locality > Constraints": > > If a ServantManager returns an invalid Servant to > the POA as the result of an incarnate() or > preinvoke() operation, the POA will return the > OBJ_ADAPTER system exception as the result of the > request. A Servant can be invalid either because > it is null (or the equivalent in a language > mapping), or because it is the wrong type of > static servant for the object reference. (The POA > cannot determine correctness of a Servant for > DSI.) > Return-Path: Date: Tue, 30 Jun 1998 18:45:39 -0400 From: Jonathan Biggar Organization: Floorboard Software To: "Daniel R. Frantz" CC: port-rtf@omg.org Subject: Re: Proposed resolutions for Issues 642 and 643 References: <005601bda3a7$c594a140$3fc5bdce@idler.beasys.com> I vote yes for the proposals for issues 642 & 643. Jon Daniel R. Frantz wrote: > There are some few enhancement issues that seem reasonable and easy > to > accommodate. Some are lacking the exact words. To make them more > specific, I've drawn up the following wording changes. We can decide > later whether we want the enhancements. I'll try to get > more later. > > Dan > ======================================================== > > > > Return-Path: Date: Mon, 06 Jul 1998 16:33:43 -0400 From: Bob Kukura Organization: IONA Technologies To: "Daniel R. Frantz" CC: port-rtf@omg.org Subject: Re: Proposed resolutions for Issues 642 and 643 References: <005601bda3a7$c594a140$3fc5bdce@idler.beasys.com> Daniel R. Frantz wrote: > > There are some few enhancement issues that seem reasonable and easy > to > accommodate. Some are lacking the exact words. To make them more > specific, I've drawn up the following wording changes. We can decide > later whether we want the enhancements. I'll try to get > more later. > > Dan > ======================================================== > > Issue 642: If the POAManager has no way to query its current > state, then the programmer may have to develop his own > parallel data structure to keep track of the current > state of the POAManager. Since the POAManager must > know its own state, there doesn't appear to be any > reason not to be able to query it. > Nature: Enhancement > Resolution: Accepted for Portability 2.3 RTF. > Revision: Page 9-19, Section 9.3.2 "POAManager Interface". Add > at end of section: > > get_state > > enum State { HOLDING, ACTIVE, DISCARDING, > INACTIVE }; > State get_state(); > > This operation returns the state of the POA > manager. > > Page 9-40, Section 9.4 "IDL for PortableServer > module". After the line "exception > AdapterInactive();", add the line > > enum State { HOLDING, ACTIVE, DISCARDING, > INACTIVE }; > > After the three lines of the deactivate operation add > the line: > > State get_state(); This looks good to me. > > ----------------- > > Issue 643: Return of invalid Servant as result of incarnate() or > preinvoke(). > Nature: Clarification > Summary: Spec does not address case when ServantManager returns > an invalid Servant to POA as result of an incarnate() > or preinvoke() operation. The POA should return > OBJ_ADAPTER. > Resolution: Accepted for Portability 2.3 RTF > Revision: Page 9-34, 9.3.4 ServantManager Interface. Add a > paragraph just before the subsection "Locality > Constraints": > > If a ServantManager returns an invalid Servant to > the POA as the result of an incarnate() or > preinvoke() operation, the POA will return the > OBJ_ADAPTER system exception as the result of the > request. A Servant can be invalid either because > it is null (or the equivalent in a language > mapping), or because it is the wrong type of > static servant for the object reference. (The POA > cannot determine correctness of a Servant for > DSI.) I don't think the POA should be required to do any special validation of the type of a static servant. Without this validation, if the ServantManager did return a servant of the wrong type, the client would most-likely recieve a BAD_OPERATION exception. But this proposal would require extra checking just to cause a different exception to be returned. The POA does not know whether a servant is static or dynamic, so it would probably just end up invoking _is_a() on all servants. This seems like extra work for the ORB that will impact performance, with little extra value to the user. OBJ_ADAPTER does seem like a resonable response if the servant is null. -Bob Return-Path: Sender: jon@floorboard.com Date: Tue, 07 Jul 1998 20:44:17 -0700 From: Jonathan Biggar To: Bob Kukura CC: "Daniel R. Frantz" , port-rtf@omg.org Subject: Re: Proposed resolutions for Issues 642 and 643 References: <005601bda3a7$c594a140$3fc5bdce@idler.beasys.com> <35A134A7.B9238923@iona.com> Bob Kukura wrote: > > ----------------- > > > > Issue 643: Return of invalid Servant as result of incarnate() or > > preinvoke(). > > Nature: Clarification > > Summary: Spec does not address case when ServantManager returns > > an invalid Servant to POA as result of an incarnate() > > or preinvoke() operation. The POA should return > > OBJ_ADAPTER. > > Resolution: Accepted for Portability 2.3 RTF > > Revision: Page 9-34, 9.3.4 ServantManager Interface. Add a > > paragraph just before the subsection "Locality > > Constraints": > > > > If a ServantManager returns an invalid Servant to > > the POA as the result of an incarnate() or > > preinvoke() operation, the POA will return the > > OBJ_ADAPTER system exception as the result of the > > request. A Servant can be invalid either because > > it is null (or the equivalent in a language > > mapping), or because it is the wrong type of > > static servant for the object reference. (The POA > > cannot determine correctness of a Servant for > > DSI.) > > I don't think the POA should be required to do any special > validation of > the type of a static servant. Without this validation, if the > ServantManager did return a servant of the wrong type, the client > would > most-likely recieve a BAD_OPERATION exception. But this proposal > would > require extra checking just to cause a different exception to be > returned. The POA does not know whether a servant is static or > dynamic, so it would probably just end up invoking _is_a() on all > servants. This seems like extra work for the ORB that will impact > performance, with little extra value to the user. OBJ_ADAPTER does > seem > like a resonable response if the servant is null. Are you proposing that we just leave this as undefined behavior? Hopefully we can at least explicitly say so in the text. Depending on the ORB now, you may get a BAD_OPERATION, or in some cases, particularly local dispatch, you may just get a core dump. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Wed, 08 Jul 1998 00:26:20 -0400 From: Bob Kukura Organization: IONA Technologies To: Jonathan Biggar CC: "Daniel R. Frantz" , port-rtf@omg.org Subject: Re: Proposed resolutions for Issues 642 and 643 References: <005601bda3a7$c594a140$3fc5bdce@idler.beasys.com> <35A134A7.B9238923@iona.com> <35A2EB11.FD83E37C@floorboard.com> Jonathan Biggar wrote: > > Bob Kukura wrote: > > > ----------------- > > > > > > Issue 643: Return of invalid Servant as result of incarnate() > or > > > preinvoke(). > > > Nature: Clarification > > > Summary: Spec does not address case when ServantManager > returns > > > an invalid Servant to POA as result of an > incarnate() > > > or preinvoke() operation. The POA should return > > > OBJ_ADAPTER. > > > Resolution: Accepted for Portability 2.3 RTF > > > Revision: Page 9-34, 9.3.4 ServantManager Interface. Add a > > > paragraph just before the subsection "Locality > > > Constraints": > > > > > > If a ServantManager returns an invalid Servant > to > > > the POA as the result of an incarnate() or > > > preinvoke() operation, the POA will return the > > > OBJ_ADAPTER system exception as the result of > the > > > request. A Servant can be invalid either > because > > > it is null (or the equivalent in a language > > > mapping), or because it is the wrong type of > > > static servant for the object reference. (The > POA > > > cannot determine correctness of a Servant for > > > DSI.) > > > > I don't think the POA should be required to do any special > validation of > > the type of a static servant. Without this validation, if the > > ServantManager did return a servant of the wrong type, the client > would > > most-likely recieve a BAD_OPERATION exception. But this proposal > would > > require extra checking just to cause a different exception to be > > returned. The POA does not know whether a servant is static or > > dynamic, so it would probably just end up invoking _is_a() on all > > servants. This seems like extra work for the ORB that will impact > > performance, with little extra value to the user. OBJ_ADAPTER > does seem > > like a resonable response if the servant is null. > > Are you proposing that we just leave this as undefined behavior? > Hopefully we can at least explicitly say so in the text. Depending > on > the ORB now, you may get a BAD_OPERATION, or in some cases, > particularly > local dispatch, you may just get a core dump. I think the behavior should be the same as if client (lets say DII client, so narrow() was avoided) and server disagree on the interface. I'm not sure its spelled out anywhere, but the implication of GIOP is that the server can't know what interface the client thought it was using. If the operation name isn't valid for the server's interface, the client gets BAD_OPERATION. If it is valid, but the signature is different, hopefully the client gets a MARSHAL exception, or maybe some other system exception. I don't think a core dump should be acceptable in any case, even for a colocated invocation. My point really is that, given that the client and server might disagree on the interface, checking the Servant's skeleton type and _primary_interface() implementation agree is not adding that much value. Remember that the server doesn't necessarily have a reference to the object sitting around, so its likely to have to call _primary_interface() to build one. Assuming client-server type mismatch handling isn't spelled out anywhere right now, I think it would suffice in the POA to say: If a ServantManager returns a nil Servant to the POA as the result of an incarnate() or preinvoke() operation, the POA will return the OBJ_ADAPTER system exception as the result of the request. If the ServantManager returns a Servant that does not implement the requested operation, the POA will return a system exception such as BAD_OPERATION or MARSHAL. If you want to be a bit more specific, we could say that "If the ServantManager does not implement an operation with the requested name, the POA will return a BAD_OPERATION system exception." But we'd still need to leave some leeway for the case where the names match but the signatures are somehow different. -Bob > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Return-Path: Sender: jon@floorboard.com Date: Wed, 08 Jul 1998 13:20:54 -0700 From: Jonathan Biggar To: "Daniel R. Frantz" , port-rtf@omg.org Subject: Re: Issues status 8-jul-98 10:00 am EDT (Correction) References: <000601bdaaa9$b710d310$3fc5bdce@idler.beasys.com> Daniel R. Frantz wrote: > > In the mail I sent earlier, the following was listed as an approved > resolution. > > >643: Return of invalid Servant as result of incarnate() or > > preinvoke() > >* Proposal: Clarification, 6/29. > > Yes: Frantz, Hierro, Biggar, Kukura, Fleming, Fox, > > Giddings > > Partial yes: Mukerji > > No: > > Recording Bob as Yes was incorrect. As it is, however, the vote is > still > Yes with quorum present. Sorry, Bob. > > Bob's vote is important since he's fairly strong against one part of > the > proposal. He'll try to convince us of the errors of our ways and we > should listen. It's still possible to change our minds and adopt a > different proposal. > > Bob, when you do send out further comments, send them to > port-rtf. I'm > using this list only for the purposes of keeping track of votes and > urging people to vote. Let me make a preemptory argument in favor of the proposal. If a ServantManager returns the wrong type of servant to support the reference, this is a serious server side bug. Since incoming GIOP requests have no reference type indication, it cannot be detected there, so the best the ORB can do is to return BAD_OPERATION if the operation is not supported by the servant, or MARSHAL if the operation name is supported, but the arguments are not correctly typed. The case is more interesting if the call is local, through a typed object reference. In this case, the ORB can detect that the servant is of the wrong type, and in fact must do the check if it to avoid a core dump. I think it is better to raise the OBJ_ADAPTER exception here, as a clearer indication that it is server side that screwed up, and not any fault of the client side. Frankly, I don't see any additional work on the ORB's part to detect this condition. Would it be better to change the proposal to state that any of the three exceptions: OBJ_ADAPTER, BAD_OPERATION, MARSHAL could be thrown, since it appears to depend on whether the call is local or not? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Wed, 08 Jul 1998 17:31:57 -0400 From: Bob Kukura Organization: IONA Technologies To: Jonathan Biggar CC: "Daniel R. Frantz" , port-rtf@omg.org Subject: Re: Issues status 8-jul-98 10:00 am EDT (Correction) References: <000601bdaaa9$b710d310$3fc5bdce@idler.beasys.com> <35A3D4A6.3F2803F0@floorboard.com> Jonathan Biggar wrote: > > Daniel R. Frantz wrote: > > > > In the mail I sent earlier, the following was listed as an > approved > > resolution. > > > > >643: Return of invalid Servant as result of incarnate() or > > > preinvoke() > > >* Proposal: Clarification, 6/29. > > > Yes: Frantz, Hierro, Biggar, Kukura, Fleming, Fox, > > > Giddings > > > Partial yes: Mukerji > > > No: > > > > Recording Bob as Yes was incorrect. As it is, however, the vote is > still > > Yes with quorum present. Sorry, Bob. > > > > Bob's vote is important since he's fairly strong against one part > of the > > proposal. He'll try to convince us of the errors of our ways and > we > > should listen. It's still possible to change our minds and adopt a > > different proposal. > > > > Bob, when you do send out further comments, send them to > port-rtf. I'm > > using this list only for the purposes of keeping track of votes > and > > urging people to vote. > > Let me make a preemptory argument in favor of the proposal. If a > ServantManager returns the wrong type of servant to support the > reference, this is a serious server side bug. Since incoming GIOP > requests have no reference type indication, it cannot be detected > there, > so the best the ORB can do is to return BAD_OPERATION if the > operation > is not supported by the servant, or MARSHAL if the operation name is > supported, but the arguments are not correctly typed. Agreed so far. > > The case is more interesting if the call is local, through a typed > object reference. In this case, the ORB can detect that the servant > is > of the wrong type, and in fact must do the check if it to avoid a > core > dump. I think it is better to raise the OBJ_ADAPTER exception here, > as > a clearer indication that it is server side that screwed up, and not > any > fault of the client side. Frankly, I don't see any additional work > on > the ORB's part to detect this condition. I agree about the check being needed for an efficient local static-client to static-implementation invocation. This check could return any exception we specify, such as OBJ_ADAPTER or BAD_OPERATION. But consider a local invocation where the server is dynamic. Without any extra checking, an "invalid" DSI servant should return a BAD_OPERATION exception, not OBJ_ADAPTER. Requiring the client to receive OBJ_ADAPTER in the first case while allowing it to receive BAD_OPERATION in the second case exposes to the client a distinction between static and dynamic implementations, breaking implementation transparency. To avoid breaking this transparency, the proposal would have to be modified to require the Servant type check for DSI Servants too, or not require it at all. I think this same line of reasoning applies to remote as well as local invocations. Here is another seperate argument: The Java mapping's portable skeletons are based on the DSI, so the POA cannot distinguish a portable static servant from a dynamic servant. It would therefore need to check the type of all Servants, and would most likely do this by invoking _is_a() on the Servant. But what RepositoryId would it pass to _is_a()? This isn't available from the request message, and an object reference isn't necessarily laying around in the server, so the POA would have to ask the Servant for its _primary_interface(). The POA would end up making two extra calls on the Servant just to see if that servant's implementation of _is_a() agreed with its implementation of _primary_interface(). The skeleton implements both _primary_interface() and _is_a(), so the test will never fail. If the DSI servant's implementation of _is_a() is written in terms of _primary_interface(), it will never fail either. Finally, even if there are cases where an error would be detected, we're talking about two extra function calls (_primary_interface() and _is_a()) on every invocation when a ServantManager is used. This has got to impact performance. > > Would it be better to change the proposal to state that any of the > three > exceptions: OBJ_ADAPTER, BAD_OPERATION, MARSHAL could be thrown, > since > it appears to depend on whether the call is local or not? That would be acceptable to me. Whether the object is local vs. remote, or static vs. dynamic, should be transparent to the client. The same exceptions need to be legal in all these cases. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -Bob Return-Path: From: "Daniel R. Frantz" To: Subject: Issue 643 (second version) Date: Thu, 9 Jul 1998 21:52:12 -0400 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 We've had a few go-rounds on this one, with Bob starting off with: >> 643: Return of invalid Servant as result of incarnate() or >> preinvoke() > >I object strongly to requiring >the POA to test the type of the Servant on every invocation just to >return OBJ_ADAPTER instead of BAD_OPERATION. See my recent email. There have been at least a half-dozen comments. I had voted for this originally, but a couple things have convinced me to change my vote. First, I agree with Bob (shucks!) that the check on every servant locator call is wasted effort. An error would be detected immediately afterward, as soon as the method call is made anyway. That's an efficiency argument that got me half-way to change. The other half-way came with the realization that detecting the error for servant managers is only part of the problem and we can't solve it all consistently. The benefit of finding an error at servant manager starting time (preinvoke or incarnate) is to give a more precise indication of an error. However, the same precision can't happen for default servants or for explicit activations. A badly written server can give the POA a bad default_servant or put a bad servant into the AOM with activate_object. It isn't until an actual request (method call) that the error is detected. It's nice to detect errors early when possible, but we can't be consistent about it. The client doesn't know what kind of server there is or what goes on there. The client doesn't care when one error or the other takes place, it doesn't work for either error. "Just fix it, you @$%!$% server writer!" Changing my vote still leaves enough votes to pass the original proposal. However, I'd like to ask for a vote on the alternate proposal, along the lines already discussed. The null return situation stays the same, but we just warn users about the other situation. If this proposal receives enough votes it will replace the other one. If not, the other stands. Here is the canonical form. ================================================================== Issue 643: Return of invalid Servant as result of incarnate() or (2nd) preinvoke(). Nature: Clarification Summary: Spec does not address case when ServantManager returns an invalid Servant to POA as result of an incarnate() or preinvoke() operation. The POA should return OBJ_ADAPTER. Resolution: Accepted for Portability 2.3 RTF Revision: Page 9-34, 9.3.4 ServantManager Interface. Add a paragraph just before the subsection "Locality Constraints": If a ServantManager returns a null Servant (or the equivalent in a language mapping) as the result of an incarnate() or preinvoke() operation, the POA will return the OBJ_ADAPTER system exception as the result of the request. If the ServantManager returns the wrong type of Servant, it is indeterminate when that error is detected. It is likely to result in a BAD_OPERATION or MARSHAL exception at the time of method invocation. Return-Path: Date: Thu, 09 Jul 1998 22:33:13 -0400 From: Bob Kukura Organization: IONA Technologies To: "Daniel R. Frantz" CC: port-rtf@omg.org Subject: Re: Issue 643 (second version) References: <003e01bdaba5$5bfb47b0$3fc5bdce@idler.beasys.com> I vote YES on the new proposal. See minor comment below. Daniel R. Frantz wrote: > > We've had a few go-rounds on this one, with Bob starting off with: > > >> 643: Return of invalid Servant as result of incarnate() or > >> preinvoke() > > > >I object strongly to requiring > >the POA to test the type of the Servant on every invocation just to > >return OBJ_ADAPTER instead of BAD_OPERATION. See my recent email. > > There have been at least a half-dozen comments. > > I had voted for this originally, but a couple things have convinced > me > to change my vote. First, I agree with Bob (shucks!) that the check > on > every servant locator call is wasted effort. An error would be > detected > immediately afterward, as soon as the method call is made > anyway. That's > an efficiency argument that got me half-way to change. > > The other half-way came with the realization that detecting the > error > for servant managers is only part of the problem and we can't solve > it > all consistently. The benefit of finding an error at servant manager > starting time (preinvoke or incarnate) is to give a more precise > indication of an error. However, the same precision can't happen for > default servants or for explicit activations. A badly written server > can > give the POA a bad default_servant or put a bad servant into the AOM > with activate_object. It isn't until an actual request (method call) > that the error is detected. It's nice to detect errors early when > possible, but we can't be consistent about it. The client doesn't > know > what kind of server there is or what goes on there. The client > doesn't > care when one error or the other takes place, it doesn't work for > either > error. "Just fix it, you @$%!$% server writer!" > > Changing my vote still leaves enough votes to pass the original > proposal. However, I'd like to ask for a vote on the alternate > proposal, > along the lines already discussed. The null return situation stays > the > same, but we just warn users about the other situation. > > If this proposal receives enough votes it will replace the other > one. If > not, the other stands. Here is the canonical form. > > ================================================================== > > Issue 643: Return of invalid Servant as result of incarnate() or > (2nd) preinvoke(). > > Nature: Clarification > > Summary: Spec does not address case when ServantManager returns > an invalid Servant to POA as result of an incarnate() > or preinvoke() operation. The POA should return > OBJ_ADAPTER. > > Resolution: Accepted for Portability 2.3 RTF > > Revision: Page 9-34, 9.3.4 ServantManager Interface. Add a > paragraph just before the subsection "Locality > Constraints": > > If a ServantManager returns a null Servant > (or the equivalent in a language mapping) as the > result of an incarnate() or preinvoke() operation, > the POA will return the OBJ_ADAPTER system > exception as the result of the request. If the > ServantManager returns the wrong type of > Servant, it is indeterminate when that error > is detected. It is likely to result in a > BAD_OPERATION or MARSHAL exception at the time > of method invocation. If others wanted to add OBJ_ADAPTER to this list of "likely" exceptions, that would be fine with me too. -Bob Return-Path: Sender: jon@floorboard.com Date: Thu, 09 Jul 1998 20:48:47 -0700 From: Jonathan Biggar To: "Daniel R. Frantz" CC: port-rtf@omg.org Subject: Re: Issue 643 (second version) References: <003e01bdaba5$5bfb47b0$3fc5bdce@idler.beasys.com> Daniel R. Frantz wrote: > ================================================================== > > Issue 643: Return of invalid Servant as result of incarnate() or > (2nd) preinvoke(). > > Nature: Clarification > > Summary: Spec does not address case when ServantManager returns > an invalid Servant to POA as result of an incarnate() > or preinvoke() operation. The POA should return > OBJ_ADAPTER. > > Resolution: Accepted for Portability 2.3 RTF > > Revision: Page 9-34, 9.3.4 ServantManager Interface. Add a > paragraph just before the subsection "Locality > Constraints": > > If a ServantManager returns a null Servant > (or the equivalent in a language mapping) as the > result of an incarnate() or preinvoke() operation, > the POA will return the OBJ_ADAPTER system > exception as the result of the request. If the > ServantManager returns the wrong type of > Servant, it is indeterminate when that error > is detected. It is likely to result in a > BAD_OPERATION or MARSHAL exception at the time > of method invocation. I can live with this version as well. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Sender: "Jeff Mischkinsky" Date: Thu, 09 Jul 1998 21:16:26 -0700 From: Jeff Mischkinsky Organization: Inprise Corporation To: port-rtf@omg.org, Jon Goldberg Subject: re: Issue 643 (second version) Speaking of fried brains, we can't remember how we voted originally. But Inprise now votes YES on the 2nd version, and hence NO on the original. Hi, In keeping with the spreading fried brain syndrome, we can't remember if and how we voted on this one. So just so that we're clear, at least: INPRISE votes YES on the second version, and hence NO on the original. thx, jeff > > > > ------------------------------------------------------------------------ > > Subject: Issue 643 (second version) > Date: Thu, 09 Jul 1998 17:52:12 -0800 > From: "Daniel R. Frantz" > To: port-rtf@omg.org > > We've had a few go-rounds on this one, with Bob starting off with: > > >> 643: Return of invalid Servant as result of incarnate() or > >> preinvoke() > > > >I object strongly to requiring > >the POA to test the type of the Servant on every invocation just to > >return OBJ_ADAPTER instead of BAD_OPERATION. See my recent email. > > There have been at least a half-dozen comments. > > I had voted for this originally, but a couple things have convinced > me > to change my vote. First, I agree with Bob (shucks!) that the check > on > every servant locator call is wasted effort. An error would be > detected > immediately afterward, as soon as the method call is made > anyway. That's > an efficiency argument that got me half-way to change. > > The other half-way came with the realization that detecting the > error > for servant managers is only part of the problem and we can't solve > it > all consistently. The benefit of finding an error at servant manager > starting time (preinvoke or incarnate) is to give a more precise > indication of an error. However, the same precision can't happen for > default servants or for explicit activations. A badly written server > can > give the POA a bad default_servant or put a bad servant into the AOM > with activate_object. It isn't until an actual request (method call) > that the error is detected. It's nice to detect errors early when > possible, but we can't be consistent about it. The client doesn't > know > what kind of server there is or what goes on there. The client > doesn't > care when one error or the other takes place, it doesn't work for > either > error. "Just fix it, you @$%!$% server writer!" > > Changing my vote still leaves enough votes to pass the original > proposal. However, I'd like to ask for a vote on the alternate > proposal, > along the lines already discussed. The null return situation stays > the > same, but we just warn users about the other situation. > > If this proposal receives enough votes it will replace the other > one. If > not, the other stands. Here is the canonical form. > > ================================================================== > > Issue 643: Return of invalid Servant as result of incarnate() or > (2nd) preinvoke(). > > Nature: Clarification > > Summary: Spec does not address case when ServantManager returns > an invalid Servant to POA as result of an incarnate() > or preinvoke() operation. The POA should return > OBJ_ADAPTER. > > Resolution: Accepted for Portability 2.3 RTF > > Revision: Page 9-34, 9.3.4 ServantManager Interface. Add a > paragraph just before the subsection "Locality > Constraints": > > If a ServantManager returns a null Servant > (or the equivalent in a language mapping) as the > result of an incarnate() or preinvoke() operation, > the POA will return the OBJ_ADAPTER system > exception as the result of the request. If the > ServantManager returns the wrong type of > Servant, it is indeterminate when that error > is detected. It is likely to result in a > BAD_OPERATION or MARSHAL exception at the time > of method invocation. -- Jeff Mischkinsky email: Senior Software Architect jeffm@visigenic.com INPRISE Corporation voice: +1(650)312-5158 951 Mariner's Island Blvd. Suite 460 fax: +1(650)286-2475 San Mateo, CA 94404 web: http://www.inprise.com