Issue 3358: Python Issue: widening object references and CORBA.Any.value (python-ftf) Source: Camros Corporation (Mr. Jeffrey A. Marshall, jam@camros.com) Nature: Uncategorized Issue Severity: Summary: There is an issue with widening object references using the CORBA.Any.value method. The current spec. states that the value method returns a suitable type of object for the accompanying type of the any. This is an issue when one process sends an object reference which is not staticaly known to the receiving ORB. Resolution: Since there it is not possible to find out anything about the embedded object in the general case, t Revised Text: Since there it is not possible to find out anything about the embedded object in the general case, the implementation can only guarantee to return CORBA.Object. Implementations are certainly free to make stronger guarantees in special cases. Revised Text: In 1.3.9, after the sentence ending "the IDL compiler would have provided", add a sentence An object reference extracted from an Any value must be narrowed before it can be used in an interface-specific operation. Actions taken: February 23, 2000: received issue October 10, 2000: closed issue Discussion: End of Annotations:===== Date: Wed, 23 Feb 2000 23:50:41 -0500 (EST) Message-Id: <200002240450.XAA05581@emerald.omg.org> To: python-ftf@omg.org, issues@omg.org Subject: Python Issue: widening object references and CORBA.Any.value From: "Jeffrey A. Marshall" X-Mailer: TWIG 2.1.1 Content-Type: text X-UIDL: DP9e95*"!!NDg!!K-a!! There is an issue with widening object references using the CORBA.Any.value method. The current spec. states that the value method returns a suitable type of object for the accompanying type of the any. This is an issue when one process sends an object reference which is not staticaly known to the receiving ORB. For example: Foo.idl: interface Base {}; interface Derived : Base {}; Client: derived_ref = get_a_derived_ref_somehow (); v = CORBA.Any (CORBA.TypeCode (Derived), derived_ref) server_ref->do_something (v) Server: def do_something (self, any): base = any.value () Assuming the "Server" process has no compile time knowledge of the "Derived" interface the ORB has a couple of options: - raise a BAD_TYPECODE? - build/load a dynamic stub instance? - return a CORBA.Object? - raise some other exception? The issue here is that either: 1. The semantics of the above scenario should be documented, 2. or that further functionality for widening object references needs to be added to the CORBA.Any class I personally like #2. I don't think this is an issue for unions/sequences/structs/values becuase values of thes types, other than value, are easy to build dynamically and the semantics of value types are well-defined (or well enough defined to solve this problem -- raise an exception if there is no factory!). Another thought is that the programmer must have known what she was asking for if they call the "value" method and therefore we should just raise an exception if the type-code is unknown to this process and a dynamic value can't be built. -jeff -- Jeffrey A. Marshall Camros Corporation Email jam@camros.com Voice 703-876-1700 ext. 10 Fax 703-876-1818 http://www.camros.com/ Sender: jon@corvette.floorboard.com Message-ID: <38B4CA8A.FDE5BD52@floorboard.com> Date: Wed, 23 Feb 2000 22:07:06 -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: "Jeffrey A. Marshall" CC: python-ftf@omg.org Subject: Re: Python Issue: widening object references and CORBA.Any.value References: <200002240450.XAA05584@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: @#;!!bC:e98eQd9Z]8!! "Jeffrey A. Marshall" wrote: > > There is an issue with widening object references using the > CORBA.Any.value > method. The current spec. states that the value method returns a > suitable type > of object for the accompanying type of the any. This is an issue > when one > process sends an object reference which is not staticaly known to > the > receiving ORB. > > For example: > Foo.idl: > interface Base {}; > interface Derived : Base {}; > Client: > derived_ref = get_a_derived_ref_somehow (); > v = CORBA.Any (CORBA.TypeCode (Derived), derived_ref) > server_ref->do_something (v) > Server: > def do_something (self, any): > base = any.value () > > Assuming the "Server" process has no compile time knowledge of the > "Derived" > interface the ORB has a couple of options: > - raise a BAD_TYPECODE? > - build/load a dynamic stub instance? > - return a CORBA.Object? > - raise some other exception? > > The issue here is that either: > 1. The semantics of the above scenario should be documented, > 2. or that further functionality for widening object references > needs to be > added to the CORBA.Any class > > I personally like #2. > > I don't think this is an issue for unions/sequences/structs/values > becuase > values of thes types, other than value, are easy to build > dynamically and the > semantics of value types are well-defined (or well enough defined to > solve > this problem -- raise an exception if there is no factory!). > > Another thought is that the programmer must have known what she was > asking for > if they call the "value" method and therefore we should just raise > an > exception if the type-code is unknown to this process and a dynamic > value > can't be built. The other choice is just to trust that the typecode is correct and use the typecode information to build a stub for the object reference as type Base, despite what the RepositoryId of the actual object reference says. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 24 Feb 2000 02:18:20 -0500 (EST) Message-Id: <200002240718.CAA07734@emerald.omg.org> To: Jonathan Biggar Subject: Re: Python Issue: widening object references and CORBA.Any.value From: "Jeffrey A. Marshall" X-Mailer: TWIG 2.1.1 Cc: python-ftf@omg.org Content-Type: text X-UIDL: _^C!!=7c!!i2Nd93-+!! I agree as stated in my original message that building a stub dynamically is an option -- I just question what the default behavior should be; in most cases consulting the interface repository to build a stub (or stub hierarchy for inherited interfaces) might not be what is desired by developers. Since python has all of the facilities for doing this on the fly, maybe a better question would be whether there should be a "default" way to build types representing IDL constructs programatically. Having a programtic interface allows the developer to decide when to build types (eg. a dynamic_value () method on CORBA.Any)... -jeff Jonathan Biggar said: > "Jeffrey A. Marshall" wrote: > > > > There is an issue with widening object references using the CORBA.Any.value > > method. The current spec. states that the value method returns a > suitable type > > of object for the accompanying type of the any. This is an issue > when one > > process sends an object reference which is not staticaly known to > the > > receiving ORB. > > > > For example: > > Foo.idl: > > interface Base {}; > > interface Derived : Base {}; > > Client: > > derived_ref = get_a_derived_ref_somehow (); > > v = CORBA.Any (CORBA.TypeCode (Derived), derived_ref) > > server_ref->do_something (v) > > Server: > > def do_something (self, any): > > base = any.value () > > > > Assuming the "Server" process has no compile time knowledge of the "Derived" > > interface the ORB has a couple of options: > > - raise a BAD_TYPECODE? > > - build/load a dynamic stub instance? > > - return a CORBA.Object? > > - raise some other exception? > > > > The issue here is that either: > > 1. The semantics of the above scenario should be documented, > > 2. or that further functionality for widening object references > needs to be > > added to the CORBA.Any class > > > > I personally like #2. > > > > I don't think this is an issue for unions/sequences/structs/values > becuase > > values of thes types, other than value, are easy to build > dynamically and the > > semantics of value types are well-defined (or well enough defined > to solve > > this problem -- raise an exception if there is no factory!). > > > > Another thought is that the programmer must have known what she > was asking for > > if they call the "value" method and therefore we should just raise > an > > exception if the type-code is unknown to this process and a > dynamic value > > can't be built. > > The other choice is just to trust that the typecode is correct and > use > the typecode information to build a stub for the object reference as > type Base, despite what the RepositoryId of the actual object > reference > says. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > Date: Thu, 24 Feb 2000 19:00:35 +0100 Message-Id: <200002241800.TAA15158@pandora> From: Martin von Loewis To: jam@camros.com CC: jon@floorboard.com, python-ftf@omg.org In-reply-to: <200002240718.CAA07734@emerald.omg.org> (jam@camros.com) Subject: Re: Python Issue: widening object references and CORBA.Any.value References: <200002240718.CAA07734@emerald.omg.org> User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII X-UIDL: L)1e9U9#e9@'Td9)-o!! > Since python has all of the facilities for doing this on the fly, maybe a > better question would be whether there should be a "default" way to build > types representing IDL constructs programatically. > > Having a programtic interface allows the developer to decide when to build > types (eg. a dynamic_value () method on CORBA.Any)... I would think that the Python Any.value operation is closest to the Java mapping Any.extract_* operation, only that it considers the typecode kind. So in case of tk_objref, Any.value() is only guaranteed to give you a CORBA.Object; you'd have to narrow to get anything more specific. The question of the most specific type of a stub object is more general than extraction from anys. For example, string_to_object could also give you a more specific type than Object, using various heuristics and trickery. As a first approximation, this is a quality-of-implementation issue. Some implementation may use an expensive approach (hundreds of _is_a) calls to figure out the most specific type, another may trust the repository id in the object reference (or the one in the type code in case of Any); yet another implementation may only give you the statically-guaranteed type. Those that figure out the type in advance have more effective _narrow implementations. Alternatively, a standard mechanism could be provided to select the typing strategy. One such mechanism was proposed in orbos/99-08-01, which was rejected by ORBOS. So I don't think the Python FTF should add such magic to the Python mapping - implementations are free to provide it as an extension (or give stronger typing guarantees as an extension) Regards, Martin Date: Thu, 24 Feb 2000 14:47:47 -0500 (EST) Message-Id: <200002241947.OAA05807@emerald.omg.org> To: Martin von Loewis Subject: Re: Python Issue: widening object references and CORBA.Any.value From: "Jeffrey A. Marshall" X-Mailer: TWIG 2.1.1 Cc: jon@floorboard.com, python-ftf@omg.org Content-Type: text X-UIDL: `o/!!,g0e9LGJe9^bOe9 Martin von Loewis said: > > Since python has all of the facilities for doing this on the fly, maybe a > > better question would be whether there should be a "default" way to build > > types representing IDL constructs programatically. > > > > Having a programtic interface allows the developer to decide when to build > > types (eg. a dynamic_value () method on CORBA.Any)... > > I would think that the Python Any.value operation is closest to the > Java mapping Any.extract_* operation, only that it considers the > typecode kind. So in case of tk_objref, Any.value() is only guaranteed > to give you a CORBA.Object; you'd have to narrow to get anything more > specific. > This sounds reasonable to me although it contradicts with the wording of the current paragraph on CORBA.Any to some degree. This might be the best alternative -- of course implemenations would be free to provide a more specific type of return value. To: "Jeffrey A. Marshall" cc: python-ftf@omg.org, issues@omg.org Subject: Re: Python Issue: widening object references and CORBA.Any.value In-Reply-To: Your message of "Wed, 23 Feb 2000 20:48:29 PST." <200002240450.XAA05581@emerald.omg.org> From: Bill Janssen Message-Id: <00Mar2.123658pst."3633"@watson.parc.xerox.com> Date: Thu, 2 Mar 2000 12:37:06 PST Content-Type: text X-UIDL: ;dVd9H%F!!_3`d9B*=e9 > Assuming the "Server" process has no compile time knowledge of the "Derived" > interface the ORB has a couple of options: > - raise a BAD_TYPECODE? > - build/load a dynamic stub instance? > - return a CORBA.Object? > - raise some other exception? Our system will return an instance of Base (assuming from your example that Base is known to the server, but Derived is not). It always returns the most specific type known to the code which unpacks the Any. Bill Date: Thu, 2 Mar 2000 16:45:33 -0500 (EST) Message-Id: <200003022145.QAA06731@emerald.omg.org> To: Bill Janssen , "Jeffrey A. Marshall" Subject: Re: Python Issue: widening object references and CORBA.Any.value From: "Jeffrey A. Marshall" X-Mailer: TWIG 2.1.1 Cc: python-ftf@omg.org, issues@omg.org Content-Type: text X-UIDL: #H#!!aKfd9&("e9(@[!! Bill Janssen said: > > Assuming the "Server" process has no compile time knowledge of the "Derived" > > interface the ORB has a couple of options: > > - raise a BAD_TYPECODE? > > - build/load a dynamic stub instance? > > - return a CORBA.Object? > > - raise some other exception? > > Our system will return an instance of Base (assuming from your > example that > Base is known to the server, but Derived is not). It always returns > the > most specific type known to the code which unpacks the Any. > Do you base this upon the type_id in the IOR or the information contained in the TypeCode? I assume that in either case, the ORB would most likely have to interrogate the IR to find out the inherited interfaces of a given type. What about a case like: interface Base1 {}; # known to the receiving ORB interface Base2 {}; # known to the receiving ORB interface Derived : Base1, Base2 {}; What happens when the receiving ORB receives a Derived? Do you create a Base1 or Base2? > Bill > To: "Jeffrey A. Marshall" cc: python-ftf@omg.org, issues@omg.org Subject: Re: Python Issue: widening object references and CORBA.Any.value In-Reply-To: Your message of "Thu, 02 Mar 2000 13:47:21 PST." <200003022145.QAA06731@emerald.omg.org> From: Bill Janssen Message-Id: <00Mar2.145750pst."3633"@watson.parc.xerox.com> Date: Thu, 2 Mar 2000 14:57:56 PST Content-Type: text X-UIDL: ^3Fe9;\f!!8oS!!8`K!! > Do you base this upon the type_id in the IOR or the information contained in > the TypeCode? I don't remember offhand. Most probably the type_id in the IOR. > I assume that in either case, the ORB would most likely have to > interrogate the IR to find out the inherited interfaces of a given > type. We have a reasonably intelligent algorithm that pings the server with _is_a calls to determine the known types that are ancestors of the type specified. We don't trust calls to the IR. > interface Base1 {}; # known to the receiving ORB > interface Base2 {}; # known to the receiving ORB > interface Derived : Base1, Base2 {}; > > What happens when the receiving ORB receives a Derived? Do you > create a Base1 > or Base2? Depends on the configuration. In one case you get an error, in the other you get an instance of a newly constructed object type, pseudo-Derived, which inherits from both Base1 and Base2. The second option seems popular with our users. Note that pseudo-Derived is not actually Derived; it is only Derived in that it has Base1 and Base2 as ancestors, and has the same repository ID. Supposedly, the user can later load the actual code for Derived, and it will automagically replace the pseudo-version; I don't remember whether or not that's actually implemented. It's not typically something that's actually necessary, in our experience. Bill