Date: Mon, 28 Aug 2000 09:38:02 -0230 From: Matthew Newhook To: interceptors-ftf@omg.org Subject: no way to register value factory from ORB initializer Message-ID: <20000828093802.A19934@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us Content-Type: text/plain; charset=us-ascii X-UIDL: TEcd9bb:e9Dpa!!0[ Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: 3793 Discussion What do we do about this one? Add ValueFactory register_value_factory( in RepositoryId id, in ValueFactory_factory ); to ORB initializer? Or punt? Thanks, Jishnu. ______________________________________________________________________ Issue 3793: no way to register value factory from ORB initializer (interceptors-rtf) Click here for this issue's archive. Source: IONA (Mr. Matthew Newhook, matthew.newhook@iona.com) Nature: Uncategorized Issue Severity: Summary: There is currently no way to register a value factory from an ORB initializer. Sender: jbiggar@Resonate.com Date: Thu, 24 Oct 2002 14:32:33 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: corba-rtf@omg.org Subject: Re: 3793 Discussion Jishnu Mukerji wrote: > > What do we do about this one? Add > > ValueFactory register_value_factory( > in RepositoryId id, > in ValueFactory_factory > ); > > to ORB initializer? Or punt? I'll vote to add it, but to ORBInitInfo, where it belongs. Will we run into IDL version issues like for IORInterceptor? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 24 Oct 2002 22:05:19 +0000 From: Harold Carr X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en To: Michi Henning CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Issues 3793, 3772 and 3403 Discussion hello It would be good to have the ORB available from within interceptors, from within ORBInitializers (although timing good be a sticky point to agree on). That said, putting the accessor on POA::Current would not be too useful. Putting the accessor on the Object interface would probably be most applicable. One could resolve the name service in an initializer then get the ORB from its reference. I'm not sure about IORInterceptors right now, but that would need to be addressed too. Note I've included issue 3793 in this discussion since there would then be no need to add register_value_factory to ORBInitInfo. Cheers, Harold Michi Henning wrote: > > > http://cgi.omg.org/issues/issue3772.txt talk about an ORB accessor on > > the POA interface > > > > http://cgi.omg.org/issues/issue3403.txt talk about PI needing access to > > ORB as an attribute. > > > > The discussion in both got terribly bogged down in PIDL vs. IDL > > philosophy, theology and other esoteric matters. > > > > Reading the vast archive, I get the impression that most of the > > pragmatic needs are adequately addressed by an "ORB" accessor to the > > Object pseudo-interface, and appears to cause relatively little upheaval > > all across the board. > > > > So should we take this on and do it? Or alternatively, should we simply > > punt? Of course, punting is the easiest of them all.:-) > > Well, not surprisingly, I still believe that an ORB accessor would really be > useful. Rather than putting the accessor on the POA or Object interfaces, > I think a better place may be POA::Current. At any rate, an ORB accessor > anywhere is better than none -- and I've been annoyed for years at the > mess my code ends up as because of the inability to get at the ORB. > > The discussions about PIDL vs IDL are academic, IMO. There is no > technical difficulty in providing access to the ORB. > > Cheers, > > Michi. > > -- > Michi Henning Ph: +61 4 1118-2700 > Triodia Technologies http://www.triodia.com/staff/michi Date: Mon, 28 Oct 2002 16:29:17 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Re: Issues 3793, 3772 and 3403 Discussion Harold Carr wrote: > > hello > > It would be good to have the ORB available from within interceptors, > from within ORBInitializers (although timing good be a sticky point to > agree on). That said, putting the accessor on POA::Current would not be > too useful. Putting the accessor on the Object interface would probably > be most applicable. One could resolve the name service in an > initializer then get the ORB from its reference. I'm not sure about > IORInterceptors right now, but that would need to be addressed too. > > Note I've included issue 3793 in this discussion since there would then > be no need to add register_value_factory to ORBInitInfo. So does someone want to take a crack at proposing some concrete text changes for this? Or do we have to wait until either Jon or I can make time?:-) Please use formal/-2-06-01 as the base document for all proposals. Thanks, Jishnu. Sender: jon@floorboard.com Date: Wed, 13 Nov 2002 18:56:28 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: corba-rtf@omg.org Subject: Re: Discussion of Resolution of issues 3403, 3772, 3793 and 3322 Jishnu Mukerji wrote: > > OK, now for the tough one. Here is a rough outline upon which to build > the resolution that fixes all of those ORB accessor related issue, i.e. > issues 3403, 3772, 3793 and 3322. > > I need help in nailing down the changes in the Portable Interceptor > chapter. The POA Chapter changes should be pretty straightforward. > Basically any help in completing items 4, 5 and 6 below would be most > appreciated. What else do we need to tweak? Comments inline. > ________________________________________________________________________ > Resolution: Access to ORB is to be provided by adding an ORB accessor > operation to the Object interface. This has the virtue of keeping the > PIDL-ness of the ORB contained by the PIDL-ness of the Object interface, > and yet allows straightforward way of providing access to the ORB from > any object local or otherwise. > > Since both PI and POA are local interfaces, this automatically provides > a means of accessing the ORB from these, and consequently also provides > a means for getting access to all ORB operations from these local > objects and hence addresses the concerns raised in issues 3403, 3793 and > 3322. So all these issues should be resolved in a single block and > closed simultaneously with this issue. > > This resolution will require the definition f language mapping of the > new extended Object interface. The resolution of this issue shall be > conditional upon the availability of at least one language mapping for > the extended Object interface. > > Revised Text: In formal/02-06-01 make the following changes: > > 1. In the IDL for interface Object at its end on page 4-14 immediately > following the line that reads: > > "Object get_component ();" > > insert the following line of IDL: > > "ORB get_ORB();" OK. > 2. Insert the following section immediately following section 4.3.12, > and bu,ping the following section numbers up by one: > > "4.3.13 Getting the ORB > > ORB get_ORB(); > > This operation returns the local ORB that is handling this particular > Object Reference. For certain local objects this operation returns an > ORB as documented in section 4.3.14. For the rest it returns > OBJECT_NOT_EXIST with standard minor code X1." Should we assume that the default for local objects is that they *have* an ORB or that they *do not have* an ORB? Or do we need to check specifically on a case by case basis? Or perhaps the best way is by rule: local objects that are explicitly created in user code have no ORB associated with them, local objects created by the ORB implementation *do* have an ORB associated with them. I think this gets the answer right for the PortableServer and PortableInterceptor local objects. It also has an added bonus that existing language binding mechanisms for creating local objects won't become obsolete. > 3. In old section 4.3.13 "LocalObject" in the bullet list under the > second bullet add the line: > > " o get_ORB - returns the ORB as documented for certain specific > local objects, and for the rest returns the system exception > OBJECT_NOT_EXIST with standard minor code X1." > > 4. In appendix section A.5 add a new minor code X1 to OBJECT_NOT_EXIST > which says "There is no meaningful association of an ORB with this local > object." > > 5. In the POA Chapter document the fact that the get_ORB operation for > the POA returns the ORB that the POA is associated with. And all other local objects in PortableServer except for AdapterActivator, ServantManager, ServantActivator and ServantLocator. > 6. In the Portable Interceptor chapter document the fact that the > get_ORB operation associated with any Interceptor returns the ORB that > the interceptor is managed by. Not quite. There will be no ORB associated with the *Interceptor, PolicyFactory, or ORBInitializer interfaces. There can be an ORB associated with all of the *Info and Current interfaces. > Specify which operations of the ORB are > available for use at what time using this reference that is returned > in > a PI. This is the sticky one. > 7. Specify any other changes that need to be made in Chapter 21 Portable > Interceptors to integrate the ORB returned from the Portable > Interceptor interface. > > Actions taken: Resolve and close this issue simultaneously with 3403, > 3793 and 3322 subject to the availability of at least one language > mapping for the new accessor operation. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 13 Nov 2002 18:08:11 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Discussion of Resolution of issues 3403, 3772, 3793 and 3322 OK, now for the tough one. Here is a rough outline upon which to build the resolution that fixes all of those ORB accessor related issue, i.e. issues 3403, 3772, 3793 and 3322. I need help in nailing down the changes in the Portable Interceptor chapter. The POA Chapter changes should be pretty straightforward. Basically any help in completing items 4, 5 and 6 below would be most appreciated. What else do we need to tweak? Thanks, Jishnu. ________________________________________________________________________ Resolution: Access to ORB is to be provided by adding an ORB accessor operation to the Object interface. This has the virtue of keeping the PIDL-ness of the ORB contained by the PIDL-ness of the Object interface, and yet allows straightforward way of providing access to the ORB from any object local or otherwise. Since both PI and POA are local interfaces, this automatically provides a means of accessing the ORB from these, and consequently also provides a means for getting access to all ORB operations from these local objects and hence addresses the concerns raised in issues 3403, 3793 and 3322. So all these issues should be resolved in a single block and closed simultaneously with this issue. This resolution will require the definition f language mapping of the new extended Object interface. The resolution of this issue shall be conditional upon the availability of at least one language mapping for the extended Object interface. Revised Text: In formal/02-06-01 make the following changes: 1. In the IDL for interface Object at its end on page 4-14 immediately following the line that reads: "Object get_component ();" insert the following line of IDL: "ORB get_ORB();" 2. Insert the following section immediately following section 4.3.12, and bu,ping the following section numbers up by one: "4.3.13 Getting the ORB ORB get_ORB(); This operation returns the local ORB that is handling this particular Object Reference. For certain local objects this operation returns an ORB as documented in section 4.3.14. For the rest it returns OBJECT_NOT_EXIST with standard minor code X1." 3. In old section 4.3.13 "LocalObject" in the bullet list under the second bullet add the line: " o get_ORB - returns the ORB as documented for certain specific local objects, and for the rest returns the system exception OBJECT_NOT_EXIST with standard minor code X1." 4. In appendix section A.5 add a new minor code X1 to OBJECT_NOT_EXIST which says "There is no meaningful association of an ORB with this local object." 5. In the POA Chapter document the fact that the get_ORB operation for the POA returns the ORB that the POA is associated with. 6. In the Portable Interceptor chapter document the fact that the get_ORB operation associated with any Interceptor returns the ORB that the interceptor is managed by. Specify which operations of the ORB are available for use at what time using this reference that is returned in a PI. 7. Specify any other changes that need to be made in Chapter 21 Portable Interceptors to integrate the ORB returned from the Portable Interceptor interface. Actions taken: Resolve and close this issue simultaneously with 3403, 3793 and 3322 subject to the availability of at least one language mapping for the new accessor operation. Date: Thu, 14 Nov 2002 03:02:50 +0000 From: Harold Carr X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en To: Jonathan Biggar CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Discussion of Resolution of issues 3403, 3772, 3793 and 3322 > > Specify which operations of the ORB are > > available for use at what time using this reference that is > > returned in > > a PI. > > This is the sticky one. For *RequestInterceptors I'd be happy to just say all operations are available (of course, register_initial_reference is already NOT available on ORBInitInfo, so it's not that easy). I think it is harder for IORInterceptors since what they do comes earlier in the initialization process. H Sender: jon@floorboard.com Date: Wed, 13 Nov 2002 19:49:07 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: Harold Carr CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Discussion of Resolution of issues 3403, 3772, 3793 and 3322 Harold Carr wrote: > > > > Specify which operations of the ORB are > > > available for use at what time using this reference that is returned in > > > a PI. > > > > This is the sticky one. > > For *RequestInterceptors I'd be happy to just say all operations are > available (of course, register_initial_reference is already NOT > available on ORBInitInfo, so it's not that easy). > > I think it is harder for IORInterceptors since what they do comes > earlier in the initialization process. Not inevitably. I would expect a "normal" ORB implementation strategy to not create the RootPOA until the client asks for its reference, and I wouldn't expect the IORInterceptor to run until that time. That would seem to be after all ORBInitializer::pre_init calls are complete, no? And since Interceptors aren't formally installed into the ORB until after post_init is called, doesn't that mean that the first time that an IORInterceptor can run is *after* ORB_init returns? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 13 Nov 2002 21:21:14 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Discussion of Resolution of issues 3403, 3772, 3793 and 3322 To: jishnu@hp.com, jon@floorboard.com Cc: corba-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >From: Jonathan Biggar >X-Accept-Language: en >MIME-Version: 1.0 >To: Jishnu Mukerji >CC: corba-rtf@omg.org >Subject: Re: Discussion of Resolution of issues 3403, 3772, 3793 and >3322 >Content-Transfer-Encoding: 7bit > > >> 2. Insert the following section immediately following section 4.3.12, >> and bu,ping the following section numbers up by one: >> >> "4.3.13 Getting the ORB >> >> ORB get_ORB(); >> >> This operation returns the local ORB that is handling this particular >> Object Reference. For certain local objects this operation returns an >> ORB as documented in section 4.3.14. For the rest it returns >> OBJECT_NOT_EXIST with standard minor code X1." > >Should we assume that the default for local objects is that they *have* >an ORB or that they *do not have* an ORB? Or do we need to check >specifically on a case by case basis? > >Or perhaps the best way is by rule: local objects that are explicitly >created in user code have no ORB associated with them, local objects >created by the ORB implementation *do* have an ORB associated with >them. I think this gets the answer right for the PortableServer and >PortableInterceptor local objects. It also has an added bonus that >existing language binding mechanisms for creating local objects won't >become obsolete. > I would rather not create two different classes of local interface implementations, with one for ordinary users and one for ORB implementors. Instead, I would rather extend the mapping to provide a creation model for local interfaces that supports assigning an ORB to a local object if desired. This can be done quite easily in Java by adding an extra constructor to the generated LocalBase class that takes an ORB as an argument (or we could add a set_ORB method to the base class in the Java mapping). In any case, we will handle that in the Java RTF, but I do not want to create two different models for how local objects are created. We will still need to say which local objects support get_ORB() for all of the local objects. Ken. Date: Thu, 14 Nov 2002 17:08:58 +0000 From: Harold Carr X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en To: Jonathan Biggar CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Discussion of Resolution of issues 3403, 3772, 3793 and 3322 Hello Jonathan, > > For *RequestInterceptors I'd be happy to just say all operations are > > available (of course, register_initial_reference is already NOT > > available on ORBInitInfo, so it's not that easy). > > > > I think it is harder for IORInterceptors since what they do comes > > earlier in the initialization process. > > Not inevitably. I would expect a "normal" ORB implementation strategy > to not create the RootPOA until the client asks for its reference, and I Agreed - that's the way we do it... > wouldn't expect the IORInterceptor to run until that time. That would > seem to be after all ORBInitializer::pre_init calls are complete, no? Originally what I was thinking was that the java to idl mapping has a "full value descriptor" which has an object listening to help with unmarshaling if needed. I was thinking that perhaps that object needed to be created during initialization and thus would need a POA. But the spec doesn't say how that object is implemented - therefore an implementation is free to use a proprietary adapter - thus no need to run IORInterceptors. > > And since Interceptors aren't formally installed into the ORB until > after post_init is called, doesn't that mean that the first time > that an > IORInterceptor can run is *after* ORB_init returns? Yes, that is true. I stand corrected. Thanks, Harold Date: Wed, 27 Nov 2002 13:28:53 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: CORBA Core RTF Subject: Discussion of sense of RTF issues so far So far we have voted on 4 sense of RTF issues. Here is a little update on what follows from those: 1. R1: Issues dealing with making ORB available to POA, PIs and Access to ValueFactory from PI. related issues: Issue 3403: PI needs the ORB to be available in IDL (Interceptors) Issue 3772: ORB accessor on POA? Issue 3793: No way to register value factory from ORB initializer (Interceptors) and also 3322. Status: We have been slowly putting together a concrete resolution. It is almost ready to go and should appear in vote 10 or 11. 2. R2 Regarding how to resolve issue 2772 Related Issue 2772 Status: It looks like the general feeling was that 2772 should be fixed as suggested in R2. We are awaiting a concrete draft resolution from Jon Biggar. As soon as it is available we will put it to vote. 3. R3: On the matter of how to resolve Issue 3097. Status: There is considerable reluctance on part of the voters to create a new version of GIOP to solve this problem, even though R3 did pass by a thin margin. But the fact that No's + Abstains outnumber Yesses by a significant margin should give us significant pause before we proceed down the path proposed in R3. We need to decide how to handle this one. Choices are leave it open (least desirable) or close with documentation of the problem in the specification. 4. R4: On the matter of how to resolve Issue 4169. Status: This one passed decisively. Jon had some objections that can probably be mitigated with some thought. It is upto Harold to come up with a complete draft resolution for this, in consultation with Jon. As soon as the draft is available we will put it to vote.