Issue 5468: Anys obtained using the singleton ORB (java-rtf) Source: International Business Machines (Ms. Anne E. Collins, nobody) Nature: Uncategorized Issue Severity: Summary: The IDL to Java spec is very clear about what methods can (and by implication what methods can't) be used with the singleton ORB and one of those is create_any(), however it does not mention any restrictions on the use of Anys obtained in this way. I think this leads to some inconsistencies and potential problems, for example: 1. You cannot use create_output_stream() on the singleton ORB but you can use create_output_stream() on an Any obtained from the singleton. Where has this OutputStream come from? Presumably from the Any's singleton ORB (calling the orb() method on that OutputStream would return the ORB). At best this seems inconsistent. 2. The problem is worse if you now marshal an object reference into that OutputStream then call create_input_stream() and try to read back the object reference using a read_Object() call. If the read_Object() is to return an object reference it needs to have an ORB to associate it with, but the only ORB available to it is the original Any's singleton ORB, which cannot support object references. Should this read_Object() succeed or fail? If it should succeed what ORB should it be using? There may be similar problems writing and reading other types to these streams. I feel the spec should state explicitly that operations on an Any created using the singleton ORB will be limited by the restrictions applicable to the singleton ORB. I don't think this would affect the intended use of Anys from the singleton, which is stated as being to describe union labels when creating a union TypeCode. Proposed resolution: Add the following sentence to the end of the subsection "Default initialization" in section 1.21.9.3 ORB Initialization Methods in the IDL to Java spec: Operations on an Any created using the singleton ORB will be limited by the restrictions applicable to the singleton ORB; those which require the use of a fully functional ORB will result in a NO_IMPLEMENT system exception. Resolution: resolved Revised Text: Add the following sentence to the end of the subsection "Default initialization" in section 1.21.9.3 ORB Initialization Methods in the IDL to Java spec: Operations on an Any created using the singleton ORB will be limited by the restrictions applicable to the singleton ORB; those which require the use of a fully functional ORB will result in a NO_IMPLEMENT system exception. Actions taken: July 9, 2002: received issue April 28, 2003: closed issue Discussion: End of Annotations:===== Subject: Anys obtained using the singleton ORB To: issues@omg.org Cc: java-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Ann Dalton1" Date: Tue, 9 Jul 2002 21:51:09 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 09/07/2002 21:50:48 I'd like to raise an issue regarding the use of Anys obtained using the singleton ORB. The IDL to Java spec is very clear about what methods can (and by implication what methods can't) be used with the singleton ORB and one of those is create_any(), however it does not mention any restrictions on the use of Anys obtained in this way. I think this leads to some inconsistencies and potential problems, for example: 1. You cannot use create_output_stream() on the singleton ORB but you can use create_output_stream() on an Any obtained from the singleton. Where has this OutputStream come from? Presumably from the Any's singleton ORB (calling the orb() method on that OutputStream would return the ORB). At best this seems inconsistent. 2. The problem is worse if you now marshal an object reference into that OutputStream then call create_input_stream() and try to read back the object reference using a read_Object() call. If the read_Object() is to return an object reference it needs to have an ORB to associate it with, but the only ORB available to it is the original Any's singleton ORB, which cannot support object references. Should this read_Object() succeed or fail? If it should succeed what ORB should it be using? There may be similar problems writing and reading other types to these streams. I feel the spec should state explicitly that operations on an Any created using the singleton ORB will be limited by the restrictions applicable to the singleton ORB. I don't think this would affect the intended use of Anys from the singleton, which is stated as being to describe union labels when creating a union TypeCode. Proposed resolution: Add the following sentence to the end of the subsection "Default initialization" in section 1.21.9.3 ORB Initialization Methods in the IDL to Java spec: Operations on an Any created using the singleton ORB will be limited by the restrictions applicable to the singleton ORB; those which require the use of a fully functional ORB will result in a NO_IMPLEMENT system exception. Ann Date: Mon, 22 Jul 2002 11:24:42 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Anys obtained using the singleton ORB To: andrew@omg.org, ann_dalton@uk.ibm.com Cc: Ken.Cavanaugh@sun.com, java-rtf@omg.org, harold.carr@sun.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc While I still agree that there is an issue here that needs to be resolved, it turns out that there are more issues to consider. The singelton ORB specification is old, and predates a number of general CORBA additions, especially Portable Interceptors. Portable Interceptors has created a number of new contexts in which Anys are required, particularly in supporting codecs (and the slots in PICurrent, but this is less relevant). The code in an ORBInitializer runs in a special environment: it does not have access to a normal ORB object. It only has restricted access to a partially initialized ORB through the ORBInitInfo interface (which is typically a facade over the partially initialized ORB) and the singleton ORB. However, the code in an ORBInitializer may need to create Anys. To do this, the code must currently (in Java) call one of the ORB.init(...) methods. Creating a full ORB in this context is not a good idea: if the ORBInitializer is specified through a system property, creating a full ORB inside an ORBInitializer will cause the nested ORB to attempt to initialize its interceptors, which calls the ORBInitializer, which creates an ORB,... leading to an infinite recursion. This leaves no choice but to use the singleton ORB (which never initializes interceptors) with the current specification. I see broadly two ways to proceed here: 1. Do not restrict anys on the singleton ORB at all, but rather require that singleton ORB created Anys fully support all data types. This will require directly addressing the issues the Ann originally wanted to avoid. 2. Restrict the singleton ORB created Anys, and provide an alternate means for PI to create Anys. There are a couple of possibilities here: a. Add create_any and create_xxx_typecode methods to ORBInitInfo. This is probably doable, but really make ORBInitInfo look more and more like the IDL version of the ORB PIDL. b. Finally agree to solve the ORB PIDL problem and provide a (perhaps mapping specific?) version of the ORB PIDL as IDL that then allows ORBInitInfo to be replaced by the IDL ORB. This has been discussed many times in the PI context, but problems with backward compatibility or duplicate/confusing APIs have so far prevented a solution. I think the current resolution that Ann wrote (and I contributed to as well) is deficient, and these issues must be considered. Also, it is not clear to me that this needs to be an urgent issue, on further reflection. Ann, I think your main problem is the JCK tests. It seems that the tests should probably be waived due to an ambiguity in the specification. That's a discussion for the JCK team, rather than the Java RTF. Ken. From: Jeffrey Mischkinsky Subject: Re: Anys obtained using the singleton ORB To: Ken.Cavanaugh@Sun.COM Date: Mon, 22 Jul 2002 11:46:28 -0700 (PDT) Cc: andrew@omg.org, ann_dalton@uk.ibm.com, java-rtf@omg.org, harold.carr@Sun.COM X-Mailer: ELM [version 2.5 PL2] 'Ken Cavanaugh' writes: > > > b. Finally agree to solve the ORB PIDL problem and provide a (perhaps > mapping specific?) version of the ORB PIDL as IDL that then allows > ORBInitInfo to be replaced by the IDL ORB. This has been discussed > many times in the PI context, but problems with backward compatibility or > duplicate/confusing APIs have so far prevented a solution. > > I think the current resolution that Ann wrote (and I contributed to as well) is deficient, > and these issues must be considered. I've never understood or agreeed that there are problems with backwards compatiblity if a new api is added. The duplicate/confusing APIs argument also haven't made much sense to me. The api's have to be similar/duplicate simply because essentially the same functions are being added, only as real IDL. I still maintain the simplest solution is to add one more operation to the PIDL ORB to return a bonafide IDL interface reference to an IDL object (the IDL'd ORB) which provides those operations which we deem are necessary. It's true most of them will be look like duplicates of the PIDL ORB operations, but that's because they really are.. and in most cases the implementation will simply be a wrapper off the already existing code. Just my $.02. And since I don't work for an ORB vendor, it may in fact be worth consierably less. :-) jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff.mischkinsky@oracle.com +1 650-506-1975 Date: Mon, 22 Jul 2002 12:19:34 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Anys obtained using the singleton ORB To: Ken.Cavanaugh@Sun.COM, jmischki@wheel.dcn.davis.ca.us Cc: andrew@omg.org, ann_dalton@uk.ibm.com, java-rtf@omg.org, harold.carr@Sun.COM X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >From: Jeffrey Mischkinsky >Subject: Re: Anys obtained using the singleton ORB >To: Ken.Cavanaugh@Sun.COM >Cc: andrew@omg.org, ann_dalton@uk.ibm.com, java-rtf@omg.org, >harold.carr@Sun.COM >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit > >'Ken Cavanaugh' writes: >> >> >> b. Finally agree to solve the ORB PIDL problem and provide a >(perhaps >> mapping specific?) version of the ORB PIDL as IDL that then >allows >> ORBInitInfo to be replaced by the IDL ORB. This has been >discussed >> many times in the PI context, but problems with backward >compatibility or >> duplicate/confusing APIs have so far prevented a solution. >> >> I think the current resolution that Ann wrote (and I contributed to >as well) is deficient, >> and these issues must be considered. > > >I've never understood or agreeed that there are problems with >backwards >compatiblity if a new api is added. >The duplicate/confusing APIs argument also haven't made much sense to >me. >The api's have to be similar/duplicate simply because essentially the >same >functions are being added, only as real IDL. > I still maintain the simplest solution is to add one more operation > to the PIDL ORB to return a bonafide IDL interface reference to an > IDL object (the IDL'd ORB) which provides those operations which we >deem > are necessary. It's true most of them will be look like duplicates >of the > PIDL ORB operations, but that's because they really are.. and in >most > cases the implementation will simply be a wrapper off the already >existing > code. > > Just my $.02. And since I don't work for an ORB vendor, it may in > fact be worth consierably less. :-) > I agree with Jeff: I'm not terribly concerned about the duplicate API argument either. We certainly could define a common ORB subset IDL definition that can be shared across all language mappings, that would be useful for exactly the sort of problem being discussed. In fact, this might not be much different than simply adding the any and typecode methods to ORBInitInfo. In any case, we (java and perhaps core RTF members) need to decide how to solve these problem. Solving the ORB IDL problem as a side effect would have other benefits too. Ken. Date: Tue, 23 Jul 2002 11:48:08 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: isue5468 -- Java RTF issue To: java-rtf@omg.org Cc: ken.cavanaugh@sun.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Just to make sure the discussion is associated with this issue, here is a slightly edited version of the email I sent yesterday: --------------------------------------------------------------- It turns out that there are more issues to consider than those that Ann included in the original post for this issue. The singelton ORB specification is old, and predates a number of general CORBA additions, especially Portable Interceptors. Portable Interceptors has created a number of new contexts in which Anys are required, particularly in supporting codecs (and the slots in PICurrent, but this is less relevant). The code in an ORBInitializer runs in a special environment: it does not have access to a normal ORB object. It only has restricted access to a partially initialized ORB through the ORBInitInfo interface (which is typically a facade over the partially initialized ORB) and the singleton ORB. However, the code in an ORBInitializer may need to create Anys. To do this, the code must currently (in Java) call one of the ORB.init(...) methods. Creating a full ORB in this context is not a good idea: if the ORBInitializer is specified through a system property, creating a full ORB inside an ORBInitializer will cause the nested ORB to attempt to initialize its interceptors, which calls the ORBInitializer, which creates an ORB,... leading to an infinite recursion. This leaves no choice but to use the singleton ORB (which never initializes interceptors) with the current specification. I see broadly two ways to proceed here: 1. Do not restrict anys on the singleton ORB at all, but rather require that singleton ORB created Anys fully support all data types. This will require directly addressing the issues the Ann originally wanted to avoid. 2. Restrict the singleton ORB created Anys, and provide an alternate means for PI to create Anys. There are a couple of possibilities here: a. Add create_any and create_xxx_typecode methods to ORBInitInfo. This is probably doable, but really make ORBInitInfo look more and more like the IDL version of the ORB PIDL. b. Finally agree to solve the ORB PIDL problem and provide a (perhaps mapping specific?) version of the ORB PIDL as IDL that then allows ORBInitInfo to be replaced by the IDL ORB. This has been discussed many times in the PI context, but problems with backward compatibility or duplicate/confusing APIs have so far prevented a solution. I think the current resolution that Ann wrote (and I contributed to as well) is deficient, and these issues must be considered. Ken.