Issues for Portability RTF List-defunt list, aliases to orb_revision

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 579: ServantActivator::etherealize (Errata for orbos/97-05-15)
Issue 580: Errata for orbos/97-05-15 page 18-2, 18.1.1, editorial
Issue 581: Errata for orbos/97-05-15 page 18-14, 18.5.1
Issue 583: InconsistentTypeCode not specified
Issue 584: Bug in example 4.4.1
Issue 612: use_servant_manager and default_servant
Issue 613: Default_servant and NON_UNIQUE_ID
Issue 614: Threading and shutdown interfaces
Issue 619: Section 2.4 defines typedef void status- no legal IDL
Issue 628: POA::activate_object_with_id() and POA::create_reference_with_id()
Issue 629: Object::get_implementation()
Issue 638: Section 3.3.1: _this() and IMPLICIT_ACTIVATION need clarification
Issue 639: Sections 18.1.1 and/or18.1.2: implicit activation
Issue 642: Add operation to POAManager to query state
Issue 643: return of invalid Servant as result of incarnate() or preinvoke()
Issue 644: Hierarchy example in 14.24.5 incorrect
Issue 645: PortableServer::POA::AdapterInactive exception is never used in IDL
Issue 654: Chapter 4.3, 4.3.3.7, Comments on DynAny
Issue 655: Chapter 4.3.3 (editorial)
Issue 656: Chapter 4.3.3.2, Comments on Dynamic Any
Issue 657: Chapter 4.3.3.8, Comments on DynAny
Issue 658: Chapter 4.3.6, Comments on DynAny (current_member_type)
Issue 659: Chapter 4.3.7
Issue 660: Chapter 4.3.8, length attribute
Issue 662: PolicyType constants not assigned
Issue 664: section 3.3.6: clarification of SINGLE_THREAD_MODEL policy
Issue 667: POAs and threads
Issue 668: Definition of Lifespan policy of TRANSIENT should be extended
Issue 669: Clarification on TRANSIENT
Issue 670: Section 3.2.2: clarification needed
Issue 671: Behavior of ServantManager should be clarified
Issue 672: Behavior of preinvoke and postinvoke
Issue 676: use of root POA to implement root POA and POAMAnager impossible
Issue 677: What happens if programmer invokes destroy() operation?
Issue 715: Change interface of AdaptorActivator::unknown_adapter() method
Issue 728: no PolicyTypes for POA policies
Issue 729: POA C++ example in orbos/97-05-15
Issue 736: ORB::run
Issue 737: Defining a new standard CORBA exception named OBJECT_DISABLED
Issue 742: Defining Cookie as sequence<octet> instead of native
Issue 743: ServantActivator interface
Issue 744: get_servant_manager and set_servant_manager
Issue 745: DynAny : invoke operation next()
Issue 746: DynAny section 4.3.3.7
Issue 747: Inconsistent usage of next() for DynUnions
Issue 748: Value of length attribute in DynAny
Issue 774: Question about ObjectId
Issue 921: Description of ServantActivator::etherialize()
Issue 934: POA::create_reference_*() Issue
Issue 962: need list_POAs call
Issue 963: Can"t determine a POA creation policies
Issue 993: ORB/POA and ServanrtManager issue
Issue 994: ServantManager and ForwardRequest issue
Issue 997: Can ServantManagwers be incarnated by other Servant Managers?
Issue 1089: Inconsistent TypeCode exception never defined
Issue 1117: DynAny issues (02), CORBA 2.2 chapter 7
Issue 1119: DynAny issue (04), CORBA 2.2, chapter 7
Issue 1120: DynAny issue (05), CORBA 2.2, chapter 7
Issue 1122: DynAny issue (07), CORBA 2.2 chapter 7
Issue 1127: POA TRANSIENT Policy needs clarification
Issue 1144: What does DynAny::current_component() do if invoked on a primit
Issue 1147: DynAny issue
Issue 1150: POACurrent should be augmented for efficiency and symmetry
Issue 1157: DynUnion::member_name() issue
Issue 1158: DynUnion::set_as_default question
Issue 1159: DynUnion interface unsafe as specified
Issue 1162: Problems with ORB shutdown
Issue 1514: typos in DynamicImplementation example
Issue 1639: DynAny and bounded strings/wstrings
Issue 1644: destroy() forDyn Any?
Issue 1648: DynAny::next semantics
Issue 1649: DynAny::seek semantics
Issue 1652: DynFixed IDL
Issue 1675: DynAny: attributes vs operations

Issue 579: ServantActivator::etherealize (Errata for orbos/97-05-15) (port-rtf)

Summary: Errata for orbos/97-05-15: page 3-34, 3.3.8.16  two refs to "ServantLocator::etherealize" should be "ServantActivator::etherealize"

Summary: Append to the next to last sentence:"on a default ORB".

Summary: The C++ code for PortableServer::ServantLocator::Cookie defines Cookie directly in the PortableServer namespace. It should be inside the class ServantLocator

Summary: Exception "InconsistentTypeCode" raised by the ORBs DynAny creation functions is not specified. Is it declared within the ORB? Is it derived from UserException?

 closed issue

Summary: There is a bug in example 4.4.1 <example> "mems->length(2)" must be added

Summary: What if both use_servant_manager and default_servant set?

Summary: What if Default_servant and NON_UNIQUE_ID?

Summary: The ORB interface for shutdown is incomplete and underspecified. work_pending and perform_work as specified are inadequate. See suggested changes in communicating archive file.

Summary: This is not legat IDL, since void can only be used as the return type of an operation declaration, per the grammar

Summary: The paragraphs describing when calls for these operations are NOT valid are confusing. Clarify the text to make this more obvious

Summary: Object::get-implementation() operation was supposed to be deprecated, but the orbos/97-0501[56] Portability submission doesn"t. It should be since ImplementationDe is still undefined

Summary: second bullet: "..a language mapping may provide a default implementation of this interface...". For C++ it appears that Servant::_default_POA() operation is intended to provide feature t

 closed issue

Summary: These sections should explicitly state that Servant::_default_POA() is used by the ORB to accomplish implicit activation

 closed issue

Summary: There is no operation to query state of POAManager. Add:          enum State { HOLDING, ACTIVE, DISCARDING, INACTIVE };             State get_state()     to interface

Summary: Spec does not address case when ServantManager returns an invalid Servant to POA as result of an incarnate() or preinvoke() operation. Spec should be clarified

Summary: The IDL for interface G does not inherit from interface D, but the generated POA_G__vepv structure contains a POA_D__epv *.

Summary: The exception PortableServer::POA::Adapterinactive is never used in the IDL in section 3.4.2. It looks like it was left over when POAManager interface was added. Should be removed

Summary: At time of creation a DynAny contains typecode but no value. Whay exception is raised by various get operations?Put something in the raises clause of the get operations

Summary: Several of the bullet items at the beginning of this section are repeated.

Summary: Aliases are not dealt with at all in this chapter and some form of TypeCode equivalence is implied ut never defined. How about bound and a unbound string. Typecode equivalence needs to be defin

Summary: There are repeated references in the chapter to narrowing a DynAny to the desired type, but there is no standard narrowing mechanism defined in CORBA IDL. Editorials in para 5 and 8 also

Summary: current_member_type operation "may return an empty string since the TypeCode of the struct being manipulated may not contain the names of members in the struct." When can this occur?

Summary: Why are there explicit operations for setting value in a struct, enum seq, etc., but not for setting the discriminator and/or member value of a union?

Summary: THe length attribute contains the number of elements in (or to be contained in) the sequence. Which is it, in or to be in? What does this mean??

Summary: None of the policy objects defined in PortableServer IDL module have PolicyType constants assigned. These are needed to implement the policy objects correctly

Summary: Statement in section 3.3.6 that "no serialization of preinvoke or postinvoke may be assumed".Spec should be clarified to state that the SINGLE_THREAD_MODEL policy.

Summary: The multithreading support ooffered by POAs is fairly inadequate for real-world, portable, multithreaded applications.(examples available in corresponding archive file)

While it would be nice in some cases to have additional functionality, 
it is certainly possible to implement and use an ORB without any 
clarification. This suggestion is more properly the subject for an RFP. 
The Real-Time CORBA has a suitable scope for this, and the current joint 
submission to it covers this functionality.

Summary: Definition of Lifespan policy of TRANSIENT should be extended toinclude temporary network outages that don"t affect server processes

are permitted to come and go, even for transient objects. 

What seems to be suggested here is that in some cases it may be 
impossible to re-establish a connection that has been broken, and that 
this situation should have some affect on the meaning of TRANSIENT. It 
isn't obvious how this change in wording would affect orb 
implementations or users. If the user cannot re-establish contact with 
the server then it is going to get an error in any case. On the server 
side, no requests will be received for the objects whose references 
had now unreachable addresses. If new references are created using a 
different address, why should they not be valid?

Summary: IIOP implementors can"t depend only on host and port to reject transient object references (section 3.3.7.2)

Summary: Section 3.2.2 should state that an Object Id can appear in the Active Object Map only once

Summary: Behavior of ServantManager should be clarified with respect to GIOP Locate requests.Just because incarnate or preinvoke are calledit"s not necessarily case that servant will be invoked

Summary: Behavior of preinvoke and postinvoke are ambiguous about when the request is finished and the reply is delivered to the client

Summary: It"s impossible to use root POA to implement the root POA and its POAManager, due to a deadlock because POAManager starts in the HOLDING state.

Summary: What happens if the programmer invokes the destroy() operation on the root POA? The spec should be changed to state that destroying the root POA is equivalent to calling ORB::shutdown()

Summary: Change this interface to allow the implementor to raise the ForwardRequest exception, to indicate that the incoming request that cause method to be called can be appropriately forwarded

Summary: PolicyType values are allocated by the OMG. None of the Policy interfaces supplied by the POA spec have PolicyType values allocated for them yet

Summary: orbos/97-05-15, section 3.6.2-creating a POA: The code in this section should first set the length of the sequence before using operator[]

Summary: On page 2-11 of the portability submission it"s specified that operation ORB::run returns when the ORB has shut down. Does this mean that ORB::run returns when ORB::shutdown returns? The behaviour is not well specified

:shutdown has been called and the shutdown has

Summary: There are scenarios where it may be interesting to raise an exception indicating that a CORBA object exists but is not operable unless corrective action is taken It"s appropriate to distinguish between the 3 following exceptions: TRANSIENT, OBJECT_DISABLED, and OBJECT_NOT_EXIST

This issue has been sitting in the port-rtf list for quite a while. the Portability submitters did not see it fit to add this to the spec. It seems inappropriate
for the Core RTF to add this feature without an overwhelming push to do so, of which there has been scant evidence. Consequently, propose that this one be laid to
rest.

Summary: It is not clear why the Cookie parameter in the preinvoke and postinvoke operations in the ServantLocator interfaces were defined as native. Defining it as native introduces more work in klanguage mappings

Summary: Some of the statements set in section 3.3.5 of POA chapter (ServantActivator interface) are not correct in order to describe behaviour of incarnate and etherialize operations

Summary: get_servant_manager and set_servant_manager operations should not require the USE_SERVANT_MANAGER policy to work . These paragraphs should be dropped

Summary: It may be convenient for programmers that operation next() be invoked in order to access the first component of a DynAny

Summary: Clarify behaviour of operations for accessing components of a constructed DynAny when they are members of basic data types

Summary: If we decide to maintain that next() doesn"t need to be invoked in order to access the first component of a DynAny, then it is not necessary to invoke next() twice in order to get access to the value of the member in the DynUnion

Summary: Value of the length attribute in the DynAny object associated to a sequence must be set prior to inserting values of the sequence

Summary: The POA specs are particularly confusing on the definition of ObjectID (POA spec as of May 20): p 3-38, section 3.4.1 IDL in COR BA module concerning the POA, p 3-39, section 3.4.2 IDL for POA and Related Interfaces, p 14-43, Operations for obtaining initial object references (C mapping). We have two legal definitions of ObjectId: PortableServer::ObjectId, and CORBA::ORB::ObjectId, specified differently

Summary: The description of the ServantActivator::etherialize() and
 ServantLocator()::postinvoke() operations do not describe what actions
 the POA should take if either of these operations returns a system
 exception.

Summary: The descriptions of POA::create_reference() and
 POA::create_reference_with_id() do not describe the intf argument.
 

 received issue

Summary: There is currently no way to determine all currently active
 subPOAs of a given POA.  We propse that a new method
 be added to the POA to provide this functionality.  This would
 allow application developers to write portable tools which
 browse currently active POAs.
 
 We propose a new method:
 
 sequence<string> list_POAs();
 
 which will return a list of currently active sub-POAs under
 the current POA.
 

This seems to be a useful feature for management applications 
which may wish to browse the set of currently active POAs in a portable 
fashion. Propose that we add this feature as described below.

Summary: There is currently no portable way to determine what
 policies a POA was created with.  We propose adding the following:
 
 readonly attribute PolicyList the_policies;
 
 Which returns the policies which the POA was created with.
 

Summary: What should the ORB/POA do if a ServantManager or an object operation
 throws a ForwardRequest and supplies an object that does not support the
 interface that the operation was defined in?
 
 

There is no obligation for the ORB/POA on the server side to do 
anything special in this case. The ORB should do the obvious - send a 
LOCATION_FORWARD reply to the caller. 

If there is anything that should be done on the client side when the 
reply is received, then it is a language binding issue. In the case of 
collocation, the behavior should be the same on the grounds of 
location transparency. 

Have a copy of  this issue assigned to each of the Language Binding RTFs, 
and remove it from the Core list. 
Revised Text: 
Actions taken: Have a copy of tthis issue assigned to each of the 
Language Binding RTFs, and remove it from the Core list.

Summary: When a ServantManager throws a ForwardRequest exception from a call to
 incarnate() or preinvoke(), how does the ORB/POA know whether the
 forward request was for the object in question or to forward to a
 different ServantManager?  It seems that there is an ambiguity here,
 because the FowardRequest could mean two different things.
 

This should be closed without change. 

While at first look it seems ambiguous, when you look closely it is not. 
When incarnate/preinvoke is called on the servant for a servant manager, 
if ForwardRequest is thrown it applies to the reference that the call 
was working on. But, if while doing that there is a recursive call to 
incarnate/preinvoke the servant manager reference itself then a 
ForwardRequest from the servant that handles that affects the servant 
manager reference itself. 

This is hard to explain, and subtle to implement, but not especially 
expensive in either time or code. I have an existence proof so I know it 
is feasible.

Summary: What would happen if someone coded up an implementation of a
 ServantManager whose POA used a ServantManager?  (I know this is weird,
 but legal.)
 

Summary: In section 7.2.2 of the CORBA 2.2 spec, add the following IDL
 declaration before the definion of the CORBA::ORB::create_*any()
 operations:
 
 exception InconsistentTypeCode {};
 

 clarified, close issue

Summary: * The whole DynAny description should be reworded to avoid talking
 about buffers, as I think this is more confusing than helpful.
 

Summary: * Page 7-10 and 7-11, section 7.2.5: the DynEnum interface uses
 read/write attributes to allow get/set of enum values as strings or
 as ulongs. What happens if a value is specified that is outside the
 enumerator range of values? The use of attributes here disallows
 throwing an InvalidValue exception.
 

 incorporated changes close issue in 2.4

Summary: * Page 7-13 and 7-14, section 7.2.7: the DynUnion interface supports
 a set_as_default attribute that can be used to see if the
 discriminator is set to a default value. This should be a readonly
 attribute, since makeing it read/write means I can use it to say that
 the discriminator has a default value when it really doesn"t.
 

Summary: * Page 7-15, C++ example at the top of the page: "value1" should be
 of type CORBA::Long, not long; "value2" should be of type
 CORBA::Boolean, not boolean. The "mems" sequence does not have its
 length set anywhere, so the first invocation of operator[] on it is
 illegal; "mems.length(2);" should be invoked before that. The
 DynAny::to_any() returns a CORBA::Any*, not a CORBA::Any, so the
 "result" variable should be declared as a CORBA::Any_var.
 

:Any_var.

Summary: The current POA spec needs some clarification on the TRANSIENT
 lifespan policy.  The current spec defines TRANSIENT as follows:
 
 "The objects implemented in the POA cannot outlive the process in
 which they are first created.  Once the POA is deactivated, use of any
 object references generated from it will result in an OBJECT_NOT_EXIST
 exception."
 
 

Summary: What does DynAny::current_component() do if invoked on a DynAny that
 contains a primitive type?
 
 I think that it should raise a CORBA::DynAny::TypeMismatch exception in
 this case.
 

Specified semantics of create operations with respect to current position and 
initial values 
Revised Text: see ptc/99-03-02

Summary: What should a DynStruct(or other structured DynAny type) do if someone
 calls a primitive inserter or getter past the end of the structure?
 
 For example:
 
 // IDL
 struct Foo {
     boolean b;
 };
 
 // C++
 
 	DynStruct_var	ds = orb->create_dyn_struct(_tc_Foo);
 	
 	ds->insert_boolean(0);
 	ds->insert_boolean(1);  // what exception should happen here?
 

Calling an insert or get operation on a DynAny that has components but has a current 
position of -1 raises InvalidValue.

Summary: To write efficient DSI implementations, there needs to be a new
 operation to POACurrent, as follows.
 
 	CORBA::RepositoryId get_interface() raises (NoContext);
 
 	Description: The get_interface operation returns the
                    RepositoryId of the interface on which the
                    request was made. If called outside the
                    context of a POA-dispatched operation,
                    a NoContext exception is raised.
 

Close with no change. 

  Some time ago I sent out a complex strawhorse proposal on how to 
  accomplish some of what this issues requests. There has since 
  been extensive discussion on the general subject, often jointly 
  with people from CorbaSec. 

  Based on that discussion, I am now convinced that it is better 
  to expect the servant to provide this information. Doing otherwise 
  invites abuse by clients that might tamper with the object reference. 

Summary: What should DynUnion::member_name() & DynUnion::member() return for a
 union whose discriminator value does not match any of the union switch
 arms?
 

Summary: There is almost no information about the behavior of the
 DynAny::set_as_default attribute.  I assume that when getting the
 attributes value, true is returned if the union has a default branch and
 the current discriminator value of the union falls in the range of the
 default branch.  I also assume that setting the set_as_default attribute
 to true causes the union discriminator value to be set to a value that
 matches the default branch.  But what should setting the set_as_default
 attribute to false do?
 

Summary: The DynUnion interface is pretty unsafe as specified.  There is no text
 in the description of the interface that states whether the programmer
 or the DynUnion implementation is responsible for assuring that the
 discriminator value and the chosen member of the underlying union are
 consistent.  Given that the programmer can access the discriminator
 value and the member value as separate DynAny objects, it is awkward for
 the implementation to detect an inconsistent union value.
 

Summary: There are some problems with ORB::shutdown as currently specified -
 specifically with the wait_for_completion parameter.
 
 There are two distinct contexts in which the call might be made:
 - in the context of an operation invocation
 - outside the context of an operation invocation.
 

This issue appears to be outside the scope of this RTF. 
While it is a limitation, it is not a fatal one, and I see no 
reasonable upward compatible way to make a change to support it. 

This issue would be worth considering in a possible 
RFP at some future time. It would be quite reasonable to make 
this sort of change in the context of replacing servant managers 
and adapter activators with something that uses a different 
implementation technique.

Summary: On page 9-58 of CORBA 2.2 the example DatabaseEntryImpl class has two
 problems:
 
 1. It derives from POA_PortableServer::DynamicImplementation instead of
 PortableServer::DynamicImplementation. Section 20.36.3 (page 20-100) of CORBA
 2.2 clearly states that DynamicImplementation is in the PortableServer C++
 namespace:
 
 "In C++, DSI servants inherit from the standard DynamicImplementation class.
 This class inherits from the ServantBase class and is also defined in the
 PortableServer namespace."
 
 The definition of the DynamicImplementation class on page 20-101 further shows
 it to reside in the PortableServer namespace.
 
 2. DatabaseEntryImpl has a member function named _defaultPOA instead of
 _default_POA.
 

Summary: The DynAny chapter makes no mention of bounded strings. I assume that
 create_basic_dyn_any() is to be used for bounded strings, but the
 spec doesn"t say. Similarly, object references seem to belong here too,
 but again, they are not mentioned.
 
 Right now, the description of create_basic_dyn_any() talks about "basic
 data types", but as far as I can see, does not define the meaning of that.
 

Summary: I"m having a hard time understanding the motivation for adding a destroy()
 operation to DynAny. Because DynAny is locality-constrained, it seems
 redundant to have a destroy() operation. However, the resolution to
 issue 1116 explicitly requires that I have to call destroy() before
 I release the last reference to a DynAny to avoid memory leaks.
 
 What I don"t understand is why we don"t just use the normal
 duplicate/release semantics on references to achieve all this.
 

Summary: For the next() operation, the spec says:
 
 	The next operation logically advances the pointer and returns TRUE
 	if the resulting pointer points to a component, or FALSE if there
 	are no more components.
 
 This does not make it clear what the current position is after next() does
 indeed return FALSE. In other words, if I have just called next() and 
 received FALSE, what will I get if I call current_component()? A nil
 reference? An exception? The DynAny for the last component?
 
 This needs to be nailed down.
 

Specified semantics of create operations with respect to current position and 
initial values 
Revised Text: see ptc/99-03-02

Summary: >From the spec:
 
 	Operation seek logically sets a new offset for this pointer,
 	returning TRUE if the resulting pointer points to a component
 	or FALSE if there is no component at the designated offset.
 
 Issues:
 
 	"... new offset for this pointer, ..."
 
 What pointer? The pointer was mentioned previously, but too far away
 for the expression "this pointer" to make sense here.
 
 Also, someone else suggested that the entire story about buffers and pointers
 should be abandandoned. I agree -- it would make more sense to talk about
 a DynAny as an ordered collection of component DynAnys, and to talk about
 the current "position" instead of a pointer.
 
 The semantics of seek do not state what the current position will be
 if I pass an out-of-range index value. As it stands, I have to assume
 the current position will be undefined if I do this. I suggest to explicitly
 state this, or alternatively, to require an out-of-range index to leave
 the current position unaffected.
 

Specified semantics of create operations with respect to current position and 
initial values. Cleaned up semantics to fully define the behavior under various boundary 
conditions. 
Revised Text: see ptc/99-03-02

Summary: Delete the type definition for OctetSeq inside the DynAny interface
 	on page 7-3.
 
 	Add
 
 		typedef sequence<Octet> OctetSeq;
 
 	on page 7-4 just before the definition of DynFixed.
 
 This makes the IDL sylistically consistent and it also removes the
 mismatch between the IDL on pages 7-3 and 7-4 with the IDL on page 7-10.
 

Deleted definition of OctetSeq here (Issue 1652). It was defined twice, once in the 
CORBA scope and once in the CORBA::DynAny scope. Because DynAny itself 
does not use OctetSeq, and because supporting type definitions for other DynAny 
types, such as DynStruct, also appear in the CORBA scope, deleting the definition 
here was the cleanest fix. 
Revised Text: see ptc/99-03-02

Summary: The DynAny interface uses an interesting mix of attributes and operations.
 
 For example, in DynFixed, we find:
 
 	interface DynFixed : DynAny {
 		OctetSeq get_value();
 		void set_value(in OctetSeq val) raises(InvalidValue);
 	};
 
 However, in DynEnum, we find:
 
 	interface DynEnum : DynAny {
 		attribute string value_as_string;
 		attribute unsigned long value_as_ulong;
 	};
 
 Why does one interface use a modifier and an accessor, while the other
 interface uses writable attributes?