Issue 3625: resolve_initial_references should be OK in ORBInitInfo::pre_init (interceptors-rtf) Source: Oracle (Dr. Harold Carr, Ph.D., nobody) Nature: Uncategorized Issue Severity: Summary: Portable Interceptors ptc/2000-04-05 21.7.2.7 says that resolve_initial_references is only valid during post_init. This restriction should be removed. Otherwise only local objects may be registered via register_initial_reference in pre_init. To create a non-local object and register it in pre_init one needs a POA which can only be obtained via resolve_initial_references. Prior art: We recently voted in favor of issue 3568 which made it possible to call register_initial_reference in post_init. We should adopt similar wording: if one is looking for other interceptors then resolve should be used in post_init. Resolution: Incorporate change. Revised Text: Remove the first sentence of 21.7.2.7: "This operation is only valid during post_init." Add the following paragraphs following the existing paragraph of 21.7.2.7: If resolve_initial_references is used to obtain a reference to the RootPOA, and new children POAs of that RootPOA are created during pre_init or post_init, then no IORInterceptors are executed for these newly created POAs. Further, regardless of the policy set associated with the these POAs, no components added via IORInfo::add_ior_component or IORInfo::add_ior_component_to_profile will appear in references created by these POAs. Invocations are allowed on references created by these POAs at anytime. If the invocations occur during pre_invoke or post_invoke, then no RequestInterceptors are executed. Actions taken: May 19, 2000: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== Date: Fri, 19 May 2000 10:53:14 -0700 (PDT) Message-Id: <200005191753.KAA03577@shorter.eng.sun.com> From: Harold Carr To: issues@omg.org Subject: resolve_initial_references should be OK in ORBInitInfo::pre_init Content-Type: text X-UIDL: #U$"!93Je9J]0e9%o&!! Portable Interceptors ptc/2000-04-05 21.7.2.7 says that resolve_initial_references is only valid during post_init. This restriction should be removed. Otherwise only local objects may be registered via register_initial_reference in pre_init. To create a non-local object and register it in pre_init one needs a POA which can only be obtained via resolve_initial_references. Prior art: We recently voted in favor of issue 3568 which made it possible to call register_initial_reference in post_init. We should adopt similar wording: if one is looking for other interceptors then resolve should be used in post_init. Sender: jbiggar@corvette.floorboard.com Message-ID: <39259368.717E89C8@floorboard.com> Date: Fri, 19 May 2000 12:18:00 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Harold Carr CC: issues@omg.org Subject: Re: resolve_initial_references should be OK in ORBInitInfo::pre_init References: <200005191753.KAA03577@shorter.eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: LD>e950K!!1\L!!m4Fe9 Harold Carr wrote: > > Portable Interceptors ptc/2000-04-05 21.7.2.7 says that > resolve_initial_references is only valid during post_init. This > restriction should be removed. > > Otherwise only local objects may be registered via > register_initial_reference in pre_init. To create a non-local object > and register it in pre_init one needs a POA which can only be obtained > via resolve_initial_references. > > Prior art: We recently voted in favor of issue 3568 which made it > possible to call register_initial_reference in post_init. We should > adopt similar wording: if one is looking for other interceptors then > resolve should be used in post_init. I'm afraid this is a very bad idea, since the implications of this change are that POAs could be created before all Interceptors were registered. This means very nasty initialization order problems that can't be resolved. A better solution would be to change the register_initial_reference operation to register a factory rather than the direct object reference: module PortableInterceptor { ... local interface ReferenceFactory { Object create_reference(in ObjectId id); }; .... local interface OrbInitInfo { .... void register_initial_reference_factory(in ObjectId id, in ReferenceFactory factory); .... }; }; This defers the actual object reference creation until post_init time, when the ORB can be assumed to be completely initialized and any POAs that are created inside the ReferenceFactory implementation can be properly initialized with all Interceptor behavior. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 19 May 2000 12:30:28 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: interceptors-ftf@omg.org Subject: [Fwd: resolve_initial_references should be OK in ORBInitInfo::pre_init] Content-Type: multipart/mixed; boundary="------------35C30CE16047F3223CC667DC" X-UIDL: F`8!!J5bd9=$,e9$[5e9 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by shorter.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA11847 for ; Fri, 19 May 2000 12:21:08 -0700 (PDT) Received: from sunmail1.Sun.COM (sunmail1 [129.145.1.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA12416 for ; Fri, 19 May 2000 12:21:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id MAA05904 for ; Fri, 19 May 2000 12:21:03 -0700 (PDT) Received: from emerald.omg.org (emerald.omg.org [192.67.184.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16621; Fri, 19 May 2000 13:20:59 -0600 (MDT) Received: from corvette.floorboard.com (corvette.floorboard.com [170.1.176.53]) by emerald.omg.org (8.9.3/8.9.2) with ESMTP id PAA22385 for ; Fri, 19 May 2000 15:18:07 -0400 (EDT) Received: from floorboard.com (jbiggar-u10.cisco.com [171.71.228.71]) by corvette.floorboard.com (8.8.8+Sun/8.8.8) with ESMTP id MAA19581; Fri, 19 May 2000 12:11:04 -0700 (PDT) Sender: jbiggar@corvette.floorboard.com Message-ID: <39259368.717E89C8@floorboard.com> Date: Fri, 19 May 2000 12:18:00 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Harold Carr CC: issues@omg.org Subject: Re: resolve_initial_references should be OK in ORBInitInfo::pre_init References: <200005191753.KAA03577@shorter.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Harold Carr wrote: > > Portable Interceptors ptc/2000-04-05 21.7.2.7 says that > resolve_initial_references is only valid during post_init. This > restriction should be removed. > > Otherwise only local objects may be registered via > register_initial_reference in pre_init. To create a non-local object > and register it in pre_init one needs a POA which can only be obtained > via resolve_initial_references. > > Prior art: We recently voted in favor of issue 3568 which made it > possible to call register_initial_reference in post_init. We should > adopt similar wording: if one is looking for other interceptors then > resolve should be used in post_init. I'm afraid this is a very bad idea, since the implications of this change are that POAs could be created before all Interceptors were registered. This means very nasty initialization order problems that can't be resolved. A better solution would be to change the register_initial_reference operation to register a factory rather than the direct object reference: module PortableInterceptor { ... local interface ReferenceFactory { Object create_reference(in ObjectId id); }; .... local interface OrbInitInfo { .... void register_initial_reference_factory(in ObjectId id, in ReferenceFactory factory); .... }; }; This defers the actual object reference creation until post_init time, when the ORB can be assumed to be completely initialized and any POAs that are created inside the ReferenceFactory implementation can be properly initialized with all Interceptor behavior. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 23 May 2000 09:58:02 -0700 (PDT) Message-Id: <200005231658.JAA04248@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org Subject: Issue 3625/3628: resolve OK in pre_init Content-Type: text X-UIDL: :(M!!^f!e9UUc!!@>2!! In issue 3625/3628 I suggested that resolve_initial_references should be allowed in pre_init so that one could get hold of the root POA to allow one to create references to be registered via register_initial_reference (otherwise only local objects could be created and registered). Jon Biggar pointed out: the implications of this change are that POAs could be created before all Interceptors were registered. This means very nasty initialization order problems that can't be resolved. A better solution would be to change the register_initial_reference operation to register a factory rather than the direct object reference: module PortableInterceptor { ... local interface ReferenceFactory { Object create_reference(in ObjectId id); }; .... local interface OrbInitInfo { .... void register_initial_reference_factory(in ObjectId id, in ReferenceFactory factory); .... }; }; This defers the actual object reference creation until post_init time, when the ORB can be assumed to be completely initialized and any POAs that are created inside the ReferenceFactory implementation can be properly initialized with all Interceptor behavior. ----- To be sure I understand Jon correctly, do you mean that the ORB would call the factory with the ObjectId between pre_init and post_init AND register the resulting object in initial references? This solution implies that all IORInterceptors would need to be registered in pre_init if they want to effect references created by the factory. But if these interceptors need to obtain initial references supplied by other services they would need to register themselves during post_init - chicken and egg problem. Also, for this solution to work would require language in the spec which would say that IORInterceptors would be enabled after pre_init and before post_init. The spec currently says that registered *RequestInterceptors are not enabled until after post_init. Is there then a conflict if we were to allow IORInterceptors to run as stated above? I think it would be simpler and more consistent to follow the model we already have: registered interceptors are not enabled until after post_init. Therefore if one makes an ORB-mediated call from within an ORBInitializer no request interceptors are invoked. Similarly, if one creates a POA within an ORBInitializer no IORInterceptors are invoked. Cheers, Harold From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Issue 3625/3628: resolve OK in pre_init Date: Tue, 23 May 2000 17:59:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ,;a!!~F*!!+$Fe9Km"e9 > From: Harold Carr [mailto:harold.carr@eng.sun.com] > I think it would be simpler and more consistent to follow the model we > already have: registered interceptors are not enabled until after > post_init. Therefore if one makes an ORB-mediated call from within an > ORBInitializer no request interceptors are invoked. Similarly, if one > creates a POA within an ORBInitializer no IORInterceptors are invoked. These aren't analogous cases. The orb mediated call is complete before initialization is completed. But the POA that is created without IORInterceptors, it remains and continues to be usable after initialization. This seems like a bad situation. Paul Date: Tue, 23 May 2000 15:42:03 -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: Issue 3625/3628: resolve OK in pre_init References: <9B164B713EE9D211B6DC0090273CEEA926BEB8@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: <+^d9 Paul, That is true. However, I would imagine that any POA's created inside of ORBInitializer would probably not be widely exposed. Usage guidelines would simply say to either use the rootPOA, or, if you do create a POA you should probably restrict its usage to just creating some references for initial references and nothing more. What is the alternative? I already pointed out a chicken-and-egg problem with Jon's solution. H Paul Kyzivat wrote: > > > From: Harold Carr [mailto:harold.carr@eng.sun.com] > > > I think it would be simpler and more consistent to follow the model we > > already have: registered interceptors are not enabled until after > > post_init. Therefore if one makes an ORB-mediated call from within an > > ORBInitializer no request interceptors are invoked. Similarly, if one > > creates a POA within an ORBInitializer no IORInterceptors are invoked. > > These aren't analogous cases. The orb mediated call is complete before > initialization is completed. But the POA that is created without > IORInterceptors, it remains and continues to be usable after initialization. > This seems like a bad situation. > > Paul Date: Wed, 19 Jul 2000 11:15:25 -0700 (PDT) Message-Id: <200007191815.LAA20904@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org Subject: Issue 3625: resolve_initial_references should be OK in ORBInitInfo::pre_init Content-Type: text X-UIDL: n`m!!OE*e9PLXd9:$"!! I raised this issue a while back: Portable Interceptors ptc/2000-04-05 21.7.2.7 says that resolve_initial_references is only valid during post_init. This restriction should be removed. Otherwise only local objects may be registered via register_initial_reference in pre_init. To create a non-local object and register it in pre_init one needs a POA which can only be obtained via resolve_initial_references. See http://cgi.omg.org/issues/issue3625.txt for the discussion thread. Basically I am still in favor of the simple solution - just allow resolve in pre_init. If POAs are created/used inside pre_init and post_init no IORInterceptors would be run. However, since everyone seems to favor the "unique policy set" solution we would have to answer the question: after ORB_init returns, if any of the POAs created inside pre/post_init happen to have the same policy set which causes a subsequent IORInterceptor activation, would the components established retroactively apply to any references subsequently created by that POA? I would say no. Cheers, Harold Date: Wed, 19 Jul 2000 11:15:41 -0700 (PDT) Message-Id: <200007191815.LAA20928@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org Subject: Issue 3625: resolve_initial_references should be OK in ORBInitInfo::pre_init Content-Type: text X-UIDL: 64:!!SdNe9Y+"!!BU5e9 I raised this issue a while back: Portable Interceptors ptc/2000-04-05 21.7.2.7 says that resolve_initial_references is only valid during post_init. This restriction should be removed. Otherwise only local objects may be registered via register_initial_reference in pre_init. To create a non-local object and register it in pre_init one needs a POA which can only be obtained via resolve_initial_references. See http://cgi.omg.org/issues/issue3625.txt for the discussion thread. Basically I am still in favor of the simple solution - just allow resolve in pre_init. If POAs are created/used inside pre_init and post_init no IORInterceptors would be run. However, since everyone seems to favor the "unique policy set" solution we would have to answer the question: after ORB_init returns, if any of the POAs created inside pre/post_init happen to have the same policy set which causes a subsequent IORInterceptor activation, would the components established retroactively apply to any references subsequently created by that POA? I would say no. Cheers, Harold