Issue 642: Add operation to POAManager to query state (port-rtf) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: There is no operation to query state of POAManager. Add: enum State { HOLDING, ACTIVE, DISCARDING, INACTIVE }; State get_state() to interface Resolution: Accepted for Portability 2.3 RTF. Revised Text: Revision: Page 9-19, Section 9.3.2 "POAManager Interface". Add Actions taken: August 1, 1997: received issue July 30, 1998: closed issue Discussion: End of Annotations:===== Return-Path: Sender: jon@sems.com Date: Fri, 01 Aug 1997 14:03:12 -0700 From: Jonathan Biggar Organization: Seagate Software NMSG To: port-rtf@omg.org Subject: Another issue The spec takes great care to define the states that a POAManager can have, but there is no operation to query the state. It would be nice if the following were added to the POAManager interface: enum State { HOLDING, ACTIVE, DISCARDING, INACTIVE }; State get_state(); Otherwise the programmer must write code to remember the state. Jon Biggar jon@sems.com Return-Path: Sender: jon@floorboard.com Date: Sat, 11 Apr 1998 19:53:48 -0700 From: Jonathan Biggar To: port-rtf@omg.org Subject: Re: Issue 642 Proposal: Add the following to the PortableServer::POAManager interface: module PortableServer { ... interface POAManager { .... enum State { HOLDING, ACTIVE, DISCARDING, INACTIVE }; State get_state(); .... }; ... }; Discussion: 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. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org 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 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(); ----------------- 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