Issue 3660: IORInfo::get_effective_policy access to POA policies (interceptors-rtf) Source: Oracle (Dr. Harold Carr, Ph.D., nobody) Nature: Uncategorized Issue Severity: Summary: IORInfo::get_effective_policy should allow access to the standard POA policies. In general, all policies given to an object adapter should be available regardless of what factory was used to create them. Knowing whether a POA is transient or persistent is necessary to support a Server Activation Framework. Resolution: Incorporate change and close issue. See issue XX for exact text. Revised Text: Actions taken: May 30, 2000: received issue January 16, 2001: closed issue Discussion: End of Annotations:===== Date: Tue, 30 May 2000 07:35:06 -0700 (PDT) Message-Id: <200005301435.HAA13807@shorter.eng.sun.com> From: Harold Carr To: interceptor-ftf@omg.org, issues@omg.org Subject: IORInfo::get_effective_policy access to POA policies Content-Type: text X-UIDL: 2 From: Harold Carr To: interceptors-ftf@omg.org, issues@omg.org Subject: Portable Activation Framework using Portable Interceptors Content-Type: text X-UIDL: BMhd9FO!e9BIBe9&$>e9 Jurgen, this is a discussion of issues I raised earlier, please do not make this an issue. All, OK, as promised, here are how the issues I raised relate to building a portable activation service. Please keep in mind, *THIS IS A USE-CASE*. We are *NOT* trying to standardize location/activation services. We are proposing changes/extensions to portable interceptors based on our prototype of an activation service built using portable interceptors. I've identified the portions of the service which require changes/extensions to the existing PI spec by preceding them with "PI FTF". ORBD Startup - PI FTF - ORBD is started on same port -ORBPersistentServerPort. - ORBD specifies its ORBInitializer class. - ORBDInitializer creates and registers activator reference in initial references. - ORBDInitializer creates and registers a ServerRequestInterceptor. Server Startup - PI FTF - started with PersistentServerId (passed by activator). - Activator passes appropriate ORBInitializer class. - ORBInitializer pre_init creates and registers IORInterceptor. - ORBInitializer post_init uses - ORBInitInfo::resolve_initial_references to obtain a reference to the Activator which it gives to - IORInterceptor for use during POA creation. Server POA Creation In IORInterceptor: - PI FTF - everything happens in new point: components_available. - PI FTF - need access to POA LifeSpanPolicy (to determine if - PERSISTENT). - If persistent then do the following steps. - PI FTF - get the IORTemplate associated with this POA. - Register that template with the activator. - Get the activator's template. - PI FTF - set the adapter's template to the activator's template. - Now, any references created by this POA will "point" to the activator (and contain components appropriate for the activator). - PI FTF - the IORInterceptor must be called each time a POA is (re)created to enable it to exchange information with the - activator. ORBD Server Request Interceptor - Get the adapter_id from ServerRequestInfo. - Lookup the template associated with this id. - If it doesn't exist then request is for the ORBD. - Otherwise - Get the object_id from ServerRequestInfo. - PI FTF - Use the object id to create a new reference from the - server's template. - Raise ForwardRequest. Misc - PI FTF - not explicit is the fact that Java ORBs need an ORB ID for persistent references to be unique: serverId | orbId | poa path/name. - PI FTF - when an object adapter is destroyed it notifies the activator of this fact so that the activator may reclaim resources. Cheers, Harold Date: Tue, 30 May 2000 13:02:36 -0230 From: Matthew Newhook To: Harold Carr Cc: interceptors-ftf@omg.org, issues@omg.org Subject: Re: IORInfo::get_effective_policy access to POA policies Message-ID: <20000530130235.A27648@ooc.com> References: <3933D976.A6D968B2@sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <3933D976.A6D968B2@sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: !pXd9FHC!!-l=!!Jc^d9 Hi, On Tue, May 30, 2000 at 08:08:38AM -0700, Harold Carr wrote: > IORInfo::get_effective_policy should allow access to the standard POA > policies. In general, all policies given to an object adapter should > be available regardless of what factory was used to create them. > > Knowing whether a POA is transient or persistent is necessary to > support a Server Activation Framework. By raising these issues you are assuming a certain model of server activation. I really don't see the point of raising specific issues for all of these things until this model is made clear. Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 28 Jun 2000 12:41:55 -0700 (PDT) Message-Id: <200006281941.MAA25807@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org Subject: Issue 3660: Access POA Policies Content-Type: text X-UIDL: QGB!!>i-e9^:T!!0-0e9 In Oslo, I showed that a server activator needed access to standard POA policies via IORInfo::get_effective_policy so that it can determine if the POA has a PERSISTENT LifecyclePolicy. At that time we took a straw poll and everyone present indicated that access to standard POA policies via IORInfo::get_effective_policy should be required in the spec. I would like to hear some more feedback, such as another use-case. Also, it seems that all policies given to an object adapter at creation time should be available regardless of what factory was used to create them. I'd like to include this in the vote 4 cycle which will probably start this coming Friday. Thanks, Harold Date: Wed, 28 Jun 2000 16:22:16 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Harold Carr CC: interceptors-ftf@omg.org Subject: Re: Issue 3660: Access POA Policies References: <200006281941.MAA25807@shorter.eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: +b'e9bF$e9IF[!!EQQe9 IONA definitely supports having all Policies passed to the POA visible from IORInfo::get_effective_policy. We thought that this was intended all along, and implemented it that way. -Bob Harold Carr wrote: > > In Oslo, I showed that a server activator needed access to standard > POA policies via IORInfo::get_effective_policy so that it can > determine if the POA has a PERSISTENT LifecyclePolicy. > > At that time we took a straw poll and everyone present indicated that > access to standard POA policies via IORInfo::get_effective_policy > should be required in the spec. > > I would like to hear some more feedback, such as another use-case. > Also, it seems that all policies given to an object adapter at > creation time should be available regardless of what factory was used > to create them. > > I'd like to include this in the vote 4 cycle which will probably start > this coming Friday. > > Thanks, > Harold Date: Mon, 14 Aug 2000 16:03:09 -0700 (PDT) Message-Id: <200008142303.QAA00324@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org Subject: text for issue 3660: poa policies/get_effective_policy Content-Type: text X-UIDL: PcI!! Organization: IONA Technologies X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Harold Carr CC: interceptors-ftf@omg.org Subject: Re: text for issue 3660: poa policies/get_effective_policy References: <200008142303.QAA00324@shorter.eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: QaD!!hFd!!p%Ne9:@O!! > Question: > > The policies defined by Messaging, OTS (others?) are all covered by > the policy_factor mechanism, in terms of being available in > get_effective_policy, right? I don't think that is a safe assumption. If an ORB service is being implemented via PI, then maybe it is safe to assume that its own policies are being implemented via PI, and therefore are accessable, but even that may not always be true. For instance, Orbix 2000 ships with an OTS implementation that does not use PI, but I could imagine a situation where someone would be implemementing their own OTS via PI, and would want to use the Orbix 2000 implementation of the OTS policies, but this restriction would get in the way. Similarly, an ORB service might need to access a policy defined by a different ORB service, and it should not matter whether that ORB service's policies are implemented via PI or via some other APIs. In Orbix 2000, the Messaging policies are implemented in the core, by a mechanism other than PI (PI isn't in the core), and this restriction would prevent a PI-based OTS implementation, for instance, from accessing messaging policies. I strongly feel that this restriction on which policies are accessible should be completely dropped, and thought that dropping this restriction altogether was the intent of this issue resolution. We have no intention of implementing this restriction in Orbix 2000, and I would have argued against this text previously if I had noticed it. > > If not, what would be correct wording for 21.5.3.1? I'd suggest something like: 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. > > Finally, 3660 passed saying that exact text to be determined as a > new > issue if 3660 passes (which it did). Can we just agree on exact > text > here as an editorial fix? Sounds OK to me if we do achieve agreement. > > Please response ASAP, since I need to finish updating the document > soon. > > Thanks, > Harold You are welcome, -Bob Date: Mon, 14 Aug 2000 19:04:37 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kukura CC: Harold Carr , interceptors-ftf@omg.org Subject: Re: text for issue 3660: poa policies/get_effective_policy References: <200008142303.QAA00324@shorter.eng.sun.com> <39989A79.CFDDAA36@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 59]d9Lk8!!B3?e9\QKe9 Bob Kukura wrote: > > > > If not, what would be correct wording for 21.5.3.1? > > I'd suggest something like: > > 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. I could live with that. How do you other PI/FTFers feel? Cheers, H X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 14 Aug 2000 22:12:36 -0400 (EDT) From: Polar Humenn To: Bob Kukura cc: Harold Carr , interceptors-ftf@omg.org Subject: Re: text for issue 3660: poa policies/get_effective_policy In-Reply-To: <39989A79.CFDDAA36@iona.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: (dPd9N24e9=Ged9o@pd9 On Mon, 14 Aug 2000, Bob Kukura wrote: > > > > If not, what would be correct wording for 21.5.3.1? > > I'd suggest something like: > > 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. I will agree with Bob on this one. I think we are really looking to "intercept" what the application does, not what other interceptors do. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: text for issue 3660: poa policies/get_effective_policy Date: Tue, 15 Aug 2000 10:51:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: OHe!!8DEe9C"A!!^QZd9 > Bob Kukura wrote: > > > > > > > If not, what would be correct wording for 21.5.3.1? > > > > I'd suggest something like: > > > > 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. > > I could live with that. How do you other PI/FTFers feel? This is fine with me, a definite improvement. Paul Date: Tue, 15 Aug 2000 18:21:38 -0700 (PDT) Message-Id: <200008160121.SAA04142@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org Subject: RE: text for issue 3660: poa policies/get_effective_policy Content-Type: text X-UIDL: ;Ko!!YVh!!i-n!!L=/e9 How about if we combine the existing text and Bob's suggestion?: ------------------------- 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. Otherwise, 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-46). If a policy for the given type was not registered via register_policy_factory or not explicitly passed to create_POA, this operation will raise INV_POLICY with a standard minor code of 2. ------------------------- Before removing these bits about registration it would be good to know why did someone want to make the policy factory registration requirement in the first place? Regardless, if the policy passed in is not in effect, what does this return? The existing text says it raises INV_POLICY if the policy is not registered, but that is not saying what happens if it is not in effect. It seems like it should say that it raises INV_POLICY if the policy is not in effect (or not registered if we keep those bits). Please respond ASAP. Thanks, Harold Date: Tue, 15 Aug 2000 22:20:54 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Harold Carr CC: interceptors-ftf@omg.org Subject: Re: text for issue 3660: poa policies/get_effective_policy References: <200008160121.SAA04142@shorter.eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: P^D!!$Qm!!,0!"! > How about if we combine the existing text and Bob's suggestion?: I'm strongly apposed to any requirement relative to registration for all the reasons I gave before. I also don't think it makes any sense to have this restriction for non-POA OAs, but not have it for the POA. To me, the choice of how to implement an OTS or messaging policy (i.e. using PI APIs or proprietary APIs) has absolutely nothing to do with whether the application is being implemented using the POA or some other OA. > > ------------------------- > > 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. Otherwise, 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-46). > > If a policy for the given type was not registered via > register_policy_factory or not explicitly passed to create_POA, this > operation will raise INV_POLICY with a standard minor code of 2. > > ------------------------- > > Before removing these bits about registration it would be good to know > why did someone want to make the policy factory registration > requirement in the first place? Can that person speak up, please? I don't recall this discussing from any of the PI submitters' meetings and teleconferences that I was able to participate in, but I did miss a number of them. > > Regardless, if the policy passed in is not in effect, what does this > return? The existing text says it raises INV_POLICY if the policy > is > not registered, but that is not saying what happens if it is not in > effect. It seems like it should say that it raises INV_POLICY if > the > policy is not in effect (or not registered if we keep those bits). I think INV_POLICY makes sense when the policy type is not known to the ORB, where a policy type may be known to the ORB either via registration using PI APIs or some other means. When a policy of a particular type is known to the ORB, but an instance of this type is not passed into create_POA, there is likely to be some default. Defaults are specified for all the POA policies. In our ORBs, ORB-level policies are also used in resolving server-side policies (when the policy is not explicitly specified at the POA level), and configurable and built-in defaults are also used in some cases. CORBA doesn't currently specify too much here. Since the PI specification does not include a portable defaulting mechanism, I'd think portable inteceptor implementations would have to be responsible for knowing the default to use when the policy has not been explicitly set. I don't particularly care this is indicated by raising INV_POLICY or by returing nil. > > Please respond ASAP. > > Thanks, > Harold -Bob Date: Wed, 16 Aug 2000 13:06:09 +1000 (EST) From: Michi Henning To: Bob Kukura cc: Harold Carr , interceptors-ftf@omg.org Subject: Re: text for issue 3660: poa policies/get_effective_policy In-Reply-To: <3999FA86.A62C1FD@iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: "0Ee9KoKd92PJ!!)I?!! On Tue, 15 Aug 2000, Bob Kukura wrote: > > Regardless, if the policy passed in is not in effect, what does this > > return? The existing text says it raises INV_POLICY if the policy is > > not registered, but that is not saying what happens if it is not in > > effect. It seems like it should say that it raises INV_POLICY if the > > policy is not in effect (or not registered if we keep those bits). > > I think INV_POLICY makes sense when the policy type is not known to the > ORB, where a policy type may be known to the ORB either via registration > using PI APIs or some other means. When a policy of a particular type is > known to the ORB, but an instance of this type is not passed into > create_POA, there is likely to be some default. Defaults are specified > for all the POA policies. In our ORBs, ORB-level policies are also used > in resolving server-side policies (when the policy is not explicitly > specified at the POA level), and configurable and built-in defaults are > also used in some cases. CORBA doesn't currently specify too much here. > Since the PI specification does not include a portable defaulting > mechanism, I'd think portable inteceptor implementations would have to > be responsible for knowing the default to use when the policy has not > been explicitly set. I don't particularly care this is indicated by > raising INV_POLICY or by returing nil. I think I mentioned this on a different thread in this group quite some time ago. I believe it would be best to raise INV_POLICY if the policy type is unknown and to return nil if the policy type is known, but no value was set. This will be important for one of the OTS policies for legacy POAs. For those, no policy value is specified for create_poa, but the absence of the policy has meaning to OTS. Returning nil for known policies and INV_POLICY for unknown policies also gives more information to the interceptor, so that would be my preferred approach. 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 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 16 Aug 2000 09:49:18 -0400 (EDT) From: Polar Humenn To: Harold Carr cc: interceptors-ftf@omg.org Subject: RE: text for issue 3660: poa policies/get_effective_policy In-Reply-To: <200008160121.SAA04142@shorter.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ,Z)!!ZeDe9/\4e9h6l!! On Tue, 15 Aug 2000, Harold Carr wrote: > > How about if we combine the existing text and Bob's suggestion?: > > ------------------------- > > An ORB service implementation may determine what server side policy > of ^^^^ the > 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. What about the POA policies that are not retained for the POA, or the POA implementers didn't want retained, such these: const CORBA::PolicyType THREAD_POLICY_ID = 16; const CORBA::PolicyType LIFESPAN_POLICY_ID = 17; const CORBA::PolicyType ID_UNIQUENESS_POLICY_ID = 18; const CORBA::PolicyType ID_ASSIGNMENT_POLICY_ID = 19; const CORBA::PolicyType IMPLICIT_ACTIVATION_POLICY_ID = 20; const CORBA::PolicyType SERVANT_RETENTION_POLICY_ID = 21; const CORBA::PolicyType REQUEST_PROCESSING_POLICY_ID = 22; Should they also be available in the interceptor? > Otherwise, 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-46). > > If a policy for the given type was not registered via > register_policy_factory or not explicitly passed to create_POA, this > operation will raise INV_POLICY with a standard minor code of 2. I don't understand this whole thing. See below. > > ------------------------- > > Before removing these bits about registration it would be good to know > why did someone want to make the policy factory registration > requirement in the first place? I really don't know, why there are policy factories in the first place. (?) As far as I'm concerned, why can't you build any object in any language you want and throw a CORBA::Policy interface on it? What do you need a policy factory for? What do you need a *registered* policy factory for? > Regardless, if the policy passed in is not in effect, what does this > return? The existing text says it raises INV_POLICY if the policy > is > not registered, but that is not saying what happens if it is not in > effect. It seems like it should say that it raises INV_POLICY if > the > policy is not in effect (or not registered if we keep those bits). We always return null if you ask for a policy type that isn't in effect. We use INV_POLICY if there was an error with it, but namely on setting policy, not retrieving it. Cheers, -Polar > Please respond ASAP. > > Thanks, > Harold > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Wed, 16 Aug 2000 11:47:08 -0230 From: Matthew Newhook To: Polar Humenn Cc: interceptors-ftf@omg.org Subject: Re: text for issue 3660: poa policies/get_effective_policy Message-ID: <20000816114708.A1646@ooc.com> References: <200008160121.SAA04142@shorter.eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: \='!!7[Be98F'!!j=ad9 Hi Polar, On Wed, Aug 16, 2000 at 09:49:18AM -0400, Polar Humenn wrote: > I really don't know, why there are policy factories in the first place. > (?) > As far as I'm concerned, why can't you build any object in any language > you want and throw a CORBA::Policy interface on it? What do you need a > policy factory for? What do you need a *registered* policy factory for? This is needed so that ORB::create_policy can be used to create a policies. > Cheers, > -Polar > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: text for issue 3660: poa policies/get_effective_policy Date: Wed, 16 Aug 2000 11:14:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: :^V!!b7H!!O-Z!!\l*e9 The existence of a factory should be irrelevant here - it is only relevant to create_policy. If you managed to create a policy and get it associated with an object adapter, and it is the effective policy of the proper type because it hasn't been overridden, then you ought to be able to retrieve it with get_effective_policy. The only problem I can see is if there is some policy of a type the orb has never heard of, that an application attempts to associate with a POA. (Perhaps some service provides its own implementation of the policy type, with its own means of construction, independent of create_policy.) In this case, is the orb obligated to permit this policy to be associated with a POA, and to retrieve it with get_effective_policy? Paul > -----Original Message----- > From: Matthew Newhook [mailto:matthew@ooc.com] > Sent: Wednesday, August 16, 2000 10:17 AM > To: Polar Humenn > Cc: interceptors-ftf@omg.org > Subject: Re: text for issue 3660: poa policies/get_effective_policy > > > Hi Polar, > > On Wed, Aug 16, 2000 at 09:49:18AM -0400, Polar Humenn wrote: > > I really don't know, why there are policy factories in the > first place. > > (?) > > As far as I'm concerned, why can't you build any object in > any language > > you want and throw a CORBA::Policy interface on it? What do > you need a > > policy factory for? What do you need a *registered* policy > factory for? > > This is needed so that ORB::create_policy can be used to create a > policies. > > > Cheers, > > -Polar > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > Regards, Matthew > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 > Date: Wed, 16 Aug 2000 09:11:28 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interceptors-ftf@omg.org Subject: Re: text for issue 3660: poa policies/get_effective_policy References: <9B164B713EE9D211B6DC0090273CEEA926BF9D@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: E>C!!nIW!!*mPd9UGY!! Paul Kyzivat wrote: > The only problem I can see is if there is some policy of a type the orb has > never heard of, that an application attempts to associate with a POA. > (Perhaps some service provides its own implementation of the policy type, > with its own means of construction, independent of create_policy.) In this > case, is the orb obligated to permit this policy to be associated with a > POA, and to retrieve it with get_effective_policy? I would say yes, association with POA and retrieval via get_effective_policy should be obligated. Didn't we already change the POA spec to say the POA is obligated to accept all policies passed (not just the ones it understands)? Just accepting is meaningless if you can't query them via get_effective_policy later. Harold Date: Wed, 16 Aug 2000 09:32:04 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat , interceptors-ftf@omg.org Subject: Re: text for issue 3660: poa policies/get_effective_policy References: <9B164B713EE9D211B6DC0090273CEEA926BF9D@bos1.noblenet.com> <399ABD30.8C90D4B2@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: )oQd9lQl!!`b_d9kWHe9 How about this as text for get_effective_policy? --------- 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 null object reference. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 16 Aug 2000 12:57:49 -0400 (EDT) From: Polar Humenn To: Harold Carr cc: Paul Kyzivat , interceptors-ftf@omg.org Subject: Re: text for issue 3660: poa policies/get_effective_policy In-Reply-To: <399ABD30.8C90D4B2@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: JITd9&k6!!Y9A!!1,W!! On Wed, 16 Aug 2000, Harold Carr wrote: > > > Paul Kyzivat wrote: > > > The only problem I can see is if there is some policy of a type > the orb has > > never heard of, that an application attempts to associate with a > POA. > > (Perhaps some service provides its own implementation of the > policy type, > > with its own means of construction, independent of create_policy.) > In this > > case, is the orb obligated to permit this policy to be associated > with a > > POA, and to retrieve it with get_effective_policy? > > I would say yes, association with POA and retrieval via > get_effective_policy should be obligated. Didn't we already change > the > POA spec to say the POA is obligated to accept all policies passed > (not > just the ones it understands)? Just accepting is meaningless if you > can't query them via get_effective_policy later. Well, I thought that was the whole point. However, it does raise another question. I think the POA was NOT obligated to keep the policies that it DID understand available. This situation kind of makes it hard for the interceptor to know anything about the POA for which it is trying to create an IOR. -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Wed, 16 Aug 2000 13:36:43 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: Harold Carr , Paul Kyzivat , interceptors-ftf@omg.org Subject: Re: text for issue 3660: poa policies/get_effective_policy References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: %1pd9#0$!!~!#e9D>Pe9 Polar Humenn wrote: > > On Wed, 16 Aug 2000, Harold Carr wrote: > > > > > > > Paul Kyzivat wrote: > > > > > The only problem I can see is if there is some policy of a type the orb has > > > never heard of, that an application attempts to associate with a POA. > > > (Perhaps some service provides its own implementation of the policy type, > > > with its own means of construction, independent of create_policy.) In this > > > case, is the orb obligated to permit this policy to be associated with a > > > POA, and to retrieve it with get_effective_policy? > > > > I would say yes, association with POA and retrieval via > > get_effective_policy should be obligated. Didn't we already change the > > POA spec to say the POA is obligated to accept all policies passed (not > > just the ones it understands)? Just accepting is meaningless if you > > can't query them via get_effective_policy later. > > Well, I thought that was the whole point. > > However, it does raise another question. > > I think the POA was NOT obligated to keep the policies that it DID > understand available. I believe we changed that so that now the POA IS obligated to keep (or alternatively reconstruct) the Policy objects so as to respond correctly to a get_effective_policy invocation. Jishnu. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 16 Aug 2000 13:58:01 -0400 (EDT) From: Polar Humenn To: Harold Carr cc: Paul Kyzivat , interceptors-ftf@omg.org Subject: Re: text for issue 3660: poa policies/get_effective_policy In-Reply-To: <399AC204.D6C08E15@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: X%`!!%7C!!pZ?!!-TAe9 Do we have a formal criteria for what "is known by the ORB?". -Polar On Wed, 16 Aug 2000, Harold Carr wrote: > How about this as text for get_effective_policy? > > --------- > > 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 null object > reference. > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: text for issue 3660: poa policies/get_effective_policy Date: Wed, 16 Aug 2000 14:45:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 6-Vd9`*2e9kA;!!VeR!! There are several cases here: 1) policy placed on the poa was created by the orb: a) it is one of the policy types explicitly called out in the poa chapter & created via the corresponding create method. b) it is a policy created via orb::create_policy, and for which a policy factory is available to the orb c) the policy was obtained from the orb. (Perhaps via one of the security operations.) 2) the policy placed on the poa is of a *type* known to the orb. perhaps it has a typeid matching one of the poa specific policies, but the instance was not created via the orb. 3) the policy placed on the poa is of a *type* unknown to the orb. Namely, the typeid has never before been mentioned to the orb. The question is whether there are any standard ways of getting into cases 2 or 3. With policies as local objects I think there may be. If this is possible and legal, then it places an extra constraint on how the orb manages policies. I don't think it is a huge burden to permit this, but I think we need to go into it with our eyes open. The earlier clarifications about policies on the POA *may* have been approved on the assumption that all policies fall under case 1 above. Paul > -----Original Message----- > From: Harold Carr [mailto:harold.carr@sun.com] > Sent: Wednesday, August 16, 2000 12:11 PM > To: Paul Kyzivat > Cc: interceptors-ftf@omg.org > Subject: Re: text for issue 3660: poa policies/get_effective_policy > > > > > Paul Kyzivat wrote: > > > The only problem I can see is if there is some policy of a > type the orb has > > never heard of, that an application attempts to associate > with a POA. > > (Perhaps some service provides its own implementation of > the policy type, > > with its own means of construction, independent of > create_policy.) In this > > case, is the orb obligated to permit this policy to be > associated with a > > POA, and to retrieve it with get_effective_policy? > > I would say yes, association with POA and retrieval via > get_effective_policy should be obligated. Didn't we already > change the > POA spec to say the POA is obligated to accept all policies > passed (not > just the ones it understands)? Just accepting is meaningless if you > can't query them via get_effective_policy later. > > Harold >