Date: Mon, 17 Jan 2000 12:16:04 -0330 From: Matthew Newhook To: issues@omg.org Subject: Portable Interceptors: object_to_string, string_to_object Message-ID: <20000117121604.B28998@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us Content-Type: text/plain; charset=us-ascii X-UIDL: To: "OMG Interceptors RTF" , "OMG ORB Core RTF" Subject: Issue 3772 (and also PI issues 3403, 3322 and 3429) Date: Thu, 30 Nov 2000 13:12:44 -0000 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 0GL!!M6"!!ccn!!Rb5e9 All, Michi has identified a need for access to a POA's owning ORB (issue 3772). In parallel, members of the Portable Interceptors RTF have identified a need for access to the ORB-being-initialized from an ORBInitInfo (issues 3403, 3429). That would remove the need to duplicate ORB's operations on ORBInitInfo, as we have with e.g. resolve_initial_references() and as Matthew has suggested for object_to_string()/string_to_object() (issue 3332). The obvious approach is to add an operation e.g. "CORBA::ORB the_orb();" just to POA and ORBInitInfo; that stumbles on the fact that ORB is PIDL, not IDL. That leads to the suggestion (issues 3403, 3429) that we convert ORB itself to IDL. However, RTF members are concerned that such a change, unless very carefully managed, would break every CORBA application. We would have to introduce a new ORB type (CORBA_3::ORB?) that coexisted with the old PIDL ORB, probably for a long time. As none of us has yet come up with a concrete proposal, I suggest we pursue Bob Kukura's alternative approach (on issue 3772's thread): to add an ORB accessor to Object. This sidesteps the IDL/PIDL issue, since Object is an IDL keyword but is already defined in PIDL, so this approach doesn't make anything worse. I would suggest the signature "CORBA::ORB _orb();", because it then makes the implementation in Java trivial. All stubs have to extend org.omg.CORBA.portable.ObjectImpl and all local interface implementations have to extend org.omg.CORBA.LocalObject, both of which define such a method. All that needs doing is to add an abstract method (or a non-final one that thoes NO_IMLEMENT to org.omg.CORBA.Object, and we're done. Well, nearly done. We're OK for non-local interfaces, but the one's we're particularly interested in are both local interfaces. I see two options here: (1) In Ch. 4, say that _orb() on local objects is undefined (and may raise NO_IMPLEMENT) unless specified otherwise on particular interfaces, and then call out POA and ORBInitInfo as interfaces where it is defined in Chs. 11 & 21. (2) try to specify what happens based on some broad categories of local objects, of which I see three: - those created necessarily by the ORB vendor (e.g. POA, ORBInitInfo); - those possibly created in an iterceptor (e.g. various interfaces derived from Policy & Current); - those created by application developers (e.g. ServantManagers). (1) is simpler of course, and enough for our immediate needs; we could look to broaden it into (2) later if necessary. How about it? If we think it's worth pursuing, and if I'm in the rechartered ORB RTF, I volunteer to work up a detailed proposal (based on (1), unless there's a clamour for (2)). Regards Nick Nick Sharman Architect, LiveContent BROKER Critical Path UK Tel: +44 (0) 161 333 4073 UK Fax: +44 (0) 161 333 4001 E-mail: mailto:nick.sharman@cp.net Web: http://www.cp.net Date: Thu, 2 May 2002 22:23:50 -0700 (PDT) From: Harold Carr To: corba-rtf@omg.org Subject: Issues 3322, 3403, 3429 PI/ORB/PIDL Hello, Issues 3322, 3403, 3429 all essentially say that interceptors and ORBInitializers need access to the ORB they are associated with. I see two problems: 1. For ORBInitializers it would need to be specified how much of that ORB can be used (since ORBInitializers are executed during ORB.init) or that pre and post_init are the last two things ORB.init does so that it is fully initialized - except interceptors would not be executed is any outcalls occur in an ORBInitializer). The BIGGER problem is: 2. The ORB is PIDL so cannot be given to interceptor local interfaces. There has been much talk in the past on how to solve the ORB/PIDL problem. I think the consensus was to define a new ORB local interface and deprecate the existing ORB/PIDL. You would still do ORB.init and then obtain the local interface ORB via resolve_initial_references. Or something like that. If someone is willing to deal with the ORB/PIDL problem then we can subsequently deal with PI issues 3322, 3403, 3429. Otherwise those issues should be closed no change. Also, it would be good to have use cases for issues 3322, 3403, 3429 - particularly in the transaction and security areas. Cheers, Harold Date: Tue, 29 Oct 2002 17:26:38 -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: Issue 3322 question Issue 3322: Portable Interceptors: object_to_string, string_to_object (interceptors-rtf) Click here for this issue's archive. Source: IONA (Mr. Matthew Newhook, matthew.newhook@iona.com) Nature: Uncategorized Issue Severity: Summary: object_to_string and string_to_object are missing on ORBInitInfo. ___________________________________________________________ Did anyone ever come up with a use-case for these operations in ORBInitInfo? Or can we happily close this issue no change due to lack of use case? I am happy to propose the latter resolution (consider this as such) in order to light the fire under whoever that wants to pursue this issue further. Jishnu. Sender: jbiggar@Resonate.com Date: Tue, 29 Oct 2002 15:23:15 -0800 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: Issue 3322 question Jonathan Biggar wrote: > > Jishnu Mukerji wrote: > > > > Issue 3322: Portable Interceptors: object_to_string, string_to_object > > (interceptors-rtf) > > > > Click here for this issue's archive. > > Source: IONA (Mr. Matthew Newhook, matthew.newhook@iona.com) > > Nature: Uncategorized Issue > > Severity: > > Summary: > > > > object_to_string and string_to_object are missing on ORBInitInfo. > > > > ___________________________________________________________ > > > > Did anyone ever come up with a use-case for these operations in > > ORBInitInfo? Or can we happily close this issue no change due to lack of > > use case? I am happy to propose the latter resolution (consider this as > > such) in order to light the fire under whoever that wants to pursue this > > issue further. > > A use case for string_to_object in an ORBInitializer would be reading a > string form IOR from an argument or file or other stable storage with > the intent to register it with register_initial_reference. Seems to me > to be quite normal and important to be able to do that. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: carr@ha2sca-mail1.SFBay.Sun.COM Date: Mon, 04 Nov 2002 13:36:05 -0800 From: Harold Carr X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: Jonathan Biggar , corba-rtf@omg.org Subject: Re: Issue 3322 question Hello, Jishnu Mukerji wrote: > > Jonathan Biggar wrote: > > > > Jonathan Biggar wrote: > > > > > > Jishnu Mukerji wrote: > > > > > > > > Issue 3322: Portable Interceptors: object_to_string, string_to_object > > > > (interceptors-rtf) > > > > object_to_string and string_to_object are missing on ORBInitInfo. > > > A use case for string_to_object in an ORBInitializer would be reading a > > > string form IOR from an argument or file or other stable storage with > > > the intent to register it with register_initial_reference. Seems to me > > > to be quite normal and important to be able to do that. > > OK, would you or Harold please propose a concrete resolution with > specific text for this one then? I think that this will become a non-issue if R1 gains traction. Then you can just use the ORB obtained from Object (or local object as Ken pointed out in his vote). Cheers, Harold Date: Mon, 04 Nov 2002 17:13:50 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Harold Carr Cc: Jonathan Biggar , corba-rtf@omg.org Subject: Re: Issue 3322 question Harold Carr wrote: > > Hello, > > Jishnu Mukerji wrote: > > > > Jonathan Biggar wrote: > > > > > > Jonathan Biggar wrote: > > > > > > > > Jishnu Mukerji wrote: > > > > > > > > > > Issue 3322: Portable Interceptors: object_to_string, string_to_object > > > > > (interceptors-rtf) > > > > > > object_to_string and string_to_object are missing on ORBInitInfo. > > > > > A use case for string_to_object in an ORBInitializer would be reading a > > > > string form IOR from an argument or file or other stable storage with > > > > the intent to register it with register_initial_reference. Seems to me > > > > to be quite normal and important to be able to do that. > > > > OK, would you or Harold please propose a concrete resolution with > > specific text for this one then? > > I think that this will become a non-issue if R1 gains traction. Then > you can just use the ORB obtained from Object (or local object as Ken > pointed out in his vote). Although, we still need to figure out which operations of the embryonic ORB will actually work when the ORB is obtained from ORBinit, no? So there is still a minor issue, admittedly related to R1. Perhaps we can just clump this one in with R1 too and go with it. Looks like R1 is going to pass. Thanks, Jishnu. Date: Mon, 04 Nov 2002 15:25:25 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: corba-rtf@omg.org Subject: Re: Issue 3322 question Jonathan Biggar wrote: > > Jonathan Biggar wrote: > > > > Jishnu Mukerji wrote: > > > > > > Issue 3322: Portable Interceptors: object_to_string, string_to_object > > > (interceptors-rtf) > > > > > > Click here for this issue's archive. > > > Source: IONA (Mr. Matthew Newhook, matthew.newhook@iona.com) > > > Nature: Uncategorized Issue > > > Severity: > > > Summary: > > > > > > object_to_string and string_to_object are missing on ORBInitInfo. > > > > > > ___________________________________________________________ > > > > > > Did anyone ever come up with a use-case for these operations in > > > ORBInitInfo? Or can we happily close this issue no change due to lack of > > > use case? I am happy to propose the latter resolution (consider this as > > > such) in order to light the fire under whoever that wants to pursue this > > > issue further. > > > > A use case for string_to_object in an ORBInitializer would be reading a > > string form IOR from an argument or file or other stable storage with > > the intent to register it with register_initial_reference. Seems to me > > to be quite normal and important to be able to do that. OK, would you or Harold please propose a concrete resolution with specific text for this one then? 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