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 616: POA::id_to_reference()
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 648: Server request and oneway operations
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 738: DSI servants should support an _is_a method which receives an ObjectId
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 750: Setting the value of a DynAny after calling rewind() may be harmful
Issue 752: Invoke a create reference operation passing empty RepositoryID string
Issue 774: Question about ObjectId
Issue 802: POAManager (02)
Issue 921: Description of ServantActivator::etherialize()
Issue 934: POA::create_reference_*() Issue
Issue 958: Separator character for POAs should be specified
Issue 962: need list_POAs call
Issue 963: Can"t determine a POA creation policies
Issue 964: No POA hook for future 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 1116: DynAny issues
Issue 1117: DynAny issues (02), CORBA 2.2 chapter 7
Issue 1118: DynAny issue (03), 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 1121: DynAny issue (06), CORBA 2.2 chapter 7
Issue 1122: DynAny issue (07), CORBA 2.2 chapter 7
Issue 1123: DynAny issue (08), CORBA 2.2 chapter 7
Issue 1127: POA TRANSIENT Policy needs clarification
Issue 1135: POAManager transition to same state
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 1161: Etherialization when destroying trees of POAs
Issue 1162: Problems with ORB shutdown
Issue 1314: Access to the Active Object Map
Issue 1407: Interaction of find_POA() and AdapterActivatorts and create_POA()
Issue 1408: POA destroy() operation is ill-defined
Issue 1409: Multiple threads calling destroy() once destroy() operation has begun
Issue 1410: Changing default servant, etc. after POA activation
Issue 1428: Blocking POA operations
Issue 1514: typos in DynamicImplementation example
Issue 1628: POA API support for default servant
Issue 1639: DynAny and bounded strings/wstrings
Issue 1644: destroy() forDyn Any?
Issue 1645:
Issue 1646: DynAny assignment
Issue 1647: Inconsistent Typecode?
Issue 1648: DynAny::next semantics
Issue 1649: DynAny::seek semantics
Issue 1652: DynFixed IDL
Issue 1668: DynFixed interface isn"t usefu
Issue 1670: DynAny::current_component if no components?
Issue 1671: DynAny: sometimes Any, sometimes DynAny?
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: Within context of request invocation, the POA can return ObjectId for target object. One could pass this to POA::id_to_reference to get references used to invoke target. Not true in non-retain case

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: Given it"s optional to call set_result operation of CORBA::ServerRequest, an ORB can"t determine whether operation supported is oneway or not

deferred in June 2011 to the next RTF

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:  "DSI servants should support an _is_a method which 
    receives a RepositoryId and is invoked by the ORB to support remote
    _is_a_requests. _is_a should be included in the list of operations 
    that a DSI servant should support"  
 

 Revision:   Section 9.3.1 "The Servant IDL type", page 9-14. Add             

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: Instead of making implementations of DynAny more complex, we suggest to clarify that calling rewind() to set the value associated a DynAny object may lead to unpredictable results. It should also be specified that rewind() is only safe if used  to re-read components associated to DynAny or re-write components associated to a DynAny if the type associated to DynAny remains the same and that it is of fixed length

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.
 

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: How does a POA associate itself with a POAManager?
 

 closed issue

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: The Portability submission should specify a separator charater
 for POAs that may not be used in a POA name.  We propose that
 "/" be the separator character in POA name, and that a "/" is
 not valid if used in a POA name.  This provides for vendors to
 provide a more compact on-the-wire encoding, rather than
 use sequence<string>, and also is a convenience for the user
 if we allow compound POA names to be used anywhere an
 adapter_name is currently used in the POA APIs.
 
 

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: The POA spec currently provides no hook for adding future POA
 Policies.  Several submission currently in the works will be adding
 new policies to the POA. We propose a generic create_policy() method which can be used
 to create any Policy.  We are open for discussion on the signature,
 but a current thought is something like this:
 
 Policy create_policy(PolicyType policyType, Any policyValue);
 
 

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: Section 7.1 states:
 
 "Destroying a DynAny object implies deleting the buffer it points to and
 also destroying all DynAny objects obtained from it. Invoking operations
 using references to descendants of a destroyed DynAny object leads to
 unpredictable results. Note that releasing a reference to a DynAny
 object will not delete the buffer pointed by the object, since the
 object indeed exists (it has not been explicitly destroyed)."
 
 This does not seem to completely specify the semantics of how destroying
 a DynAny affects its semantics.  If I have 3 DynAnys, DA1, DA2, and DA3,
 where I created DA2 from DA1 using current_component(), and DA3 from DA2
 also using current_component, what are the effects of the following
 operations:
 
 1.  DA1->destroy()
 
 2.  DA2->destroy()
 
 3.  DA3->destroy()
 
 

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-9, section "Iterating through components of a DynAny": The
 first sentence in this section says that DynAny allows iteration
 through structs. It should make it clear that it also allows
 iteration through sequences, arrays, and unions as well.
 

 Revision:   Section 7.2.3 "The DynAny interface", Page 7-9, 

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-13, section 7.2.8: the description of the "length" attribute
 for DynSequence says that the length is set to zero for unbounded
 sequences. This is useless as it confuses bound with length. That
 part of the sentence should be removed. If I want to know the
 sequence bound, I can ask its TypeCode. The DynSequence length
 attribute should be used to get/set the actual length of the sequence
 in the DynSequence regardless of whether its bounded or unbounded.
 

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: * Page 7-16, C++ example: the do-while loop condition should be
 
 while (!found && dyn_struct->next());
 
 That is, the ! negation of next() currently present in the example is
 wrong.
 
 In the same example, the semicolons after the close braces for the
 two "if" statements and the eval_filter() function are all unnecessary.
 
 * Overall: somebody needs to globally substitute "associated with"
 for "associated to" on this entire chapter.
 
 

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: The POAManager processing states diagram does not show an arrow from a
 given state to itself. Does it mean that the state transition from one
 state to the same state is disallowed? The accompanying text does not talk
 about this. 
 
 Suggestion is to allow one state to same state transition without raising
 an exception. The action should be no-op.
 

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 is not (as far as I can see from the spec) any guarantee of
 the order of events when a hierarchy of POAs is destroyed. Because
 ServantActivators are themselves activated in some POA, there is no
 guarantee that when etherialization is performed for one POA that the
 servant activator itself won"t already have been deactivated. 
 

 clarified/fixed

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: How about adding visibility to the Active Object Map.  This would be
 beneficial to a factory-type server application that created and activated
 Servants and also periodically reported status on what it is in its AOM.
 
 Changes to the spec would look something like:
 
 module PortableServer
 {
 	typedef sequence<Object> ObjectSequence;
 	interface POA
 	{
 		ObjectSequence get_active_objects();
 	};
 
 };
 

Summary: 1. Interaction of find_POA() and AdapterActivators and create_POA().
 
 In a single-threaded environment, one can call find_POA() and cause
 an AdapterActivator to be invoked, which will ultimately call create_POA()
 and return control back to the user after completeing the initialization of
 that POA.
 
 In a multi-threaded environment, things are not that simple.  One can call
 find_POA(), which will invoke an AdapterActivator.  Now from here many
 things can happen.  For instance, another thread can come in and call create_POA()
 and create the POA before the AdapterActivator gets a chance to.  The
 AdapterActivator will then need to handle this unexpected condition.
 Granted, this was probably a poorly written program, but properly designed
 APIs should still have defined behavior for even incorrectly written programs.
 

Summary: The POA destroy() operation is ill-defined with respect to what happens
 to requests which are currently executing when destroy() is called.
 

 received issue

Summary: There is also a problem with multiple threads calling destroy() once a destroy() operation has
 begun.  This is particularly important when they set wait_for_completion to true, or if they
 call destroy with a different etherealize_objects value.  My current thought on this is that
 the first thread which calls destroy determines the etherealization policy for the destroy.
 If subsequent threads call destroy() while destruction is in progress they will wait for completion
 if wait_for_completion is true, otherwise they return immediately, and let the intial thread which
 called destroy() complete the destruction.
 
 

Summary: There is currently no defined behavior for what happens when one attempts
 to change the default servant by calling set_servant() when there are already
 activations on the current default servant.  There is a similar problem for
 calls to set_servant_manager() which are just as dangerous.  For instance,
 one could have a ServantLocator installed and have its preinvoke() method
 called, then change the ServantLocator to a new one, and it would have its
 postinvoke() operation called instead of the original ServantLocator.
 

Summary: Several operations on the POAManager and the POA itself have
 a boolean paramter wait_for_completion which is intended to
 block the thread until the operation has completed.  Unfortunately,
 this is not trivial to implement in an arbitrary multi-threaded implementation
 of the POA (or even a single-threaded for that matter).  The semantics of
 wait_for_completion are also quite  muddy in this situation, and we prefer not
 to add complexity to a system when the only gain is some very murky semantics.
 
 We would like to propose that wait_for_completion parameter is ignored
 and always set to FALSE, when the operation is invoked from a thread
 which is executing in a POA context (i.e. if Current::get_POA() returns
 a POA).  Or put another way, wait_for_completion is only meaningful
 when invoked outside the context of the POA by either a user-created
 thread, or in user-event loop (in single-thread environments).
 

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 current POA APIs do not adequately support the use of
 default servants in the POA.  The particular operations of
 concern are servant_to_id, servant_to_reference, and 
 id_to_servant.
 

 Revision:   Section 9.3.8 "POA Interface".

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: The text for the assign operation says:
 
 	If an invalid DynAny object is passed (it has a different typecode
 	or doesn"t contain a meaningful value), the Invalid exception
 	is raised.
 
 Two problems with this:
 
 	- What"s a "meaningful" value, or more pertinently, what"s a
 	  value that isn"t meaningful?
 
 	  I think this needs to be defined a lot more clearly.
 
 	- More seriously, why can"t I assign a DynAny containing a
 	  string to a DynAny containing, say, a structure? I would
 	  have expected assignment to simply do a proper deep copy
 	  of all the components, including the type code. As defined,
 	  I can assign a DynAny to another DynAny only if the target
 	  does not have "a different type code".
 
 	  Was this intentional? If so, what"s the motivation?
 

Summary: The DynAny create operations on the ORB interface use the
 InconsistentTypeCode exception. As far as I can see, that exception is
 never defined. I assume it should be in the ORB interface.
 

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 interface for DynFixed requires me to deal with a fixed-point type
 as an octet sequence. The contents of the octet sequence are simply
 the bytes that would be generated by the CDR marshaling rules for a
 fixed-point value.
 
 Fine, that allows me to get the values in and out, but it is pragmatically
 useless. Do we really expect every application dealing with DynFixed to
 re-implement the marshaling rules? Moreover, at run time, getting the
 value in and out is very complex. Either I use decadic logarithms to
 extract the digit values, or I need to turn the fixed-point value into
 a string and then parse out the digits (never mind that there is no
 standard API call for turning the fixed-point value into a string to
 start with).
 
 >From there, it is still completely unclear how I could turn the fixed-point
 octet sequence (which I now hold as a string or as a series of decimal
 digits) into a value I use to do computation. I would have to multiply
 successive digits into an accumulator, dividing by 10 for every digit.
 
 This is simply useless for all intents and purposes, because it is far
 too much work.
 l

Summary: What does DynAny::CurrentComponent() return if there are no components,
 for example if I iterate over an empty exception or empty sequence?
 

 received issue

Summary: Something a bit strange about component types for DynAny...
 
 For unions, the discriminator and the active member are controlled as
 type DynAny. For sequences and arrays, they are sequences of *any* (not
 DynAny). Yet, when I iterate over a sequence or array, the members are
 dealt with as type DynAny (instead of any).
 
 For structures, if I access the members via iteration, they are accessed
 as type DynAny, whereas if I use set_members() and get_members(), they
 are sequences of name-*any* pairs, not sequences of name-*DynAny* pairs.
 
 I don"t see why, in some cases, components are dealt with as type any,
 and in other cases, they are dealt with as DynAny. Any particular reason?
 
 

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?