Issues for Components 2006 Revision Task Force mailing list

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

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

Issue 6001: CCMHome should have a get_container method Jira Issue CORBA31-155
Issue 6286: portability of CCM descriptors Jira Issue CORBA31-156
Issue 6438: CCMHome should have a get_components method Jira Issue CORBA31-157
Issue 6671: [Components] Contradiction between IDL and Interface Repository concerning Jira Issue CORBA31-158
Issue 6672: EnterpriseComponent should have a get_servant method Jira Issue CORBA31-159
Issue 6673: HomeExecutorBase should have a get_servant method Jira Issue CORBA31-160
Issue 6684: The association of entity component primary key and PSS key is unclear Jira Issue CORBA31-161
Issue 6688: EnterpriseComponent should have a get_servant method Jira Issue CORBA31-162
Issue 6689: HomeExecutorBase should have a get_servant method Jira Issue CORBA31-163
Issue 7556: Generic connectivity for Receptacles, Emitters, Publishers Jira Issue CORBA31-164
Issue 7732: EnterpriseComponent should have a set_persistent_object method Jira Issue CORBA31-165
Issue 7733: HomeExecutorBase should have a set_context method Jira Issue CORBA31-166
Issue 9173: add some feature to let an assembly look like a monolithic compoment Jira Issue CORBA31-167
Issue 9174: "supports" keyword Jira Issue CORBA31-168
Issue 10142: Contradictory sections in the CCM and Lightweight CCM specifications Jira Issue CORBA31-169
Issue 10582: The D&C IDL part doesn't match 06-04-02. Jira Issue CORBA31-170
Issue 13151: add a sequence of CCMHome typedef sequence<CCMHome> CCMHomes; Jira Issue CORBA31-171
Issue 14026: spec should define how the base class of an executor is generated by the framework Jira Issue CORBA31-172
Issue 14061: The spec mentions InvalidConfiguration as exception but there is no idl in this spec Jira Issue CORBA31-173
Issue 14064: typedef CCMObjectSeq Jira Issue CORBA31-174
Issue 14087: Event mechanism proposal Jira Issue CORBA31-175
Issue 15051: ResourceCommitmentManager lacking Jira Issue CORBA31-176
Issue 15052: two not used and document exceptions listed Jira Issue CORBA31-177
Issue 15053: DifferentProcess used 2 times Jira Issue CORBA31-178
Issue 15164: HomeConfiguration::set_configuration_values should document exception Jira Issue CORBA31-179
Issue 15960: Incorrect statement that implies that connect_consumer returns a cookie Jira Issue CORBA31-180

Issue 6001: CCMHome should have a get_container method (components-rtf)

The CCMHome interface does not provide a mechanism for locating the container that created a home.  The lack of a method to get a home's container is inconsistent with the rest of the CCM model.  Furthermore, this method would be very useful as it would provide a means to navigate from a component to its ServerActivator, which is currently not possible.    Resolution:    Replace the following text in formal/02-06-05 on page 1-41    interface CCMHome {      CORBA::IRObject get_component_def();      CORBA::IRObject get_home_def ();      void remove_component ( in CCMObject comp)          raises (RemoveFailure);  };    with    interface CCMHome {      CORBA::IRObject get_component_def();      CORBA::IRObject get_home_def ();      void remove_component ( in CCMObject comp)          raises (RemoveFailure);      Container get_container();  };    and add the operation description    get_container    The get_container operation returns a reference to the Container object that created this CCMHome

Identifier (FPI).     These FPIs are required for the CAD, CSD, CCD and CPF DTDs.     Proposed resolution:     Adds the CCM DTDs on the OMG web site and adds the following text in the specification:     * section 6.3, before subsection 6.3.1 :     The CORBA Software Descriptor must refer to the DTD using the following statement: <!DOCTYPE softpkg PUBLIC "-//OMG//DTD CORBA Software Descriptor 3.0//EN" "https://www.omg.org/dtd/softpkg_3_0.dtd" />     * section 6.4, before subsection 6.4.1 :     The CORBA Component Descriptor must refer to the DTD using the following statement: <!DOCTYPE corbacomponent PUBLIC "-//OMG//DTD CORBA Component Descriptor 3.0//EN" "https://www.omg.org/dtd/corbacomponent_3_0.dtd" />     * section 6.4.4:     replace     <!DOCTYPE corbacomponent SYSTEM "corbacomponen.tdtd">     with     <!DOCTYPE corbacomponent PUBLIC "-//OMG//DTD CORBA Component Descriptor 3.0//EN" "https://www.omg.org/dtd/corbacomponent_3_0.dtd" />     * section 6.7, before subsection 6.7.1 :     The Component Assembly Descriptor must refer to the DTD using the following statement: <!DOCTYPE componentassembly PUBLIC "-//OMG//DTD Component Assembly Descriptor 3.0//EN" "https://www.omg.org/dtd/componentassembly_3_0.dtd" />     * section 6.7.1:     replace     <!DOCTYPE componentassembly SYSTEM "componentassembly.dtd">     with     <!DOCTYPE componentassembly PUBLIC "-//OMG//DTD Component Assembly Descriptor 3.0//EN" "https://www.omg.org/dtd/componentassembly_3_0.dtd" />     * section 6.8, before subsection 6.8.1 :     The Component Property File must refer to the DTD using the following statement: <!DOCTYPE properties PUBLIC "-//OMG//DTD Component Property File 3.0//EN" "https://www.omg.org/dtd/properties_3_0.dtd" />   

The CCMHome interface does not provide a mechanism for obtaining references to all CCMObjects that the home has created (those that have not been removed).  The lack of a method to get all the components created by a home is inconsistent with other sections of the CCM model (specifically the deployment module APIs).  Furthermore, this method would be very useful as it would provide a mechanism for querying a Container for all existent components.      Resolution:      Replace the following text in formal/02-06-05 on page 1-41      interface CCMHome {      CORBA::IRObject get_component_def();      CORBA::IRObject get_home_def ();      void remove_component ( in CCMObject comp) raises (RemoveFailure);  };      with      typedef sequence<CCMObject> CCMObjects;      interface CCMHome {      CORBA::IRObject get_component_def();      CORBA::IRObject get_home_def ();      void remove_component ( in CCMObject comp) raises (RemoveFailure);      CCMObjects get_components();  };      and add the operation description      get_components      The get_components operation returns a sequence of all existent CCMObject references (i.e. those that have not been removed) created by this CCMHome.

According to the IDL language it is allowed to define a facet/receptacle on a component with type of Object. The text says:        A facet is declared with the following syntax:  (120) <provides_dcl> ::= �provides� <interface_type> <identifier>  (121) <interface_type> ::= <scoped_name>  | �Object�  The interface type shall be either the keyword Object, or a scoped name that denotes  a previously-declared interface type which is not a component interface, ...        In contradiction to that the Interface Repository element for a component, the ComponentDef, does only allow the creation of facets/receptacles with type of InterfaceDef. The according operations are:        // write interface  ProvidesDef create_provides (  in RepositoryId id,  in Identifier name,  in VersionSpec version,  in InterfaceDef interface_type  );  UsesDef create_uses (  in RepositoryId id,  in Identifier name,  in VersionSpec version,  in InterfaceDef interface_type,  in boolean is_multiple  );        Thus the ComponentDef can not be used to create a facet/receptacle that is of type Object, since Object is no InterfaceDef but a PrimitiveDef.  One solution would be to use IDLType instead of InterfaceDef since PrimitiveDef and InterfaceDef inherit from that interface. My proposal is to change the Interface Repository IDL in the following way.      1) replace in ComponentDef:      // write interface  ProvidesDef create_provides (  in RepositoryId id,  in Identifier name,  in VersionSpec version,  in IDLType interface_type  );  UsesDef create_uses (  in RepositoryId id,  in Identifier name,  in VersionSpec version,  in IDLType interface_type,  in boolean is_multiple  );      2) replace ProvidesDef, ProvidesDecsription, UsesDef, UsesDescription with      interface ProvidesDef : Contained {  // read interface  readonly attribute IDLType interface_type;  };      struct ProvidesDescription {  Identifier name;  RepositoryId id;  RepositoryId defined_in;  VersionSpec version;  IDLType interface_type;  };      interface UsesDef : Contained {  // read interface  readonly attribute IDLType interface_type;  readonly attribute boolean is_multiple;  };      struct UsesDescription {  Identifier name;  RepositoryId id;  RepositoryId defined_in;  VersionSpec version;  IDLType interface_type;  boolean is_multiple;  };  

The EnterpriseComponent should have a get_servant method. When creating component or facet reference of service or session component, the first step is creating the object reference and associating its PortableServer::ObjectId with servant. Currently, the container manages executor, but the EnterpriseComponent interface does not provide a mechanism to get servant. The method would be very useful as it means the container can use executor to get servant, which is not possible now.     Resolution:     Replace the following text in formal/02-06-05 on page 3-39     module Components { local interface EnterpriseComponent {}; };     with     module Components { local interface EnterpriseComponent { Servant get_servant() raises (CCMException); }; };     and add the operation description     get_servant     The get_servant operation returns a reference to the servant.  

The HomeExecutorBase should have a get_servant method. When creating component or facet reference of service or session component, the first step is creating the object reference and associating its PortableServer::ObjectId with servant. Currently, the container manages executor, but the HomeExecutorBase interface does not provide a mechanism to get servant. The method would be very useful as it means the container can use executor to get servant, which is not possible now.     Resolution:     Replace the following text in formal/02-06-05 on page 3-40     module Components { local interface HomeExecutorBase {}; };     with     module Components { local interface HomeExecutorBase { Servant get_servant() raises (CCMException); }; };     and add the operation description     get_servant     The get_servant operation returns a reference to the servant.  

Issue: The association of entity component primary key and PSS key is unclear. There is only one attribute as the primary key in the CCM entity component, PSS has no primary key. An entity can be identified uniquely by the PSS key, but currently PSS permits several keys, and each PSS key can be composed of several attributes. Consequently, it is difficult to establish association between entity component primary key and PSS key, and the create and find methods can not to be mapped to the corresponding methods of PSS.  

When creating component or facet reference of service or session  component, the first step is creating the object reference and  associating its PortableServer::ObjectId with servant. Currently, the  container manages executor, but the EnterpriseComponent interface does  not provide a mechanism to get servant. The method would be very useful  as it means the container can use executor to get servant, which is not  possible now.      Resolution:      Replace the following text in formal/02-06-05 on page 3-39      module Components {   local interface EnterpriseComponent {};  };      with      module Components {   local interface EnterpriseComponent {    Servant get_servant()     raises (CCMException);   };  };      and add the operation description      get_servant      The get_servant operation returns a reference to the servant.    

This question is similar to the first one. When creating component or  facet reference of service or session component, the first step is  creating the object reference and associating its  PortableServer::ObjectId with servant. Currently, the container manages  executor, but the HomeExecutorBase interface does not provide a  mechanism to get servant. The method would be very useful as it means  the container can use executor to get servant, which is not possible now.      Resolution:      Replace the following text in formal/02-06-05 on page 3-40      module Components {   local interface HomeExecutorBase {};  };      with      module Components {   local interface HomeExecutorBase {    Servant get_servant()     raises (CCMException);   };  };      and add the operation description      get_servant      The get_servant operation returns a reference to the servant.  

The CCMObject interface contains numerous operations for generic  connection management (in addition to the type-specific operations  defined by equivalent IDL for a component).      However, there's a separate set of "connect" and "disconnect"  operations for each kind of port, i.e., receptacles, emitters and  publishers. This is inconvenient for generic software that treats  ports generically, such as the deployment infrastructure in an  implementation of the Deployment and Configuration specification.      The set of operations might even get larger in the future, when  Streams for CCM becomes available.      I thus propose to add generic "connect_feature" and "disconnect_  feature" operations that is able to interconnect compatible ports  regardless of the type of port.      Proposed resolution:      In section 1.11.1, "CCMObject Interface," add the following two  operations to the CCMObject interface:      module Components {    interface CCMObject : Navigation, Receptacles, Events {      Cookie connect_feature (in FeatureName name,                              in Object connection)        raises (InvalidName, InvalidConnection, AlreadyConnected,                ExceededConnectionLimit);      void disconnect_feature (in FeatureName name,                               in Cookie ck)        raises (InvalidName, InvalidConnection, CookieRequired,                NoConnection);      /* other operations as before */    };  };      Add the following explanation to the same section:        connect_feature        The connect_feature operation connects the object reference    specified by the connection parameter to the component feature    specified by the name parameter. The feature must be either a    receptacle, emitter or publisher port.        If the feature identified by the name parameter is a receptacle    port, the connect_feature operation acts equivalent to calling    the connect operation on the Receptacles interface.         If the feature identified by the name parameter is an emitter    port, the connect_feature operation acts equivalent to calling    the connect_consumer operation on the Events interface. A nil    "cookie" value is returned.        If the feature identified by the name parameter is a publisher    port, the connect_feature operation acts equivalent to calling    the subscribe operation on the Events interface.        If the feature identified by the name parameter is neither    receptacle, emitter or publisher port, or if the component does    not have any feature by that name, the InvalidName exception is    raised.          disconnect_feature        The disconnect_feature operation dissolves the connection    identified by the ck cookie to the component feature specified    by the name parameter.        If the feature identified by the name parameter is a receptacle    port, the disconnect_feature operation acts equivalent to calling    the disconnect operation on the Receptacles interface.         If the feature identified by the name parameter is an emitter    port, the disconnect_feature operation raises the InvalidConnection    exception if a non-nil cookie is passed as the ck parameter;    otherwise, it acts equivalent to calling the disconnect_consumer    operation on the Events interface.        If the feature identified by the name parameter is a publisher    port, the disconnect_feature operation acts equivalent to calling    the unsubscribe operation on the Events interface.        If the feature identified by the name parameter is neither    receptacle, emitter or publisher port, or if the component does    not have any feature by that name, the InvalidName exception is    raised.

There is no standard way for container to intercept component state management.  By which container can implement O/R mapping and management component states.     Resolution:     Container can intercept state management by provide a storage object for executor segment.  Replace the following text in formal/02-06-05 on page 3-39     module Components  {   local interface EnterpriseComponent    {             };  };     with     module Components  {   local interface EnterpriseComponent    {          void set_persistent_object(in StorageObjectBase);   };  };     and add the operation description     set_persistent_object      Set context object for executors

Home executor cann't access context object. Thus some features like SMP(Self-Management Persistence) are not enabled.     Resolution:     Replace the following text in formal/02-06-05 on page 3-40     module Components {   local interface HomeExecutorBase {};  };     with     module Components {   local interface HomeExecutorBase {      void set_context(in CCMContext con);   };  };     and add the operation description     set_context     Set context object for home executor.  

It is better to add some feature to let an assembly look like a monolithic compoment. For example, add some discriptions in CAD(compoment assembly discription) file to identify the external interface of an assembly. There exists an delegate compoment behaving like the assembly. It can navigate one external interface of an assembly to another. This delegate compoment can be created by main component server automatically according to the CAD file.   

Issue: It is good to let CCM component definition can have operations directly, but not indirectly by "supports" keyword. The "supports" adds too much complexity when defining a compoment and compiler implementation  

I'd like to report an issue that exists in both the CORBA Component Model Specification (formal/06-04-01) and also the Lightweight CORBA Component Model specification (ptc/04-06-10) please.      In section "6.11 Component Inheritance" of formal/06-04-01 there is the statement : "A derived component type may not directly support an interface."      This same statement is made in "1.11 Component Inheritance" of ptc/04-06-10 and in "3.17.2.3 Component Inheritance" of the CORBA 3.0.3 spec (04-03-02).      But, in both "6.3.2.4 Inheritance and supported interfaces" of formal/06-04-01 and "1.3.2.4 Inheritance and supported interfaces" of ptc/04-06-10 there is the following:      "For a component declaration with the following form:        component <component_name> : <base_name>    supports <interface_name_1>, <interface_name_2> { � };      the equivalent interface shall have the following form:    interface <component_name>    : <base_name>, <interface_name_1>, <interface_name_2> { � };"      The above example is giving equivalent IDL for a declaration that the preceding statements regarding component inheritance say is not permitted. It should presumably be removed.    

The D&C IDL part doesn't match 06-04-02. For example TargetManager is not correctly in 06-04-01 and has its errors in 06-04-02  

We would like to add a request to add the following IDL type. Just add a sequence of CCMHome typedef sequence<CCMHome> CCMHomes;  

The LwCCM removes the usage of cidl from CCM, but this looses also the fixed name of the base class of the executor. The spec should define how the base class of an executor is generated by the framework, so that the implementor of the executor can write a portable executor  

The spec mentions InvalidConfiguration as exception but there is no idl in this spec that describes this exception and its members  

In section 10.3.1.2 the typedef CCMObjectSeq is listed, we propose to move it to Section 6.11.1 just after the definition of CCMObject  

The CCM spec describes the event mechanism default part of CCM. We want to propose to change this event machine to a connector based model as part of the DDS4CCM specification. Then there would be an event connector and the container then is much more light weight and easier to use. People that don't want to use CORBA event machinisms don't pull in all the dependent code   

The IDL file 07-02-01 related to CCM is lacking ResourceCommitmentManager

The IDL file 07-02-01 related to CCM we have the following exceptions        exception LastConfiguration {    };        exception InvalidReference {    };      LastCOnfiguration is not listed at all in 06-04-01 and 06-04-02    InvalidReference is listed in 06-04-02 in text and diagrams, but not in idl at all

DifferentProcess is used in LocalityKind and in PlanLocalitiyKind. This will result in illegal idl because both enums are in the deployment module. We propose to prefix all values in PlanLocalityKind with Plan

HomeConfiguration::set_configuration_values documentation should mention which exception to thrown when an any/name value pair has a not supported name or when the any can't be extracted

In chapter 6.6.8, sub paragraph "connect_consumer" the following statement is given:      The cookie return value can be used to disconnect from the source.      I think that this sentence should be removed from the specification since connect_consumer is declared as follows:      void connect_consumer (    in FeatureName emitter_name,    in EventConsumerBase consumer)      raises (InvalidName, AlreadyConnected,               InvalidConnection);    Also, disconnect_consumer doesn't provide a cookie as input parameter.