Issues for Components RTF mailing list

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

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

Issue 2204: Locality constrained objects + externalization
Issue 2227: Versioning needed for CORBA Core
Issue 2301: Locality-constrained objects
Issue 2611: Policies not locality-constrained?
Issue 3065: CCM Issue: CIDL Syntax doesn't allow for modules
Issue 3197: Use of undefined "id" attribute
Issue 3198: Purpose of "name" element
Issue 3199: atribute not part of definition
Issue 3208: PACKAGING AND DEPLOYMENT METAMODEL
Issue 3229: Components: Relationship of CIDL and PSDL unclear
Issue 3230: Components: readonly_attr_declarator slightly ambiguous
Issue 3232: Missing Rights Combinator in Security deployment descriptor
Issue 3233: IFR backward compatibility broken
Issue 3236: destroy() for local objects
Issue 3260: EJB/CCM mappings for the IR
Issue 3299: Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01
Issue 3412: CCM issue chapter 69 ptc/99-10-04
Issue 3419: Bridge Interoperability of the Java mapping with the EJB-to-CCM mapping
Issue 3647: operation <string get_implementation(in string iuuid)> Why does not CCMHome include the operation create_component() ?
Issue 3648: Why does not CCMHome include the operation create_component() ?
Issue 3649: p.615-85 ToonTownImpl
Issue 3650: In example p.615-86
Issue 3651: Where is HomeExecutorBase interface defined?
Issue 3725: Issue On the use of typed home (or CCMHome subtypes)
Issue 3726: Issue on Assemblies and descriptors
Issue 3746: Pbl: Improper mapping rule from IDL3 to IDL2 when dealing with events.
Issue 3785: operation get_implementation() referenced but not declared
Issue 3786: What about valuetype factories?
Issue 3925: range description in CPF files.
Issue 3926: simple ELEMENT definition
Issue 3928: Local push() operation.
Issue 3929: ExecutablePlacement definition
Issue 3930: exception raised by Components::Events::subscribe()
Issue 3937: Channel Setup for Emits ports.
Issue 3938: Intent of Components::Events::(un)subscribe to bypass the notif. service ?
Issue 3939: An assembly is always mono-vendor ???
Issue 3954: equivalent interfaces issue
Issue 3955: push() versus push_event()
Issue 3977: Services available for a basic container
Issue 3982: Deployment Object Life Cycles
Issue 3985: description element need to be added to corbacomponent.dtd
Issue 3986: repository element needed by softpkg DTD
Issue 3987: typo in connections element definition
Issue 3993: CCM Events issue
Issue 3996: IDL question concerning CCM
Issue 3997: No user access to filterable body in CCM spec.
Issue 3998: No Access to event filter form component
Issue 4011: grammar rule for home_executor_body contradicts description
Issue 4024: Typo in assembly element paragraph heading
Issue 4025: New component issue: connection failure recovery
Issue 4073: Components, Facets, and Object References Unclear
Issue 4075: Inter-component type semantics unclear
Issue 4077: Component assemblies do not follow composition pattern
Issue 4078: Component assembly templates
Issue 4079: Component home polymorphism
Issue 4080: Component home interface inheritance
Issue 4081: Problems with the Components Notification Event Interface
Issue 4116: Extended Interface Repository
Issue 4136: ComponentIR Interface fixes
Issue 4140: Components FTF: TypeCodeFactory
Issue 4203: CCM : Session2Context and Servants
Issue 4204: CCM : Session2Context naming
Issue 4214: CCM: usage of the MOF profile
Issue 4269: IDL out parameters can't map to EJB?
Issue 4307: CCM: Chapter 66 should be removed
Issue 4329: "supports" terminology issue for CCM
Issue 4412: Component port introspection
Issue 4529: Incorrect syntax in Components::Enumeration
Issue 4540: explicit definition of CCM exceptions mapped from EJB standard exceptions
Issue 4574: Issue for Components: Missing language mapping
Issue 4576: CCM: Isolated scope tokens
Issue 4577: CCM: Definition of import declaration unclear
Issue 4578: CCM: import and re-opening of modules
Issue 4579: CCM: Meaning of "exposed" scopes unclear.
Issue 4716: Little problem with introspection API
Issue 4717: minor IDL changes required in CCM API
Issue 4983: Generic operations for subscribing/unsubscribing at publishing ports
Issue 4986: IDL3 keyword "eventtype" conflicts with struct "CosNotification::EventType
Issue 5091: components-ftf: repository id in software package descriptor
Issue 5092: components-ftf: registercomponent element
Issue 5093: components-ftf: connectevent element
Issue 5340: Issue regarding language mapping for keyless homes
Issue 5429: simple type element of the property file issue
Issue 5492: Issues related to CCM's XML descriptors: chapter 69.4.4
Issue 5493: Issues related to CCM's XML descriptors: chapter 69.4.5.4
Issue 5494: Issues related to CCM's XML descriptors: chapter 69.4.5.16
Issue 5495: Issues related to CCM's XML descriptors: chapter 69.7.2.25
Issue 5496: Issues related to CCM's XML descriptors: chapter 69.7.2.38
Issue 5497: Issues related to CCM's XML descriptors: chapter 695.4
Issue 5498: CIDL Grammar problems: Productions must be renumbered : 134 -> 1, ... paragraph 60.2.1 : There is two mistakes in keywords
Issue 5499: paragraph 60.2.1 : There is two mistakes in keywords
Issue 5500: Productions 140, 141, 142 and 143 must be removed
Issue 5506: Typo (??) in chapter 61
Issue 5507: 69.8.2 Property File XML Elements
Issue 5577: create operation of AssemblyFactory interface
Issue 5583: Remove section 4.4.1.4 in formal/02-06-65
Issue 5584: Corrections in XML DTDs for packaging
Issue 5585: Editorial issues in formal/02-06-65
Issue 5588: Update Table 5-13 in the EJB Chapter of formal/02-06-65
Issue 5683: Derived component supported interface restriction
Issue 5906: insufficient examples of component attributes
Issue 7902: sections 1, 3, 4, 5 essentially empty
Issue 7903: Section 7, Overview
Issue 7911: On Page 18 - Figure 11 Home mapping
Issue 7912: Section 7.2
Issue 7913: Minor comments re Components FTF
Issue 7914: use the proper notation for expressing Profiles
Issue 7915: Figure 1
Issue 7916: Section 7.1, line1:
Issue 7917: - Figure 2
Issue 7918: 7.2, sentence 3
Issue 7919: Section 8.1.1
Issue 7920: Sections 8.1.1, 8.2.1:

Issue 2204: Locality constrained objects + externalization (components-ftf)

Summary: Here"s an interesting question. How do you prevent the externalization of
   an l-c object? The user can create a reference to the l-c object *before*
   the l-c object has been bound to the POA itself. This means that the     
   reference can be externalized, and calls could presumably come into      
   the POA for this l-c object. What should the result of this call be?     
   OBJECT_NOT_EXIST?   
 

The only portable mechanism to implement locality constrained objects is LocalObject, which does not involve the
POA.

Summary: At present there is no formal mechanism or process for versioning the
 CORBA Core. Indeed, it is somewhat hard to figure out what is part of
 the CORBA Core. In Rev 2.3 we tried to at least bring all the IDL for
 the Core together in pieces at logical places, e.g. ORB interface,
 Object interface, IR Interfaces etc. In addition we also have the
 PortableServer module and the GIOP and related modules, the versions of
 all of which have to match for the resulting system to have any hope of
 working as advertized.  I guess the basis of the current state of
 affairs is that - the vendor delivers the core, and therefore one can
 trust the vendor to deliver the right things. This model tends to break
 down in situations where people can download bits and pieces of a Java
 ORB at different times and then try to make the whole thing work
 together. 
 

The general versioning problem could not be dealt with by the Components FTF
as it is too general and out of the scope of this FTF. However this should be the
subject of a future RFP issued both in the Platform and Domain Technical
Committees.
Let's note that the changes in the CORBA Core implied by the CCM are only
related to the OMG IDL grammar (i.e. new keywords and EBNF rules), the new
CORBA::Object::get_component operation, the Interface Repository and
CORBA::TypeCode interfaces. All other CCM APIs are defined in the separate
Components module.

Summary: something about locality-constrained objects... The spec says that LC objects
 are local, so I cannot pass reference to another process or use
 object_to_string with them. There are no other restrictions so, by
 implication, LC objects can do everything a normal object can do. In paricular,
 I can invoke operations on LC objects via the DII, I get preinvoke and
 postinvoke calls from a servant locator, and the reference for an LC object
 and its servant have independent life cycles.
 
 This seems rather strange.

The DII issues are covered in issue 3177.  The only portable mechanism to implement locality constrained objects is
LocalObject, so no servant locator is involved. LocalObject specifies that the reference and implementation lifecycles are
equivalent.

Summary: the current spec doesn"t list policy objects as locality constrained.
 This seems rather strange. In particular, at the time I create policy objects,
 there is no POA that could be responsible for them, and I have no way
 to associate a policy object with a particular POA.
 Of course, this raises the question of whether references to policy objects
 are persistent or transient, whether I can pass them to another address
 space, whether requests on them are single-threaded or not, etc, etc.
 

Section 11.1.5 of the components submission identifies the interfaces that are changed to local, including "all the
interfaces in the PortableServer module".  These changes will be incorporated into the CORBA 3.0 specification.

The FTF draft does not allow a CIDL composition to be
included in a module.

Discussion: In the FTF Draft, the CIDL BNF (Section 60.3) is not yet
tied into IDL syntax. As it stands, a composition cannot be embedded
in a module. The draft recognizes that with the note (Section 60.4):

The CCM FTF draft document ptc/99-10-04 does not fully describe the CIDL
grammar, i.e. relationship between CIDL, PSDL, and IDL grammars,
compositions declared into modules.
CIDL is a language to describe compositions, i.e. the structure and state of
component implementations. In order to declare and refer state definitions, CIDL
is a superset of PSDL as stated in the orbos/99-07-01 document. Moreover CIDL
is also a superset of OMG IDL in order to refer home and component definitions.
Then the CIDL grammar must be a combination of the PSDL and IDL grammars
plus the composition rule.

I have a number of issues with the Software Package Descriptor section of
the CCM specification (Component Spec - Volume I, orbos/99-07-01.) I have
not found answers to issues raised below in either the components-ftf
archive, or the issues list.

ISSUE - The softpkg descriptor example uses an "id" attribute, which isn't
defined in the softpkg.dtd.

>From page 10-305, 10.2.1 A softpkg Descriptor Example, CORBA Components -
orbos/99-07-01:

	<idl id="IDL:M1/Bank:1.0" ><link href="ftp://x/y/Bank.idl"/></idl>

According to the softpkg.dtd, (page B-435, B.1 softpkg.dtd, CORBA Components
- orbos/99-08-05, ) the idl element is defined as follows:

<!ELEMENT idl
	( link
	| fileinarchive
	| repository
	) >

The same definition can also found in section 10.2.2.14, The idl Element (,
page 10-311, CORBA Components - orbos/99-07-01.) There are no attributes
defined for the idl element.

In ptc/99-10-04 section 69.3.1 page 69-260, the following
<idl id="IDL:M1/Bank:1.0" ><link href="ftp://x/y/Bank.idl"
/></idl> describes what the repository Id is and where the IDL file is located for the
softpkg descriptor example.
Require to add "id" to the list of attributes of the "idl" element in the softpkg XML
DTD.

ISSUE - What is the purpose of the "name" element as used in the
"dependency" element?

See section 10.2.2.7, The dependency Element (, page 10-308, 10.2.1 A
softpkg Descriptor Example, CORBA Components - orbos/99-07-01.) Section
10.2.2.20, The name Element, describes the name element as an optional
element of the "author" element, and is meant to identify the author. So
does the name element identify the author of the dependency, or is it used
to identify the dependency itself?

Resolution:
Require to update the text describing the name element of the softpkg XML DTD
as this element is an optional child element of both the author and dependency
elements. When used as a child of author, it specifies the name of the author.
When used as a child of dependency, it specifies the expected value of the
dependency.

ISSUE - The description of the "implementation" element explains the
"variation" attribute, but the attribute is not part of the definition. 

>From page 10-32, CORBA Components - orbos/99-07-01: "The variation attribute
is used to indicate a variation from a normal implementation." But the
definition of the implementation attribute list only lists the "id"
attribute. The variation attribute is not part of the definition as given in
softpkg.dtd either (, page B-419, B.1 softpkg.dtd, CORBA Components -
orbos/99-08-05.)

Require to add "variation" to the list of attributes of the "implementation" element
in the softpkg XML DTD.

1) Some concepts from the CORBA metamodel (component, facet, receptacle,
event publishing/emission/consumption) are also in P/D metamodel but the
definitions from the CORBA metamodel are not directly reused.  

Recommendation: Analyze where reuse is appropriate and adjust the P/D
metamodel accordingly.

2) The P/D metamodel has the notion of files (e.g. configuration property
files and some other files) where some metadata are stored.  The hand-coded
DTDs treat these files as types in their own right, i.e. they conceptualize
them as files, and some of the other types point to the file types.  This
is approach is mimicked in the metamodel.  However, it might not make sense
in the metamodel because, in a repository context, you are referencing
other information in the repository and not necessarily a file.   The way
the metamodel is now, when something references one of these files you lose
the metadata trail.  The file metaclass itself does not have structural
features pointing to metaclasses that define the contents of the file.  You
have to go elsewhere (i.e. to the property file Package) to get that
metadata and there is no reference to the property file Package.

Recommendation: It might make more sense for references to the file
metaclass to instead reference the top level element of the property file
Package so that you can "follow the metadata trail." If someone wants to
break out the properties metadata in a file, then the generated DTD should
allow that, i.e. the part that needs to go into a properties file should be
able to be self-contained without external references.

This issue points out only two problems of the packaging and deployment model.
There are lot of other problems and there are lots of inconsistencies between the
meta model and the deployment descriptors. For this reason, it is better to
remove the Packaging and Deployment meta model and to address this by a
future RFP process.

The draft component specification (ptc/99-10-04) explains that CIDL is
a superset of IDL. This is a derivation from the specification
voted-on in the PTC (orbos/99-07-01), which specified that CIDL is a
superset of PSDL.

Also, declaring CIDL not to be a superset of PSDL means that the
<catalog_use_dcl>, <abstract_storage_home_binding> etc become
meaningless, as they refer to entities from PSDL.

Proposed Resolution: Declare CIDL to be a superset of PSDL.

In ptc/99-10-04, the production 104

<readonly_attr_declarator >::= 
    <simple_declarator> [ <raises_expr> ] 
  | <simple_declarator> { "," <simple_declarator> }*

is ambiguous, since a sole <simple_declarator> could either denote the
first alternative (with no <raises_expr>), or the second alternative
(with the simple-declarator-list omitted). Even though this does not
constitute a serious problem, it is also easy to fix:

<readonly_attr_declarator >::= 
    <simple_declarator> <raises_expr>
  | <simple_declarator> { "," <simple_declarator> }*

The production 104 is ambiguous and is replaced by the rule provided by the
issue submitter.

In section 69.4.5.45, the "rights" element is mentioned, but the "rights
combinator" elemnt is not. Given a set of "rights" it is not possible to
determine how to cobine them without the "rights combinator" as specified in
CORBAsec. Suggest we add a "rights cobminator" element, consistent with the
definition of rights combinator in CORBAsec.

The CCM FTF draft document ptc/99-10-04 does not provide the required
information needed to set the required rights for an operation since the rights
combinator is missing. A rightscombinator attribute must be added to the
security element of the CORBA component descriptor DTD.

Moving existing interfaces from the CORBA module to a new IR module breaks
backward compatibility. Hence they should be moved back to the CORBA module. The
elements that are newly added can go into a new module, and interfaces
corresponding to the existing ones with the same names can be placed in the new
module, with these interfaces deriving from the existing corresponding
interfaces in the CORBA module, thus allowing all CORBA3 IR interfaces to be
accessed from a single module.

This also fixes a related problem regarding separation of the TypeCode stuff,
specifically TypeCode factory. It is broken in the current spec because certain
types used by the typecode factory were inadvertently moved to the IR module.

Resolution:
The Interface Repository interfaces are moved back to the CORBA module to not
break backward compatibility. New OMG IDL constructions introduced by the
CCM, i.e. home, component and ports, are reflected by new OMG IDL interfaces
contained in the new CORBA::ComponentIR module.
The last draft of the CORBA Chapter 10 "The Interface Repository" is available in
OMG TC Document # ccm/2001-08-01 and the full OMG IDL is available in OMG
TC Document # ccm/2001-08-02.

every ORB I know of implements the various destroy() operations on
local objects (such as policies or DynAny) as a no-op and destroys the local
object on the final call to release() instead. Yet, the spec still requires
programmers to call destroy(). The problem with this is that programmers
can easily end up writing non-portable code without any visible problem.
Then, when code is moved to another ORB, it is conceivable that it will
leak objects.

This isn't very pretty. I think we should get rid of the destroy() calls
on local objects (possibly with the exception of the ORB object, although
the entire shutdown issue for that is quite a mess anyway). It doesn't
make sense to require the programmer to make a destroy() call for something
that naturally can be reference counted.

When the interfaces identified in section 11.1.5 are updated to be local interfaces, any destroy() operations should
be deprecated using the text below.  Note that this does not include CORBA::ORB.

The mapping between EEJB metadata and the IR is missing in the
current specification .Resolution: Define the mapping

Given that the information needed to implement the EJBMetadata interface for a
given EJB (in particular, for one that is the mapping of a CORBA Component) is
available from the Java runtime, it is not necessary to define a mapping between
EJB metadata and the IR. That is, for the purposes of implementing
EJBMetadata, which is the only concern in this issue, a mapping between EJB
metadata and the IR is not required. An example of this implementation involves
looking up class information in the classpath for the EJBMetadata methods that
require this information (getHomeInterfaceClass, getRemoteInterfaceClass,
getPrimaryKeyClass), and caching information obtained at generation time for
the remaining EJBMetadata methods (getEJBHome, isSession and
isStatelessSession).

Document orbos/99-08-13, line 9 and further, contradicts with
orbos/99-07-01,
Chapter 4.4. The production rules for typePrefix and typeId contain a
";",
where file orbos/99-08-13 omits them.

Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01,
Chapter 4.2. The production rules for import contain a ";",
where file orbos/99-08-13 omits them.

Resolution:
Require to add ';' at the end of lines 1-6 and 9 in orbos/99-08-13 in order to be
compliant with the CCM specification (ptc/99-10-03) and to replace typePrefix by
typeprefix (see Issue 3216).

What exactly is meant in chapter 69.7.2.3 by component archive file? It is
not defined anywhere. Is it a software package descriptor or a software
package? At least it is not a CORBA component descriptor as shown in the
example in chapter 69.7.1. The text there is like:

<componentfile id="A">
    <fileinarchive name="ca.ccd"/>
...

Is the sufix ccd right?

Resolution:
The referred file has to contain a SoftwarePackageDescriptor in order to get
information about actual implementations. Thus the example at the beginning of
69.7.1 must be changed. The suffix ccd must change to “csd”.

he following sub-issues need to be addressed to make sure that CCM/EJB
bridge implementations are interoperable. In particular, these sub-issues
have in common that the current definition of the bridge relies on the
Java-to-IDL mapping, which in certain cases does not match the requirements
of the EJB-to-CCM mapping.

Sub-issue: METHOD NAMES IN STANDARD INTERFACES

The names for some methods defined on standard interfaces, for example
<home-name>Implicit.find_by_primary_key or <home-name>Implicit.create,
differ from the names that their EJB counterparts get mapped to under
Java-to-IDL (in the example these would be
<home-name>.findByPrimaryKey and create__keytype, respectively). When
this happens, the translation from one form of the name to the other
can happen at either the client or the server side of the bridge. FOR
INTEROPERABILITY, it is necessary to eliminate this ambiguity. Choices
for doing this include requiring the client stub to always do the
translation or requiring the server skeleton to take into account both
name forms.

The actual problem we are getting hit by here is overloaded names. Methods
like remove and create in EJBHome and user-defined EJB homes can only be
mapped to remove__XXX and create__XXX under Java-to-IDL, yet the
definitions of the corresponding methods in <home-name>Implicit are remove
and create, respectively. I can understand that these implicit home names
were defined as such because <home-name>Implicit is a standard interface
(although the fact that its name is prefixed by <home-name> is a bit
troubling) and, if for no other reason, because the XXX in create_XXX
cannot be known in general. So, if we stick to the standard names, there is
a mismatch. Notice however that I said that the mapping is done under
Java-to-IDL. Perhaps I should not say that but the CCM spec is not clear
about this and in fact it states that the create methods in an EJB home are
mapped to factory names under Java-to-IDL. So we may actually be talking
about two different issues: (1) use different mapping rules for create with
no primary key, in which case we need to ammend the spec to this effect;
(2) perform a translation, in which case we have an interoperability issue.

Sub-issue: HANDLING STANDARD EXCEPTIONS

Standard exceptions thrown by EJB methods, such as
DuplicateKeyException, have a mapping specification to IDL (under the
current Java-to-IDL specification) that does not match the exceptions
that they map to under the CCM spec (in the example this would be
DuplicateKeyValue). This requires that the bridge perform a run-time
translation of exceptions from the Java-to-IDL mapping to the CCM
mapping at either the client stub or the server skeleton. FOR
INTEROPERABILITY, it is further necessary that the location of the
translation be fixed. Early prototype implementation suggests that it
is more advantageous for the client stub to perform the translation
since otherwise the server skeleton would need to know what kind of
client it is talking to: a CCM client or an EJB client. A larger issue
that this falls under is the reconciliation of the Java-to-IDL mapping
with the EJB-to-CCM mapping. If and when the larger issue is resolved,
this issue would largely disappear.

This also falls under the Java-to-IDL mismatch. Our choices seem to be: (1)
define the standard exceptions, e.g. Components::DuplicateKeyValue, as if
they had been mapped from Java under Java-to-IDL, (2) map the exceptions
from Java under rules different from those on Java-to-IDL; (3) perform a
translation. Choice (1) may be too intrusive but it could be rationalized
with a "integration with EJB" argument. Choices (2) and (3) are similar to
the above.

Sub-issue: PASSING A PRIMARY KEY PARAMETER

A number of methods defined by standard interfaces, such as remove
defined by EJBHome, include in their signature a primary key value and
define its type to be java.lang.Object, which under RMI-IIOP is mapped
to CORBA::Any. Since the primary key is actually an object passed by
value and thus mapped to an IDL value type, a run-time translation
must be performed from the value type to Any and viceversa whenever a
method that includes a primary key is called. FOR INTEROPERABILITY, it
is necessary that the location of this translation be fixed. Choices
for doing this include requiring the client stub to always do the
translation or requiring the server skeleton to take into account both
a value or an Any that could possibly be coming from any given
client. In additon, if a primary key is returned it may be more
advantageous for the client to perform this translation, since the
server skeleton may not know what form the client is expecting.

Here again the problem is that, under Java-to-IDL, java.lang.Object gets
mapped to ::java::lang::Object (not CORBA::Any actually, as per the actual
Java-to-IDL I am looking at) for methods like EJBHome.remove, whereas the
key is expected to be passed as a value type. So the choices seem to be:
(1) use rules other than those in Java-to-IDL for the mapping or (2)
perform a translation.

Require that client or server stubs of home and remote interfaces for both
CORBA Component views of EJBs as well as EJB views of CORBA Components
include the necessary code to perform the translations outlined in the summary.

3. Why isn't the operation <string get_implementation(in string iuuid)>
   defined in the interface ComponentInstallation while being used in
   ptc/99-10-04 p.69-329 item 9? (Where Installation should be
   replaced by ComponentInstallation don't you think?) Moreover, this
   operation is required for an Assembly to find the location of a
   component implementation in order to load it in a container.

The section 69.9 of the ptc/99-10-04 document does not define the signature of
the required get_implementation operation. Moreover this section refers to the
Installation interface instead of the ComponentInstallation interface.
The section 69.9 of the ptc/99-10-04 document must be replaced by the content
of the ccm/2001-10-03 document defining the signature of the
get_implementation operation and replacing all occurrences of the Installation
interface by the ComponentInstallation interface.

4. Why does not CCMHome include the operation create_component() ? I
   understand that a component created by a home with keys should not
   offer this interface, however according to the exemple in the spec
   Container operation install_home() returns a CCMHome, thus how
   could a component be created in this context? Does it imply that
   you know if the home is keyless or not, thus narrowing it before
   use? Don't you find strange to have the remove operation but not a
   default create in the CCMHome interface?

Clients could invoke the remove_component operation of the CCMHome
interface without requiring to know if the home has or has not an associate
primary key.
In order to create a component from a CCMHome instance, the caller must know
if the home has or has not a primary key. Moreover for keyed homes, the caller
must know what the home’s primary key type is, in order to create a primary key
value. This knowledge is obtained statically if the caller knows explicitly the
concrete home interface, or dynamically via the Interface Repository for instance.
If the home has no primary key, the caller could invoke the
Components::KeylessCCM Home::create_component operation to create a
component. If the home has a primary key, the caller should create a primary key
value according to the home’s primary key type, and should invoke the create
operation of the equivalent implicit interface of the called home. A dynamic caller
could invoke this latter operation via the DII.
Adding a generic create_component operation for keyed homes could only
resolve a part of the problem for dynamic clients: They always need to obtain
dynamically the primary key type in order to create a primary key value. As these
two knowledge could already be obtained simultaneously by introspecting the
associate CORBA::ComponentIR::HomeDef object, this issue should be closed
with no change.

5. Even if it is _only_ an example, p.615-85 ToonTownImpl implements
   ExecutorSegmentBase, shouldn't it be HomeExecutorBase?

In ptc/99-10-04 chapter 615 example 1, ToonTownImpl is the skeleton executor
implementation class for the home ToonTown. Then this class must implement
the HomeExecutorBase interface instead of the ExecutorSegmentBase interface.

6. In example p.615-86, shouldn't myToonImpl extends ToonSessionImpl
   (presented in the previous pages) instead of ToonImpl (which is not
   defined)? The same classname is used in pages 96-98, but it seems
   correct in this case. 

In ptc/99-10-04 chapter 615 example 1, myToonImpl is the user-provided
executor implementation class for the component executor ToonSessionImpl.
Then this class must inherit from the generated ToonSessionImpl class instead
of the non defined ToonImpl class.

7. Where is HomeExecutorBase interface defined? I only saw it used in 
   the packaging and deployment model. If it is a standard interface
   which is returned (how could it be non standard), shouldn't it be
   defined somewhere? (Same remark for ExecutorSegmentBase
   interfaces. It may be defined in the last Components.idl, but I did  
   not find one more recent than orbos/99-08-13.)

The interface HomeExecutorBase is defined in the Language Mapping Chapter.
See the resolution for issue 4574.

When a component type is implemented, it inherits a specialized
interface for callback functions, for example SessionComponent. In
this context, why should home implementations be unspecialized? Using
a specific home type, deployment could be improved when performed in a 
multi-actor context. As the cooperation between containers and homes
is unspecified, using multi-actors components seems unreachable. One
particular aspect is how the container <Context> interface si provided 
to the component instance. Using a well defined specialized home
interface would solve this problem easily. Thus, avoiding the use of 
wrappers for example which are another solution, but far more complex.
Such an interface should be defined for each component type category. 

As an example the following interface could be a basis for session
component homes. (there must be other operations to add here, but I
have not foudn them yet.)

interface SessionCCMHome : CCMHome { // or CCMHomeKeyless

    void set_session_context ( in SessionContext sc ) ;

};

A home has no use for a SessionContext reference. It is the container’s
responsibility to set the context value on component executor segments that
implement the SessionComponent interface. Adding a HomeContext interface
that provides useful information to a home (e.g. the home’s reference) is out of
the scope of this issue.

Looking a the <Assembly> interface, a question arises. When providing
the assembly descriptor location, a logic description of the
application to deploy is provided. But, how are set the pysical hosts
to be used for the deployemnt of the logic configuration? No hooks is
provided to the deployment tool (as there are no interfaces for the
tool) in order to provide these information, and no operation is
available on the assembly interface to do so. Is there an extension of 
the <Assembly> interface in order to contain this information?
Otherwise, how could the application be deployed?

Thinking about what should be provided, it is necessary to assign a
logical name contained in the assembly descriptor to a physical host
name. Maybe an extension to the assembly descriptor filled at
deployment time is the solution? The second possible choice crossing
my mind is an IDL structure (in fact sequence of structure) that could 
be provided to the assembly object.

In the Component Assembly Descriptor XML DTD, the destination element
should be used to fix the physical placement of homeplacement, executable
placement, hostcollocation, or processcollocation elements (see
section 69.7.2.18 page 69-309). To deploy a component assembly, a deployment
tool must provide to an Assembly object a copy of the logical assembly
descriptor where all destination elements are set with the expected physical
placement (see the note in ptc/99-10-04 section 69.7.2.1 page 69-303).

Dealing with the following IDL3 definition, a problem arises when
generating the IDL2 definitions (complete IDL2 mapping is enclosed at
the end of this mail).

    module example {
      valuetype AnEvent : Components::EventBase {
        public string value;
      };

      component Producer {
        publishes AnEvent output;
      };
    
      component Consumer {
        consumes AnEvent input;
      };
    };

According to the chapter 5 of the CCM specification, the publishes
definition of the Producer component is mapped to the following
definition (excerpt).

    interface Producer : Components::CCMObject {

      Components::Cookie 
      subscribe_output(in ::example::ProducerEventConsumers::AnEventConsumer consumer)
        raises (Components::ExceededConnectionLimit);

    };	

In the mean time, the consumes definition of the Consumer component is 
mapped to the following definition.

    interface Consumer : Components::CCMObject {

      ::example::ConsumerEventConsumers::AnEventConsumer 
      get_consumer_input();

    };

We can see that two versions of the "AnEventConsumer" interface have
been defined in two distincts modules. Thus the following Java
lines are not correct:


    example.Producer p = ...;
    example.Consumer c = ...;

    p.subscribe_output(c.get_consumer_input());

The Java compiler will refuse to compile the last one, producing an
error like "BadTypeCoerce". However, in the IDL3 definitions, both
components have been defined in order to be used together. (sic!)

Thus, we think that the mapping for a Consumer should not be based on
the component definitions, but on the event definition itself. It
would then avoid multiple (incompatible) definitions of the consumers.
This mapping could be defined in two distinct ways.

Add the new eventtype keyword in OMG IDL to define event types.
. Add the CORBA::ComponentIR::EventDef interface to reflect eventtype
definitions into the Interface Repository.
. Add the new EventDef metatype in the OMG IDL metamodel. This metatype
only inherits from the ValueDef metatype.
. Define component client view mapping rules to translate IDL3 eventtype
definitions to IDL2 valuetype definitions.
. Change component client view mapping rules for event port definitions to
IDL2 event consumer interfaces. The new mapping rules are event type
oriented instead of event port oriented.

In chapter 69.9.1.2 Deployment Scenario on page 329 of ptc/99-10-04.pdf the
operation get_implementation() is refered as if it belongs to the
ComponentInstallation interface (called only "Installation"), but the
specification of that interface lacks it.

What about <i>valuetype factories</i>?

<p>In the context of a component dealing with events, the aspect of 
<i>valuetype</i> factories has not been really mentionned in the spec, 
especially in the deploiement process. 
If I am right, dealing with <i>valuetypes</i> in a program means to 
instantiate and to register a factory for this <i>valuetype</i> to the 
ORB. In the context of the CCM, a component and its home is installed
into a generic container which may not know the <i>valuetype</i>. 
Thus, the <i>valuetype factory</i> may have to be installed at
deployment time. </p>
<p> According
to the similarity in the <i>home</i> and <i>valuetype factory</i>
concepts, it may be a good solution to add an entry in the CORBA
Component Descriptor OSD file to define the <i>valuetype factory</i>
(which would have to be included in the component package) required by
the component as well as to define a standard name scheme for their
entry points. Here is an draft example of what it could look
like. Relationships / dependencies between components and <i>valuetype 
factories</i> also have to be introduced.</p>  

<!--
<softpkg>
  ...
  <implementation id="...">
    ... all the environment stuff ...
    <descriptor type="Event Factory">
      <fileinarchive>...</fileinarchive>
    </descriptor>
    <code type="DLL">
      <fileinarchive name="bank.dll" />
      <entrypoint>createEventFactory</entrypoint>
    </code>
  </implementation>
  ...
</softpkg>
-->

<p><tt>&lt;softpkg>
<br>&nbsp; ...
<br>&nbsp; &lt;implementation id="...">
<br>&nbsp;&nbsp;&nbsp; ... all the environment stuff ...
<br>&nbsp;&nbsp;&nbsp; &lt;descriptor type="Event Factory">
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;fileinarchive>...&lt;/fileinarchive>
<br>&nbsp;&nbsp;&nbsp; &lt;/descriptor>
<br>&nbsp;&nbsp;&nbsp; &lt;code type="DLL">
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;fileinarchive name="bank.dll" />
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;entrypoint>createEventFactory&lt;/entrypoint>
<br>&nbsp;&nbsp;&nbsp; &lt;/code>
<br>&nbsp; &lt;/implementation>
<br>&nbsp; ...
<br>&lt;/softpkg></tt></p>

<p>The second solution could be to include the code for <i>valuetype
factory</i> creation in the <i>home</i> implementation, which mean
less specification: "The home has to install any valuetype factory
required by the component." would be enough. However, this second
approach may not be as much portable as the first one (as long as a 
<i>home</i> may be portable between containers, which IMHO should be
possible).</p> 

There are two problems involving valuetype factories. The first is in connection
with events as identified by the author in that there is no straightforward way to
register valuetype factories for events in a generic container. The second
problem is similar to the first in that there is no straightforward way to register
primary key valuetype factories for entity component homes nor is there a
mechanism to specify the state for a primary key that is required to create an
entity component. The solution to the first problem (and part of the solution for
the second problem) is to add a valuetypefactory ELEMENT in the software
package DTD and modify the description of the dependency ELEMENT in the
description of the software package descriptor to explicitly include handling of
valuetype factories. The solution to the second problem requires the addition of a
valuetype ELEMENT in the properties DTD so that the state for the primary key
of an entity component can be specified and identified.

The definition for "choices"  is as follow in the properties.dtd file:

<!ELEMENT choice ( #PCDATA ) >
<!ELEMENT choices ( choice+ )

knowing that the PCDATA for choice is supposed to hold one possible value
for the "simple" if I am right

I believe this is missing a bit of descriptive power. In case you want to
specify a range of 100 values you will have to give the 100 different values
each in its own "choice" element. It is very verbose !!!

We could add a range ELEMENT to the DTD as follow:

<!ELEMENT range (value, value)>

We could then change the choices ELEMENT as follow:

<!ELEMENT choices ( range | choice )+>

Any thought.

The choices ELEMENT in the properties DTD is restrictive and may result in
verbose properties descriptors and ultimately affect efficiency and performance.
Therefore, a range ELEMENT should be added to the properties DTD to allow a
choice between a single simple property value or a range of simple property
values.

I have a question about the property.dtd file provided with the CCM spec.

in this file "simple" is described as follow:

<!ELEMENT simple
( description?
, value
, choices?
, defaultvalue?
) >

This seems to indicate that a "simple" element has to have a value in the
file. Therefore it is not clear how usefull is the optional "defaultvalue"
field. It also means that if the component or assembly provider wants to
provide the CPF files with the CCD and CAD files it has to put values into
them instead of just setting the default value. Obviously the best thing to
do would be to repeat the default value into the value but it seems strange
to me. The point is that if there is a default value provided the value
doesn't seem to be mandatory.

Also, in a way similar to the CAD file, whe