Dynamic configuration of components :
In the Scope section of QoS4CCM specification, the following is mentionned:
"Dynamic configuration and re-configuration is also an essential point of
distributed systems, because in order to adapt an application to a specific
execution environment, one has to be aware that the QoS of the execution
environment evolves during execution. There is a strong need to be able to
make on-the-fly adaptation. That is why it is very important to provide an
architecture, mechanisms, and monitoring concepts that allow dynamic
adaptation of a running application, explicitly by an administrator, but
also automatically. The specification addresses this problem domain in the
context of the CORBA Component Model (CCM) [CCM]."

For example reading/writing component's attributes or installing or
uninstalling non-functional properties is necessary. This issue propose to
address this topic which is not concretly resolved in the current
specification.

To achieve this goal, a small evolution is needed. The existing CCM
specification allows some application specific means like home user defined
operations or 'configurator' setting but such mechanisms don't work without
respectively using home finder or dynamic invocations. The necessity to
develop applications that can dynamically reconfigure components and get
knowledge of component configuration in a generic way, bring us to consider
a new configuration mechanism at runtime to facilitate dynamic adaptation of
running application.
We propose to add configuration ability with access of special
'configurator' implementation using component's home interface. We also
propose to improve StandardConfigurator to get component configuration.This
will allow to configure easily non-functional properties at run-time.

If the component is created dynamically, or configured at runtime, the QoS value needs to be configured either via application specific means or by using configurator. Sections are added to support dynamic adaptation of a running application. This implies the modification of the CCM interface StandardConfigurator to be able to retrieve configuration values. HomeConfiguration interface is also modified to be able to retrieve a configurator.

Service configuration :
The QoS4CCM standard doesn't speak about access of QoS Enabler at container
level. The 'install_service_reference' operation definition allos to
register service reference at container level but doesn't allow the
configuration of the services in a standard way. This would be useful to
have a configuration interface and to invoke it at service installation.

We propose to define a standard QoS Usage's interface to make service
configuration and to improve 'install_service_reference' operation
definition.

We propose to define a standard QoS Usage's interface to make service configuration and to improve 'install_service_reference' operation definition. A new interface QoSUsage to the following interface to make service configuration in standard way. The definition is inserted at end of section 8.11.2

Configuration of the underlying middleware:
The « three different realization mecanisms » mentionned in section 1.1 are
not all managed in the specification. Especially the second topic « The
configuration of the underlying middleware, for instance the use of certain
policies of the portable object adapter, or object references, typically in
order for QoS properties to be propagated in a suitable way ».
Interceptor mechanism allows injection of non-functional properties at
interception points, but it is not sufficient to correlate non-functional
properties with component feature out of the calling process. The necessity
to configure the underlying middleware, for instance the use of certain
policies of the portable object adapter, or object references, may be
designed with new interfaces as well as interceptors.
We propose to introduce a means to configure on activation interception
points to configure POA or RT-POA policies on the activation of a facet.
This shall also allow to have "on connection interception" to set easily the
transport protocol policies (SHMIOP, UIOP,...)

We propose to introduce a means to configure on activation interception points to configure POA or RT-POA policies on the activation of a facet. This shall also allow to have "on connection interception" to set easily the transport protocol policies (SHMIOP, UIOP,...).
We propose to add a means to configure the underlying middleware corresponding to the second mechanisms mentioned in section 1.1. This one is not managed by the specification.
Below a section to be added after Negotiation is presented. The mechanism is designed with new interfaces as well as interceptor mechanism.

section 8.6 "ContainerServantStubRequestInfo" shall be
"ContainerServantRequestInfo

Replace the old text with the new one

Interceptor specific registration:
The section 8.7 mentions in a note that « Possible specific registration
operation (e.g., register only for a specific facet) shall be investigated
in FTF. In constraint environments, the need can be to register interceptors
at operation level.
In section 8.3.4 there is no means for interceptor registration on specific
operation of facet. We propose to introduce the ability to specify a port
name and an operation name in order to access easily to these data at
implementation level. No registration interface modifications are needed
here.
As said in section 8.3.4.1 name attribute can be also used to order
interceptors stored into a list. We suggest adding a priority attribute that
should supply such need.

We propose to introduce the ability to specify a port name and an operation name in order to access easily to these data at implementation level. No registration interface modifications are needed here.
As said in section 8.3.4.1 name attribute can be also used to order interceptors stored into a list. An addition of a priority attribute that should supply such need.
Improvement of existing ContainerInterceptor interface in order to allow interceptor registration at facet and operation level.

Section 8.5.5 : write "To write an extended client-side..." shall be
replaced by "To write an extended server-side..."

Replace the old text with the new one

Section 8.5 "A basic Container Interceptor is designed to ..." shall be
replaced by "An extended Container Interceptor..."

Replace the old text with the new one.

Bad section number:
The 8.6.4.6 section shall be 8.6.5 section and 8.6.4.7 to 8.6.4.11 shall be
8.6.5.1 to 8.6.5.5
The 8.7.2.3 section shall be 8.7.3 section and 8.7.2.4 to 8.7.2.5 shall be
8.7.3.1 and 8.7.3.2

Replace the section numbers with the good numbers

IDL inconsistency for ContainerInterceptor interface:
In section 8.3.4, the IDL for CustomSlotItem (identifier is a string) is not
consistent with the one of the AnnexeA.2 section (identifier is an
OctetSeq).

Regarding the resolution of issue No 9740, update the IDL of 'struct CustomSlotItem' in section Annex A.2 with the one in section 8.3.4.
A new repository Id shall be added for CustomSlotItem, CustomSlotItemSeq and COPIServiceContext

Why use separate registration interfaces for each interceptor type?

closed no change

Is it possible for a server (i.e. facet) to require QoS? How?

closed no change

Its not really clear here what is done by the business-logic component executor, what is done by the container, and what is done by QoSEnabler components. Who implements the Negotiation facet? Who makes the require_qos calls?

closed no change

Figure seems not to correspond to the description of extended Interceptors

Figure 8.3 has been updated depicting the extended interception points.

How does the client get the target_id? How does the server get the origin_id? It would seem that IOR components and service contexts would need to be standardized to portably exchange these.

Service Context ID and the content of the service context need to be
standardized. For this reason a subsection has been added to section 8.3

Need to specify whether raising ForwardRequest changes the target persistently, or just for the current invocation

closed no change

Could duplication of Portable Interceptor text be avoided? Why not just reference the descriptions of the PI intercept points in CORBA?

closed no change

Stub_receive_other Paragraph 2, which discusses retries, does not seem to be consistent with the approach of implementing these intercept points by wrapping the ORB-level stub. ORB-level retries would be transparent to the wrapper, and wrapper-level retries would appear to the ORB as independent requests. I don't see how the wrapper could ensure that the PortableInterceptor::Current remains the same, except that the same thread is presumably used.

closed no change

Disign Principles The concepts of Basic vs. Extended Container Interceptors need to be introduced before they are references in the various principals listed here. After reading all of this, I would infer that the Basic COPIs are intended to be called from an ORB-level Portable Interceptor that is part of the container implementation, and that the Extended COPIs are called directly by the container. Is this correct? Could it be stated more explicitly?

To introduce the concept of Basic and Extended Concept beforehand a text
section will be added at the end of section 8.3.1.
In general the implementation of the Container and the used mechanism are
completely transparent, which means a container vendor could implement the
specification in various different ways. However, to implement the basic COPIs
by wrapping the PI and to implement the extended COPIs by calling it directly
from the container is one possible solution and also a most likely one. However,
to state this directly in the spec would possibly constrain the implementation of
the specification too much. For this reason the described solution will be
mentioned as one possible implementation variant by adding text at the end of
section 8.3.1.

Mandatory in Binding class Its not clear what mandatory means. What does it mean for a Binding to exist but not be bound?

More detailed text has been added to explain that.

This needs clarification. Does each COPI get its own slot_id assigned by the container? Does the COPI control what (if anything) goes in this slot?

The usage of the slot id needs more detailed specification to be used in an
interoperable way. The following text will be given in response to this issue:
COPIs are not able to allocate a slot id since this is done in the ORBInitializer
which is executed at component server creation, which is before any user code
(i.e. COPI) is executed. Therefore, a slot id is allocated by the component server
and is communicated to the COPI by using the set_slot_id method. By using this
slot_id Container Portable Interceptors can have access to a PICurrent slot to
exchange thread and call specific information. All COPIs get the same slot id
since the number of registered COPIs is not known beforehand. A definition of
the content of the slot where COPIS can read and add information is also added

Disign Principles Is Principle 3 talking about ORB-level location forwarding? If so, it should be clarified that this redirects not only the current request but also subsequent requests to the new location.

closed no change

Derivation of Registration Interfaces Why isn't StubContainerInterceptorRegistration derived from ClientContainerInterceprotRegistration? Why isn't ServantContainerInterceptorRegistration derived from ServerContainerInterceprotRegistration?

closed no change

StubContainerInterceptionRegistration has several errors. In IDL the local interface name is wrong, the register and unregister method names are wrong and have wrong types. In 8.7.2.4 and .5 headers are wrong

IDL problems have been fixed. Wrong names and headers have been fixed.
Some other minor typos have been fixed.

Argument of register_server_interceptor must be a ServerContainerInterceptor

IDL Problems has been fixed.

8.7.3 has several errors, in description, headers, idl, wrong types, interfaces, etc

Wrong IDL and headers have been fixed.