Issue 752: Invoke a create reference operation passing empty RepositoryID string (port-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Minor Summary: Summary: In current POA specification, it is not specified what is the behaviour of create_reFerence* operations that receive an empty RepositoryId string. The specification should clearly state what"s the behaviour in this case, but it doesn"t. Resolution: Revised Text: Actions taken: October 6, 1997: received issue July 30, 1998: closed issue Discussion: End of Annotations:===== Return-Path: From: JuanHierro@aol.com Date: Mon, 6 Oct 1997 03:12:27 -0400 (EDT) To: juergen@omg.org cc: jhierro@tid.es Subject: Juergen: I missed an issue !! Portable Object Adapter (POA) issues, cont.: ============================================ Title: It is not specified what is the behaviour when we invoke a create reference operation passing an empty RepositoryId string. Description: In current POA specification, it is not specified what is the behaviour of create_reFerence* operations that receive an empty RepositoryId string. The specification should clearly state what's the behaviour in this case, but it doesn't. The best choice in our mind would be to state that passing a empty string implies that an empty string is passed in the type_ID field in the IOR representation of the reference. Today, is up to the ORB implementation whether the type_id field in the IOR representation of a reference carries the repository id of the most derived interface associated to the object pointed by the reference. These kind of decissions shouldn't rely on the ORB implementation but on the programmer. While in certain situations it would be more efficient to pass an empty type_id in the IOR (interactions within the ORB domain where the reference is not going to be narrowed, for example) in other situations it wouldn't. Leaving this decision up to the ORB implementation is not the best answer because the ORB implementation cannot guess what's the usage that the application is making of the references. Therefore, it's better to leave the decission to the programmer, who knows what's the usage that the application is making of references. create_reference* operations should therefore behave as follows: + passing an empty string causes that an empty type_id string is inserted in the IOR representation of the reference + passing a non-empty string representing a RepositoryId causes that the string be inserted in the IOR representation of the reference. Return-Path: Date: Wed, 01 Jul 1998 14:37:37 -0400 From: Jonathan Biggar Organization: Floorboard Software To: port-rtf@omg.org Subject: Proposal for Issues 752 & 934 Both 752 & 934 can be resolved with the following proposal: Add the following text to both descriptions of POA::create_reference() and POA::create_reference_with_id() in section 9.3.8, before the sentence "This operation does not cause an activation to take place.": The specified repository id, which may be a null string, will become the type_id of the generated Interoperable Object Reference (see 11.6.2). A repository id that does not identify the most derived interface of the object or one of its base interfaces will result in undefined behavior. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Wed, 01 Jul 1998 16:40:44 -0400 From: Jonathan Biggar Organization: Floorboard Software To: port-rtf@omg.org Subject: Proposal for Issue 752 [In a separate message, I will post an issue to the C++ RTF requesting the addition of virtual functions to handle get_interface(), is_a(), and non_existent() in the PortableServer::ServantBase class.] In section 9.3.1, add the following after the second bullet item: o Values of type Servant provide default implementations of the standard object reference operations get_interface(), is_a(), and non_existent(). These operations can be overridden by the programmer to provide additional behavior needed by the object implementation. The default implementations of get_interface() and is_a() operations will use the most derived interface of a static servant or the most derived interface retrieved from a dynamic servant to perform the operation. The default implementation of the non_existent() operation will simply return false. These operations are invoked by the POA just like any other operation invocation, so the PortableServer::Current interface and any language mapping provided method of accessing the invocation context are available. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Thu, 2 Jul 1998 07:44:33 +0100 From: jhierro@jam.tid.es (Juan Jose Hierro Sureda) To: port-rtf@omg.org Subject: Re: Proposal for Issue 752 X-Sun-Charset: US-ASCII Hi all, I vote yes for adoption of the proposal made by Jon on issue 752. Thanks Jon, -- Juanjo > > [In a separate message, I will post an issue to the C++ RTF > requesting > the addition of virtual functions to handle get_interface(), is_a(), > and > non_existent() in the PortableServer::ServantBase class.] > > In section 9.3.1, add the following after the second bullet item: > > o Values of type Servant provide default implementations of the > standard object reference operations get_interface(), is_a(), and > non_existent(). These operations can be overridden by the > programmer to > provide additional behavior needed by the object implementation. > The > default implementations of get_interface() and is_a() operations > will > use the most derived interface of a static servant or the most > derived > interface retrieved from a dynamic servant to perform the operation. > The default implementation of the non_existent() operation will > simply > return false. These operations are invoked by the POA just like any > other operation invocation, so the PortableServer::Current interface > and > any language mapping provided method of accessing the invocation > context > are available. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > > > Return-Path: Date: Thu, 02 Jul 1998 11:32:49 -0400 From: Bob Kukura Organization: IONA Technologies To: Jonathan Biggar CC: port-rtf@omg.org Subject: Re: Proposal for Issue 752 References: <359A9ECC.307626AA@floorboard.com> Like on the client side, in order to not conflict with legal IDL operation names, the C++ mappings of these pseudo-operations must prepend an underscore. So the C++ mapping function names on ServantBase and on DynamicImplementation should be "_get_interface()", "_is_a()", and "_non_existent()", with the same signatures as in the mapping of CORBA::Object. -Bob Jonathan Biggar wrote: > > [In a separate message, I will post an issue to the C++ RTF > requesting > the addition of virtual functions to handle get_interface(), is_a(), > and > non_existent() in the PortableServer::ServantBase class.] > > In section 9.3.1, add the following after the second bullet item: > > o Values of type Servant provide default implementations of the > standard object reference operations get_interface(), is_a(), and > non_existent(). These operations can be overridden by the > programmer to > provide additional behavior needed by the object implementation. > The > default implementations of get_interface() and is_a() operations > will > use the most derived interface of a static servant or the most > derived > interface retrieved from a dynamic servant to perform the operation. > The default implementation of the non_existent() operation will > simply > return false. These operations are invoked by the POA just like any > other operation invocation, so the PortableServer::Current interface > and > any language mapping provided method of accessing the invocation > context > are available. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org