Issue 10522: Servant_to_id clarification (corba-e-ftf) Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen@remedy.nl) Nature: Uncategorized Issue Severity: Summary: In the OMG spec the servant_to_id is described as below. If the RETAIN, NO_IMPLICIT_ACTIVATION an UNIQUE has been set then the pre condition is valid so we don't get wrong policy. Then we follow the steps, 1 is not possible, 2 is also not possible, 3 is not possible, so 4 is triggered but that looks very strange. I think there should be another step says if RETAIN and UNIQUE and NO_IMPLICIT_ACTIVATION and not active then we get WrongPolicy. Ok, the servant is not active, but it is more that the policies are wrong. This appeared when testing for CORBA/e compact. There RETAIN, NO_IMPLICIT_ACTIVATION and UNIQUE are the default and without a special check for CORBA/e we got a ServantNotActive exception instead of the wrong policy. We could add a check for CORBA/e compact but it looks that the real issue is in the core spec already. Johnny This operation requires the USE_DEFAULT_SERVANT policy or a combination of the RETAIN policy and either the UNIQUE_ID or IMPLICIT_ACTIVATION policies if invoked outside the context of an operation dispatched by this POA. If this operation is not invoked in the context of executing a request on the specified servant and the policies specified previously are not present, the WrongPolicy exception is raised. This operation has four possible behaviors. 1. If the POA has both the RETAIN and the UNIQUE_ID policy and the specified servant is active, the Object Id associated with that servant is returned. March 2004 CORBA, v3.0.3: Interfaces 11-43 11 2. If the POA has both the RETAIN and the IMPLICIT_ACTIVATION policy and either the POA has the MULTIPLE_ID policy or the specified servant is not active, the servant is activated using a POA-generated Object Id and the Interface Id associated with the servant, and that Object Id is returned. 3. If the POA has the USE_DEFAULT_SERVANT policy, the servant specified is the default servant, and the operation is being invoked in the context of executing a request on the default servant, then the ObjectId associated with the current invocation is returned. 4. Otherwise, the ServantNotActive exception is raised. Resolution: Revised Text: Actions taken: December 12, 2006: received issue Discussion: Intent of specification was exactly as specified. Use of WrongPolicy should be independent of any state of servant to which operation is applied. Disposition: Closed, no change End of Annotations:===== m: "Johnny Willemsen" To: Cc: Subject: Servant_to_id clarification Date: Tue, 12 Dec 2006 12:52:11 +0100 X-Mailer: Microsoft Office Outlook 11 thread-index: Accd4/V+p5eAqziURNetGxN2UvrKRQ== X-Virus-Scanned: by XS4ALL Virus Scanner X-Spam-Status: No, hits=0.1 required=5.0 tests=MISSING_OUTLOOK_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Hi, In the OMG spec the servant_to_id is described as below. If the RETAIN, NO_IMPLICIT_ACTIVATION an UNIQUE has been set then the pre condition is valid so we don't get wrong policy. Then we follow the steps, 1 is not possible, 2 is also not possible, 3 is not possible, so 4 is triggered but that looks very strange. I think there should be another step says if RETAIN and UNIQUE and NO_IMPLICIT_ACTIVATION and not active then we get WrongPolicy. Ok, the servant is not active, but it is more that the policies are wrong. This appeared when testing for CORBA/e compact. There RETAIN, NO_IMPLICIT_ACTIVATION and UNIQUE are the default and without a special check for CORBA/e we got a ServantNotActive exception instead of the wrong policy. We could add a check for CORBA/e compact but it looks that the real issue is in the core spec already. Johnny This operation requires the USE_DEFAULT_SERVANT policy or a combination of the RETAIN policy and either the UNIQUE_ID or IMPLICIT_ACTIVATION policies if invoked outside the context of an operation dispatched by this POA. If this operation is not invoked in the context of executing a request on the specified servant and the policies specified previously are not present, the WrongPolicy exception is raised. This operation has four possible behaviors. 1. If the POA has both the RETAIN and the UNIQUE_ID policy and the specified servant is active, the Object Id associated with that servant is returned. March 2004 CORBA, v3.0.3: Interfaces 11-43 11 2. If the POA has both the RETAIN and the IMPLICIT_ACTIVATION policy and either the POA has the MULTIPLE_ID policy or the specified servant is not active, the servant is activated using a POA-generated Object Id and the Interface Id associated with the servant, and that Object Id is returned. 3. If the POA has the USE_DEFAULT_SERVANT policy, the servant specified is the default servant, and the operation is being invoked in the context of executing a request on the default servant, then the ObjectId associated with the current invocation is returned. From: "Johnny Willemsen" To: Subject: [Issue 10522] Servant_to_id clarification Date: Thu, 28 Dec 2006 12:05:28 +0100 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccqcBUpa4StweS5Tz26cThxxjHHEg== X-Virus-Scanned: by XS4ALL Virus Scanner X-Spam-Status: No, hits=0.1 required=5.0 tests=MISSING_OUTLOOK_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Hi, Issue 10522 has been stored under CORBA/e but this is really something for the core CORBA spec. I did find this when implementing CORBA/e but the real problem is in the core spec. Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands To: Johnny Willemsen Cc: corba-e-ftf@omg.org Subject: Issue 10522 - clarification needed From: Victor Giddings Date: Thu, 7 Feb 2008 11:38:17 -0500 X-Mailer: Apple Mail (2.753) Johnny, I am having a problem with this description now that I am looking at it intensely. You seem to be saying: RETAIN + NO_IMPLICIT_ACTIVATION + UNIQUE_ID + {servant not active} =should yield=> WrongPolicy RETAIN + NO_IMPLICIT_ACTIVATION + UNIQUE_ID + {servant not active} =does currently yield=> ServantNotActive First, is this an accurate statement of the problem? Second, if so, why do you believe this is a policy problem? The policies seem reasonable to me and should be independent of activation state of the servant. Further, there is no way for the POA to return an ID for the servant that it has not "seen" before. In the OMG spec the servant_to_id is described as below. If the RETAIN, NO_IMPLICIT_ACTIVATION and UNIQUE has been set, then the pre condition is valid so we don't get wrong policy. Then we follow the steps, 1 is not possible, 2 is also not possible, 3 is not possible, so 4 is triggered but that looks very strange. I think there should be another step says if RETAIN and UNIQUE and NO_IMPLICIT_ACTIVATION and not active then we get WrongPolicy. OK, the servant is not active, but it is more that the policies are wrong. This appeared when testing for CORBA/e compact. There RETAIN, NO_IMPLICIT_ACTIVATION and UNIQUE are the default and without a special check for CORBA/e we got a ServantNotActive exception instead of the wrong policy. We could add a check for CORBA/e compact but it looks that the real issue is in the core spec already. Johnny .This operation requires the USE_DEFAULT_SERVANT policy or a combination of the RETAIN policy and either the UNIQUE_ID or IMPLICIT_ACTIVATION policies if invoked outside the context of an operation dispatched by this POA. If this operation is not invoked in the context of executing a request on the specified servant and the policies specified previously are not present, the WrongPolicy exception is raised. This operation has four possible behaviors. 1. If the POA has both the RETAIN and the UNIQUE_ID policy and the specified servant is active, the Object Id associated with that servant is returned. March 2004 CORBA, v3.0.3: Interfaces 11-43 11 2. If the POA has both the RETAIN and the IMPLICIT_ACTIVATION policy and either the POA has the MULTIPLE_ID policy or the specified servant is not active, the servant is activated using a POA-generated Object Id and the Interface Id associated with the servant, and that Object Id is returned. 3. If the POA has the USE_DEFAULT_SERVANT policy, the servant specified is the default servant, and the operation is being invoked in the context of executing a request on the default servant, then the ObjectId associated with the current invocation is returned. 4. Otherwise, the ServantNotActive exception is raised.. Victor Giddings Objective Interface Systems victor.giddings@mail.ois.com X-Virus-Scanned: by XS4ALL Virus Scanner X-Spam-Flag: NO X-Spam-Score: -4.354 X-Spam-Level: X-Spam-Status: No, score=-4.354 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001] From: "Johnny Willemsen" To: "'Victor Giddings'" Cc: Subject: RE: Issue 10522 - clarification needed Date: Thu, 7 Feb 2008 20:14:17 +0100 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Achpp+HeqZppC/6JSIWD1D4WzkihxwAFQQ5w Hi, It has been some time ago I reported this. When now reading the text again I do see you are right. This should be a servant not active exception. WrongPolicy doesn't make sense. Please reject this issue. Johnny From: Victor Giddings [mailto:victor.giddings@mail.ois.com] Sent: Thursday, February 07, 2008 5:38 PM To: Johnny Willemsen Cc: corba-e-ftf@omg.org Subject: Issue 10522 - clarification needed Johnny, I am having a problem with this description now that I am looking at it intensely. You seem to be saying: RETAIN + NO_IMPLICIT_ACTIVATION + UNIQUE_ID + {servant not active} =should yield=> WrongPolicy RETAIN + NO_IMPLICIT_ACTIVATION + UNIQUE_ID + {servant not active} =does currently yield=> ServantNotActive First, is this an accurate statement of the problem? Second, if so, why do you believe this is a policy problem? The policies seem reasonable to me and should be independent of activation state of the servant. Further, there is no way for the POA to return an ID for the servant that it has not "seen" before. In the OMG spec the servant_to_id is described as below. If the RETAIN, NO_IMPLICIT_ACTIVATION and UNIQUE has been set, then the pre condition is valid so we don't get wrong policy. Then we follow the steps, 1 is not possible, 2 is also not possible, 3 is not possible, so 4 is triggered but that looks very strange. I think there should be another step says if RETAIN and UNIQUE and NO_IMPLICIT_ACTIVATION and not active then we get WrongPolicy. OK, the servant is not active, but it is more that the policies are wrong. This appeared when testing for CORBA/e compact. There RETAIN, NO_IMPLICIT_ACTIVATION and UNIQUE are the default and without a special check for CORBA/e we got a ServantNotActive exception instead of the wrong policy. We could add a check for CORBA/e compact but it looks that the real issue is in the core spec already. Johnny .This operation requires the USE_DEFAULT_SERVANT policy or a combination of the RETAIN policy and either the UNIQUE_ID or IMPLICIT_ACTIVATION policies if invoked outside the context of an operation dispatched by this POA. If this operation is not invoked in the context of executing a request on the specified servant and the policies specified previously are not present, the WrongPolicy exception is raised. This operation has four possible behaviors. 1. If the POA has both the RETAIN and the UNIQUE_ID policy and the specified servant is active, the Object Id associated with that servant is returned. March 2004 CORBA, v3.0.3: Interfaces 11-43 11 2. If the POA has both the RETAIN and the IMPLICIT_ACTIVATION policy and either the POA has the MULTIPLE_ID policy or the specified servant is not active, the servant is activated using a POA-generated Object Id and the Interface Id associated with the servant, and that Object Id is returned. 3. If the POA has the USE_DEFAULT_SERVANT policy, the servant specified is the default servant, and the operation is being invoked in the context of executing a request on the default servant, then the ObjectId associated with the current invocation is returned. 4. Otherwise, the ServantNotActive exception is raised.. Victor Giddings Objective Interface Systems victor.giddings@mail.ois.com 4. Otherwise, the ServantNotActive exception is raised.