Issue 3777: Exact text for IORInfo::get_effective_policy (interceptors-rtf) Source: Oracle (Dr. Harold Carr, Ph.D., nobody) Nature: Uncategorized Issue Severity: Summary: The summary of issue 3660 (IORInfo::get_effective_policy access to POA policies ) says: "The standard POA policies should be available via IORInfo::get_effective_policy" The resolution says: Exact text to be determined as a new issue if this issue passes. I think we could agree to add text (like that suggested by Bob) to say policies passed to create_POA are available as an editorial part of 3660. This would result in text like the following: ------------------------- An ORB service implementation may determine what server side policy of a particular type is in effect for an IOR being constructed by calling the get_effective_policy. The returned CORBA::Policy object shall only be a policy whose type was registered via ORBInitInfo::register_policy_factory (see section 21.7.2.12, register_policy_factory on page 21-43) AND policies defined in module PortableServer. If a policy for the given type was not registered via register_policy_factory or is not defined in module PortableServer, this operation will raise INV_POLICY with a standard minor code of 2. ------------------------- It seems that no one wants the registration bits any longer. And, in the process of looking at this, it was discovered that the text does not say what happens when the given policy is not in effect. Removing the bits about policy factory registration and adding the policy not in effect bits seems to go beyond the scope of 3660. So, I think we need to vote on an issue for the exact text of get_effective_policy. I propose: ------------------------- An ORB service implementation may determine what server side policy of a particular type is in effect for an IOR being constructed by calling the get_effective_policy operation. When the IOR being constructed is for an object implemented using a POA, all Policy objects passed to the PortableServer::POA::create_POA call that created that POA are accessable via get_effective_policy. If a policy for the given type is not known to the ORB, then this operation will raise INV_POLICY with a standard minor code of 2. Parameters type The CORBA::PolicyType specifying the type of policy to return. Return Value The effective CORBA::Policy object of the requested type. If a policy for the given type is known but that policy is not in effect, then this operation will return a nil object reference. ------------------------- I'll get an official vote issue document posted right away. Resolution: fixed, close issue Revised Text: n ORB service implementation may determine what server side policy of a particular type is in effect for an IOR being constructed by calling the get_effective_policy operation. When the IOR being constructed is for an object implemented using a POA, all Policy objects passed to the PortableServer::POA::create_POA call that created that POA are accessable via get_effective_policy. If a policy for the given type is not known to the ORB, then this operation will raise INV_POLICY with a standard minor code of 2. Parameters type The CORBA::PolicyType specifying the type of policy to return. Return Value The effective CORBA::Policy object of the requested type. If a policy for the given type is known but that policy is not in effect, then this operation will return a nil object reference. Actions taken: June 16, 2000: received issue October 17, 2000: issue XX in the original report October 17, 2000: closed issue Discussion: End of Annotations:===== Date: Wed, 2 Aug 2000 16:27:47 -0700 (PDT) Message-Id: <200008022327.QAA01248@shorter.eng.sun.com> From: Harold Carr To: interceptors@omg.org, issues@omg.org Cc: juergen@omg.org Subject: New issue: Portable Interceptors viz-a-viz LOCATION_FORWARD_PERMANENT Content-Type: text X-UIDL: KiUd9'0Qd9E6,e9$U8e9 LOCATION_FORWARD_PERMANENT was deprecated by the interop 2Kplus, issue 1486. It was included in vote 2: ftp://ftp.omg.org/pub/interop/interop2kplusvote2.htm The results are somewhere in: ftp://ftp.omg.org/pub/interop However, the portable interceptor specification ptc/2000-04-05 specifies a ForwardRequest exception with a boolean permanent field. This field and all references to it should be removed from the interceptor specification. Cheers, Harold PS: Interceptor FTFers: I would like to include this in our vote 7, which I will be posting tonight - I'll include it without an issue number for now. Date: Wed, 2 Aug 2000 14:17:07 -0700 (PDT) Message-Id: <200008022117.OAA19534@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org Subject: LOCATION_FORWARD_PERMANENT Content-Type: text X-UIDL: *E5!!p'b!!po'!!n(fd9 Does anyone know if LOCATION_FORWARD_PERMANENT got deprecated? I seem to remember some discussion in other groups in this regard. I ask because, if it is deprecated, we need to fix the PI spec accordingly. Cheers, Harold From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: LOCATION_FORWARD_PERMANENT Date: Thu, 3 Aug 2000 08:24:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: d`b!!@`ld9JA~!!'b2e9 I think so, but (at least in my mind) the status of this is fuzzy. I wouldn't hurry to do anything about it. Paul > -----Original Message----- > From: Harold Carr [mailto:harold.carr@eng.sun.com] > Sent: Wednesday, August 02, 2000 5:17 PM > To: interceptors-ftf@omg.org > Subject: LOCATION_FORWARD_PERMANENT > > > > Does anyone know if LOCATION_FORWARD_PERMANENT got deprecated? I seem > to remember some discussion in other groups in this regard. I ask > because, if it is deprecated, we need to fix the PI spec accordingly. > > Cheers, > Harold > Date: Mon, 7 Aug 2000 09:59:14 +0200 (MET DST) Message-Id: <200008070759.JAA24679@hess.dinsunnet> From: Julien Maisonneuve To: harold.carr@eng.sun.com CC: interceptors-ftf@omg.org In-reply-to: <200008022117.OAA19534@shorter.eng.sun.com> (message from Harold Carr on Wed, 2 Aug 2000 14:17:07 -0700 (PDT)) Subject: Re: LOCATION_FORWARD_PERMANENT Content-Type: text X-UIDL: F9Ce9/j\d9iSQe9?Xn!! Date: Wed, 2 Aug 2000 14:17:07 -0700 (PDT) From: Harold Carr Does anyone know if LOCATION_FORWARD_PERMANENT got deprecated? I seem to remember some discussion in other groups in this regard. I ask because, if it is deprecated, we need to fix the PI spec accordingly. Hi folks, I don't know, but if it was, this would be a significant problem for Fault-Tolerant CORBA as it is explicitly mentionned in the spec (and really useful). I guess the FT FTF would have to reinstate it somehow. Julien. -- Julien Maisonneuve, PhD IP Unit B1-338 Alcatel Corporate Research Center Alcanet: 2111 1577 Route de Nozay Tel: +33 1 6963 1577 91461 Marcoussis cedex Fax: +33 1 6963 1169 FRANCE Julien.Maisonneuve@alcatel.fr Date: Mon, 7 Aug 2000 10:01:53 +0200 (MET DST) Message-Id: <200008070801.KAA24683@hess.dinsunnet> From: Julien Maisonneuve To: ft-ftf@omg.org Subject: [harold.carr@Eng.Sun.COM: LOCATION_FORWARD_PERMANENT] Content-Type: text X-UIDL: o6d!!'> To: interceptors-ftf@omg.org Subject: LOCATION_FORWARD_PERMANENT Does anyone know if LOCATION_FORWARD_PERMANENT got deprecated? I seem to remember some discussion in other groups in this regard. I ask because, if it is deprecated, we need to fix the PI spec accordingly. Cheers, Harold ------- End of forwarded message ------- Date: Mon, 07 Aug 2000 06:53:52 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Julien Maisonneuve CC: harold.carr@eng.sun.com, interceptors-ftf@omg.org Subject: Re: LOCATION_FORWARD_PERMANENT References: <200008070759.JAA24679@hess.dinsunnet> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: bZcd97-Xd9[9W!!J;~e9 reply below... > > Date: Wed, 2 Aug 2000 14:17:07 -0700 (PDT) > From: Harold Carr > > Does anyone know if LOCATION_FORWARD_PERMANENT got deprecated? I seem > to remember some discussion in other groups in this regard. I ask > because, if it is deprecated, we need to fix the PI spec accordingly. > Hi folks, > I don't know, but if it was, this would be a significant problem for > Fault-Tolerant CORBA as it is explicitly mentionned in the spec (and > really useful). I guess the FT FTF would have to reinstate it somehow. LOCATION_FORWARD_PERMANENT was deprecated by the interop 2Kplus, issue 1486. It was included in interop 2kplus vote 2: ftp://ftp.omg.org/pub/interop/interop2kplusvote2.htm The results are somewhere in: ftp://ftp.omg.org/pub/interop Based on that vote, interceptors are now voting to remove the permanent attribute and all mentions of LOCATION_FORWARD_PERMANENT. So far, everyone is agreeing it should be removed. If this really is a significant problem you should raise an issue with interop. Cheers, Harold Date: Tue, 8 Aug 2000 00:28:30 +1000 (EST) From: Michi Henning To: Harold Carr cc: Julien Maisonneuve , harold.carr@eng.sun.com, interceptors-ftf@omg.org Subject: Re: LOCATION_FORWARD_PERMANENT In-Reply-To: <398EBF70.B3AB36D@sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: =#1!!W2C!!8d#!!E@4!! On Mon, 7 Aug 2000, Harold Carr wrote: > reply below... > > > > Date: Wed, 2 Aug 2000 14:17:07 -0700 (PDT) > > From: Harold Carr > > > > Does anyone know if LOCATION_FORWARD_PERMANENT got deprecated? I seem > > to remember some discussion in other groups in this regard. I ask > > because, if it is deprecated, we need to fix the PI spec accordingly. > > Hi folks, > > I don't know, but if it was, this would be a significant problem for > > Fault-Tolerant CORBA as it is explicitly mentionned in the spec (and > > really useful). I guess the FT FTF would have to reinstate it somehow. If the FT FTF wants to reinstate it, it must also come up with a way to deal with Object::hash(). The spec requires the value returned by hash() to be immutable for the life time of the reference. [ Unfortunately, "life time" isn't defined in the core which really is a separate defect. ] LOCATION_FORWARD_PERM causes problems with this immutability, which is why we deprecated it. The issue archive should contain all the detail... 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 Date: Tue, 8 Aug 2000 00:29:37 +1000 (EST) From: Michi Henning To: ft-ftf@omg.org Subject: Re: LOCATION_FORWARD_PERMANENT (fwd) Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: LL5e9-l^d9(l""!oC'!! Sorry, I forgot to CC ft-ftf on this. Michi. ---------- Forwarded message ---------- From: Michi Henning Organization: Object Oriented Concepts To: Harold Carr Cc: Julien Maisonneuve , harold.carr@eng.sun.com, interceptors-ftf@omg.org Date: Tue, 8 Aug 2000 00:28:30 +1000 (EST) Subject: Re: LOCATION_FORWARD_PERMANENT On Mon, 7 Aug 2000, Harold Carr wrote: > reply below... > > > > Date: Wed, 2 Aug 2000 14:17:07 -0700 (PDT) > > From: Harold Carr > > > > Does anyone know if LOCATION_FORWARD_PERMANENT got deprecated? I seem > > to remember some discussion in other groups in this regard. I ask > > because, if it is deprecated, we need to fix the PI spec accordingly. > > Hi folks, > > I don't know, but if it was, this would be a significant problem for > > Fault-Tolerant CORBA as it is explicitly mentionned in the spec (and > > really useful). I guess the FT FTF would have to reinstate it somehow. If the FT FTF wants to reinstate it, it must also come up with a way to deal with Object::hash(). The spec requires the value returned by hash() to be immutable for the life time of the reference. [ Unfortunately, "life time" isn't defined in the core which really is a separate defect. ] LOCATION_FORWARD_PERM causes problems with this immutability, which is why we deprecated it. The issue archive should contain all the detail... 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