Issue 3109: DynAny & abstract interfaces don't mix! (orb_revision) Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com) Nature: Uncategorized Issue Severity: Summary: Section 9.2.2 states: "The operation raises InconsistentTypeCode if value has a TypeCode with a TCKind of tk_Principal, tk_native, or tk_abstract_interface." This is totally broken for abstract interfaces. What happens if I do this: // IDL abstract interface I { }; struct S { I an_i; }; // C++ S mys; CORBA::Any a; a <<= s; DynamicAny::DynAnyFactory_var daf = ...; DynamicAny::DynAny_var da = daf->create_dyn_any(a); DynamicAny::DynAny_var component = da->current_component(); Obviously the value of component must be meaningful, otherwise there is no way to examine or construct a value of type S. Resolution: Revised Text: Actions taken: December 10, 1999: received issue October 30, 2000: closed issue Discussion: End of Annotations:===== ender: jbiggar@floorboard.com Message-ID: <38516E25.8CE20B9B@floorboard.com> Date: Fri, 10 Dec 1999 13:18:29 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org, orb_revision@omg.org Subject: DynAny & abstract interfaces don't mix! Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: A!:!!fe)!!nEG!!RjV!! Section 9.2.2 states: "The operation raises InconsistentTypeCode if value has a TypeCode with a TCKind of tk_Principal, tk_native, or tk_abstract_interface." This is totally broken for abstract interfaces. What happens if I do this: // IDL abstract interface I { }; struct S { I an_i; }; // C++ S mys; CORBA::Any a; a <<= s; DynamicAny::DynAnyFactory_var daf = ...; DynamicAny::DynAny_var da = daf->create_dyn_any(a); DynamicAny::DynAny_var component = da->current_component(); Obviously the value of component must be meaningful, otherwise there is no way to examine or construct a value of type S. Clearly the statement in 9.2.2 needs to be changed to allow tk_abstract_interface, and insert_abstract() and get_abstract() operations must be added to DynAny. Proposal: 1. Rewrite the sentence in 9.2.2 to state: "The operation raises InconsistentTypeCode if value has a TypeCode with a TCKind of tk_Principal, tk_native." 2. Add the following operations to DynAny: local interface DynAny { ... void insert_abstract(in CORBA::AbstractBase value) raises(TypeMismatch, InvalidValue); ... CORBA::AbstractBase get_abstract() raises(TypeMismatch, InvalidValue); ... }; Question: is there a versioning problem adding operations to a local interface? I don't think the problems are nearly as severe, since nothing is ever marshalled on the wire. Can we get away with just adding operations without doing the usual derive and extend dance? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jbiggar@floorboard.com Message-ID: <3855432E.7D26200F@floorboard.com> Date: Mon, 13 Dec 1999 11:04:14 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Subject: Straw poll about versioning of local interfaces Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: \j0!!M14e9h\$e9@XPe9 I'd like to bring up this question that I posted at the end of issue 3109 and see what the RTF members opinion on it is: Is there a versioning problem adding operations to a local interface? I don't think the problems are nearly as severe as we are seeing with the IFR, for example, since nothing is ever marshalled on the wire. Can we get away with just adding operations without doing the usual derive and extend dance? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 14 Dec 1999 06:56:45 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: orb_revision@omg.org Subject: Re: Straw poll about versioning of local interfaces In-Reply-To: <3855432E.7D26200F@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ?]kd9m9]d95WE!!LgQ!! On Mon, 13 Dec 1999, Jonathan Biggar wrote: > I'd like to bring up this question that I posted at the end of issue > 3109 and see what the RTF members opinion on it is: > > Is there a versioning problem adding operations to a local > interface? I > don't think the problems are nearly as severe as we are seeing with > the > IFR, for example, since nothing is ever marshalled on the wire. Can > we > get away with just adding operations without doing the usual derive > and > extend dance? I think that, for local interfaces, you can get away with this. In effect, adding a new operation to a local interface is the same as adding a new function to a header file. The only glitch is that local interfaces are in the IFR... This means that there could be multiple, different versions of the same interface in a CORBA domain, depending on whose IFR I end up with... 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 Date: Mon, 13 Dec 1999 19:02:55 -0800 From: Vijaykumar Natarajan Reply-To: vijayn@inprise.com Organization: Inprise Corporation X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Jonathan Biggar , orb_revision@omg.org Subject: Re: Straw poll about versioning of local interfaces References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: mRNd9lW_!!EHGe9nV4e9 I am not really sure one can get away with just adding operations. Consider the local interface is part of an ORB interface to services. Wouldn't plugging in services just not be possible as the service may be relying on the local interface as the point of interaction with the ORB. The service definition of the interface may be different from the ORB definition of the local interface and there would be no way for the service to distinguish between the two. Vijay Michi Henning wrote: > On Mon, 13 Dec 1999, Jonathan Biggar wrote: > > > I'd like to bring up this question that I posted at the end of issue > > 3109 and see what the RTF members opinion on it is: > > > > Is there a versioning problem adding operations to a local interface? I > > don't think the problems are nearly as severe as we are seeing with the > > IFR, for example, since nothing is ever marshalled on the wire. Can we > > get away with just adding operations without doing the usual derive and > > extend dance? > > I think that, for local interfaces, you can get away with this. In effect, > adding a new operation to a local interface is the same as adding a new > function to a header file. The only glitch is that local interfaces are > in the IFR... This means that there could be multiple, different versions > of the same interface in a CORBA domain, depending on whose IFR I end up > with... > > 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 Sender: jon@floorboard.com Message-ID: <3855BEC5.4CDC3C9D@floorboard.com> Date: Mon, 13 Dec 1999 19:51:33 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: vijayn@inprise.com CC: Michi Henning , orb_revision@omg.org Subject: Re: Straw poll about versioning of local interfaces References: <3855B35F.EAD45679@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ~Q#e9Q;?!!EE!!!l2 > I am not really sure one can get away with just adding > operations. Consider the local interface is part of an ORB interface > to services. Wouldn't plugging in services just not be possible as > the service may be relying on the local interface as the point of > interaction with the ORB. The service definition of the interface > may be different from the ORB definition of the local interface and > there would be no way for the service to distinguish between the > two. Ok, my unscientific poll suggests we are split over whether to allow this. As a particular point in example, I proposed adding two operations to DynamicAny::DynAny, namely insert_abstract() and get_abstract(). To do this the "right" way, I have to: import DynamicAny; module DynamicAny_X_Y { interface DynamicAny : DynamicAny::Any { void insert_abstract(CORBA::AbstractBase) raises(...); CORBA::AbstractBase get_abstract() raises(...); }; }; All good so far, but the usage case is nasty. Whenever I want to use these operations, I must explictly narrow a DynamicAny::DynAny to a DynamicAny_X_Y::DynAny. This can get pretty gross when we add a few more revisions... However, I do understand the versioning problem with mismatched ORB and application, in particular the Java problem, although probably not as well as I ought to. So for you Java gurus, is there any solution to the problem better than the above? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jbiggar@floorboard.com Message-ID: <38582999.AAC4901E@floorboard.com> Date: Wed, 15 Dec 1999 15:51:53 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: orb_revision@omg.org Subject: Re: A quick status check References: <3857E83D.5EB4E294@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: "?Rd9P:\d9DA`!!FWK!! Jishnu Mukerji wrote: > 3109 (DynAny and abstract interface) if I get final text from Jon. Here is a recap of the proposal: 1. Rewrite the sentence in 9.2.2 from: "The operation raises InconsistentTypeCode if value has a TypeCode with a TCKind of tk_Principal, tk_native, or tk_abstract_interface." to: "The operation raises InconsistentTypeCode if value has a TypeCode with a TCKind of tk_Principal, tk_native." 2. Add the following operations to DynAny: local interface DynAny { ... void insert_abstract(in CORBA::AbstractBase value) raises(TypeMismatch, InvalidValue); ... CORBA::AbstractBase get_abstract() raises(TypeMismatch, InvalidValue); ... }; [ There is no extra text describing each of the insert_* and get_* operations in detail, only ones that need exceptional treatment, so this proposal has no text to describe insert_abstract & get_abstract.] -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org