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 2973: implementing import for C++
Issue 3060: Components Issues - Chapter 61 ptc/99-10-04
Issue 3061: Components Issues - Chapter 62 ptc/99-10-04
Issue 3062: Components Issues - Chapter 69 ptc/99-10-04
Issue 3063: Components Issues - Interface Repository ptc/99-10-03
Issue 3064: CCM Issue: Basic Level doesn't mention homes
Issue 3065: CCM Issue: CIDL Syntax doesn't allow for modules
Issue 3066: CCM Issue: Is a home needed?
Issue 3099: Should Components::Enumeration be an IDL interface or an IDL abstract value
Issue 3182: CCM Issue: How are standard EJB exceptions mapped into the CCM View
Issue 3183: CCM Issue: Is CCMObject::remove intended to be available to the CCM client?
Issue 3187: Do EJB-mapped attributes go to the ComponentDefault interface?
Issue 3189: What's the return type of CCM mappings of EJB finder and creator methods?
Issue 3190: How is CCMHome::get_home_def mapped to EJB operations?
Issue 3191: Is the ccm_home method shown in Table 8-1 a typo?
Issue 3197: Use of undefined "id" attribute
Issue 3198: Purpose of "name" element
Issue 3199: atribute not part of definition
Issue 3207: CORBA IR METAMODEL
Issue 3208: PACKAGING AND DEPLOYMENT METAMODEL
Issue 3212: 1. Should a session component have a way to save and restore its private st
Issue 3213: Implementation of get_component
Issue 3214: Registering homes outside of the container
Issue 3215: Federation of HomeFinders?
Issue 3216: New IDL keywords
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 3418: USING Components::Enumeration
Issue 3419: Bridge Interoperability of the Java mapping with the EJB-to-CCM mapping
Issue 3645: Use of the type ComponentHome
Issue 3646: Document OMG ptc/99-10-04 p.615-87
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 3652: CCM specification terms
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 3873: Implementation of extended CCM features
Issue 3925: range description in CPF files.
Issue 3926: simple ELEMENT definition
Issue 3927: Attribute exception 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 3940: INS name ? where do we get them from ?
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 4575: Issue for components: No meta model for CIDL ?
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 5508: 69.8.2.8 The simple Element, page 69-538
Issue 5509: 69.8.2.7 The range Element, pages 69-537/538
Issue 5510: 69.8.2.3 The choices Element, page 69-537
Issue 5511: 69.8.2.9 The sequence Element
Issue 5512: Test Property - add a test property definition to the properties DTD
Issue 5513: Add the capability to define a component artifact property
Issue 5514: 69.3 Software Package Descriptor
Issue 5515: 69.3.2.15 The implementation Element, pages 69-478/479
Issue 5516: 69.8.2.7 The code Element, pages 69-474
Issue 5517: 69.3.2.15 The implementation Element, pages 69-478/479
Issue 5518: 69.3.2.25 The propertyfile Element, page 69-482
Issue 5519: 69.3.2.14 The idl Element, page 69-478
Issue 5520: Descriptor
Issue 5521: 69.3.2.2 The author Element, page 69-474
Issue 5522: Component Artifact Dependency
Issue 5523: Device Artifact Dependency
Issue 5524: Uses Relationships
Issue 5576: 69.3 AssemblyFactory Interface
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 5589: Description for the impltype Element?
Issue 5590: Checking XML DTD elements related to the trader service
Issue 5591: Using Configurator on CCMHome or any CORBA objects?
Issue 5594: [CCM] Interface Repository Metamodel
Issue 5639: A new exception specification is needed for CCM2Context::req_passivate()
Issue 5683: Derived component supported interface restriction
Issue 5684: Issue on the description of the consumesidentifier element
Issue 5688: Derived component supported interface restriction (formal/2002-06-65)
Issue 5769: HomeConfigurator should not extend CCMHome
Issue 5852: Generic port connections
Issue 5858: CCM IDL style inconsistency
Issue 5870: multiple lifetime policies declaration issue
Issue 5871: 3.2.7 Compositions with Managed Storage
Issue 5898: CCM spec: insufficient examples of component attributes
Issue 5900: Section 6.4.5.52 (page 6-38)
Issue 5902: Section 6.4.5.10 (page 6-26)
Issue 5903: Section 6.4.5.26 and Section 6.4.5.30 should be moved to section 6.3
Issue 5906: insufficient examples of component attributes
Issue 5909: Session2Context interface
Issue 5910: issue on component supporting abstract interfaces
Issue 5918: CCM Spec: attributes are listed in the ports section?
Issue 5936: context interface for home implementation
Issue 5937: 'local executor mapping'
Issue 5943: page 1-20 second bullet of the description of the disconnect operation
Issue 5944: page 1-20 the description of the get_connection operation
Issue 5945: page 1-20 and page 1-21 - editorial
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.

I'm concerned that for C++, implementing "import" as currently specified in
the Components spec will be extremely difficult.

Imagine how you might implement this: your IDL compiler generates a C++
header file for all imported name scopes and creates #include directives
for these files in the C++ code generated for the main IDL file. The main
problem is that importable name scopes are modules, interfaces, valuetypes,
structures, unions, and exceptions. To import an exception, for example,
the import mechanism would have to keep a dependency graph for that
exception type and make sure that all dependencies are generated into the
header file so the C++ compilation won't fail. This seems way too complex,
and I don't see the value of being able to import individual structs and such.

In Java the import feature is nothing more than a convenience (it allows types from other packages to be referred to using simple names, rather than fully scoped names); it is very similar to 'using namespace' in C++. The CCM import is indeed the same kind of beast: a convenience to avoid the use of fully scoped names when referencing types from other modules. 

A potential issue with the import specification in the Components specification is that it suggests that a CORBA3-compliant ORB should provide an interface-repository based IDL compiler, e.g.: (from ptc/99-10-03 p 3-19)) 

The definition of import obviates the need to define the meaning of IDL constructs in terms of "file scopes". 
[...] 
A specification that imports name scopes must be interpreted in the context of a well-defined set of IDL specifications whose union constitutes the space from within which name scopes are  imported. By "a well-defined set of IDL specifications", we mean  any identifiable representation of IDL specifications, such as an interface repository. The specific representation from which name scopes are imported is not specified, nor is the means by which importing is  implemented, nor is the means by which a particular set of IDL specifications (such as an interface repository) is associated with the context in which the importing specification is to be interpreted. 

Generating usable C++ code with such an IR-based IDL compiler would be a real challenge. But since CCM import does not specify that a compliant ORB implementation needs to provide such a tool, this is not an issue. 

A minor error in the CCM import spec is that import can refer to constructs that do not create scopes (struct, union and exception). This resolution fixes this bug. 

Now, regarding language mappings, the CCM-IDL import does not need to be mapped to anything (remember, it's just a convenience). 
For example if we have: 

module A 
{ 
   interface X {}; 
}; 

import A; 

interface B 
{ 
    void op(in X p); 
}; 

The C++ mapping for operation op could be 

virtual void op(A::X_ptr p); 

Another possibility in C++ is to map import <module_name> to using namespace <module_name>. And in Java, import <module_name> can be mapped to import <module_name>.*. Each language-mapping RTF will have to decide. 

	The following errors in the component model chapter 61 need to be fixed as
follows to align the IDL in the text with the final IDL published in
Appendix A (orbos/99-08-08).
	1. In IDL on page 46, section 61.6.3 add a “;” after 		expected_event_type.
	2. In IDL on page 43, section 61.5.3 replace 
		ConnectionList get_connections (in FeatureName name) 
				raises (InvalidName);
		with
		ConnectedDescriptions get_connections (in FeatureName name) 
				raises (InvalidName);
	3. In IDL on page 68, section 61.10.1.2 replace				
		valuetype ConfigValue {
			FeatureName name;
			any value;
		};
with
		valuetype ConfigValue {
			public FeatureName name;
			public any value;
		};

	The following errors in the container model chapter 62 need to be fixed as
follows to align the IDL in the text with the final IDL published in
Appendix A (orbos/99-08-08).

	1. In IDL on page 141 section 62.3.2.3 replace
		local interface Transaction {
		with
		local interface UserTransaction {
	2. In IDL on page 144, 145, 147, 155, and 162 add “;” after reason
	3. In IDL on page 155, section 62.4.2.1 delete “,” after WRONG_CONTAINER
	4. In IDL on page 150, section 62.4.1.1 replace
		local interface CCM2Context : CCMContext {
		with
		local interface CCM2Context : Basic::CCMContext {
	5. In IDL on page 155 section 62.4.2.1 replace
		local interface Session2Context : SessionContext, CCM2Context {
		with
		local interface Session2Context 
				: Basic::SessionContext, CCM2Context {
	6. In IDL on page 162, section 62.4.3.7 replace
		local interface Entity2Context : EntityContext, CCM2Context {
		with
		local interface Entity2Context 
				: Basic::EntityContext, CCM2Context 
	7. In IDL on page 150, section 62.4.1.1 change
		Events::Event get_event();
		to
		Notification::Event get_event();
	8. On page 152, section 62.4.1.4, change Components::Events to
Components::Notification

	The following errors in the deployment chapter 69 need to be fixed as
follows to align the IDL in the text with the final IDL published in
Appendix A (orbos/99-08-08).

	1. In IDL on page 330, section 69.9.2 replace two occurences of
		raises InvalidLocation;
		with
		raises (InvalidLocation);
		and one occurence of
		raises UnknownImplId;
		with
		raises (UnknownImplId);
	2. In IDL on page 331, section 69.9.3 replace one occurence of
		raises InvalidLocation;
		with
		raises (InvalidLocation);
		and two occurences of 
		raises InvalidAssembly;
		with
		raises (InvalidAssembly);
	3. In section 69.9.1.2 on pages 328 and 329, items 2 and 9 change
Installation to ComponentInstallation

The following errors in the interface repository chapter 10 need to be fixed.

	1. In IDL for interface HomeDef on Page 52 and Page 88: 
	   Remove the line: readonly attribute boolean is_basic; 
	2. In IDL for struct HomeDescription on Page 52 and Page 88: 
    	   Remove the line:  boolean is_basic; 
	3. In section 10.5.38.1 on page 53: Remove the paragraph that begins with: 
          "The is_basic attribute is TRUE if this is a basic home......."

 There is nothing in the FTF documents about leveling with
respect to homes. Basic CCM does not allow components to inherit from
other components. Why is there no similar restriction for homes?

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.

Summary: The CCM FTF IDL chapter does not state whether a home must be
declared for a component. A home must have a component, but must a
component have a home?

Summary: Section 8.2.1.2 of the spec defines Components::Enumeration as an
IDL interface, with the implication
that it is intended as a remote type.

Issue: It has been noted that java.util.Enumeration is usually implemented
as a java.io.Serializable and that making
Components::Enumeration an IDL interface would prevent this from happening
for collections of primary keys returned
from EJB Homes that are mapped to CCM Homes.

Proposal: Define Components::Enumeration as an IDL abstract valuetype.

It has been noted that java.util.Enumeration is usually implemented as a java.io.Serializable and that making Components::Enumeration an IDL interface would prevent this from happening for collections of primary keys returned from EJB Homes that are mapped to CCM Homes.

Chapter 8 of the spec specifies mappings between EJB operations and their
equivalents in the CCM view, but it leaves the mappings of standard EJB
exceptions unclear.


Issue:
Create methods on an EJB home interface all throw the standard
javax.ejb.CreateException; finder methods on the EJB home interface all
throw the javax.ejb.FinderException; and remove methods on both home and
remote interfaces all throw the javax.ejb.RemoveException.  In a few cases
chapter 8 gives an implied mapping: for example, the FinderException on the
findByPrimaryKey method seems to map to either the
Components.UnknownKeyValue exception or to the Components.InvalidKey
exception on the equivalent find_by_primary_key CCM method.  Even in these
cases the names are sometimes inappropriate.  In the majority of cases,
however, there is simply no CCM equivalent to the EJB exception, and bridge
implementors are left to wonder whether they should attempt a non-standard
mapping.


Proposal:
     (a) Add the new CCM standard exceptions Components.CreationFailure,
Components.NotFound, and Components.RemovalFailure
     (b) Add Components.CreationFailure to the raises clause of all create
methods on implicit and explicit home interfaces
     (c) Add Components.NotFound to the raises clause of
find_by_primary_key on implicit home interfaces, and to the raises clause
of all finder methods on explicit home interfaces
     (d) Add Components.RemovalFailure to the raises clause on the remove
operation on implicit home interfaces, to the CCMObject.remove operation,
and to the CCMHome.remove_component operation
     (e) Specify in chapter 8 that the EJB Finder exception is always
mapped to Components.CreationFailure; that the EJB CreateException is
always mapped to Components.CreationFailure; and that the EJB
RemoveException is always mapped to Components.RemovalFailure.
     (f) Make explicit in chapter 8 the already implied mapping bewteen the
EJB DuplicateKeyException and the Components.DuplicateKeyValue exception

 Create methods on an EJB home interface all throw the standard javax.ejb.CreateException; finder methods on the EJB home interface all throw the javax.ejb.FinderException; and remove methods on both home and remote interfaces all throw the javax.ejb.RemoveException. In a few cases chapter 8 gives an implied mapping: for example, the FinderException on the findByPrimaryKey method seems to map to either the Components::UnknownKeyValue exception or to the Components::InvalidKey exception on the equivalent find_by_primary_key CCM method. Even in these cases the names are sometimes inappropriate. In the majority of cases, however, there is simply no CCM equivalent to the EJB exception, and bridge implementors are left to wonder whether they should attempt a non-standard mapping. 

Section 5.12.1 of the spec can be interpreted to mean that the
CCMObject::remove call is not intended for use by CCM clients; but this is
inconsistent with the EJB/CCM mapping given in chapter 8.


Issue:
The explanation given for the CCMObject::remove call in section 5.12.1 is:
     "This operation is called when a component is about to be destroyed.
The component
     can perform any cleanup processing required (e.g. releasing resources)
 prior to its
     destruction."
This explanation can be interpreted to mean that the call is a private call
 from a CCM container to one of its components; if it has this internal
purpose then it might not be
intended for use by CCM clients wanting delete the component.  However,
table 8-1 shows that the CCM view of an EJB maps this call to the
EJBObject.remove()
method. This implies that the method is intended for client use as the
EJBObject.remove() is.  If so, then it also makes more sense to implement
the
CCMHome::remove() method in terms of the EJBObject.remove() method, rather
than the current mapping which requires an EJB Handle.


Proposal: (a) Change the text for remove() in 5.12.1 to say: "This
operation is used to delete a component".
     (b) Change the mapping in table 8-1 for CCMHome::remove to use
EJBObject.remove

: The explanation given for the CCMObject::remove call in section 5.12.1 is: "This operation is called when a component is about to be destroyed. The component can perform any cleanup processing required (e.g. releasing resources) prior to its destruction." This explanation can be interpreted to mean that the call is a private call from a CCM container to one of its components; if it has this internal purpose then it might not be intended for use by CCM clients wanting delete the component. However, table 8-1 shows that the CCM view of an EJB maps this call to the EJBObject.remove() method. This implies that the method is intended for client use as the EJBObject.remove() is. 

When mapping EJB set/get methods to a CCM view, it is not clear whether the
resulting IDL attributes belong on the ComponentDefault interface or on the
component definition itself


Issue:
Set/get method pairs on the EJB remote interface map to IDL attributes, but
do these attributes end up in the XXXDefault interface or in the XXX
component definition?  Section 8.2.1.2 of the specification seems to imply
they belong in the XXXDefault interface, but section 5.3.2 says the
component definition for a basic CCM "shall only contain zero or more
attribute declarations", which suggests that attributes of a CORBA
Component belong in the component definition.   Also, the mapping in the
other direction (EJB view of a CCM), described in 8.3.1, suggests that CCM
attributes are always found in the component definition itself.  It appears
that both versions will work, but this point is worth clarifying.


Proposal:
Change 8.2.1.2 to say that all EJB set/get method pairs are mapped to IDL
attributes on the component definition itself.

Set/get method pairs on the EJB remote interface map to IDL attributes, but do these attributes end up in the XXXDefault interface or in the XXX component definition? Section 8.2.1.2 of the specification seems to imply they belong in the XXXDefault interface, but section 5.3.2 says the component definition for a basic CCM "shall only contain zero or more attribute declarations", which suggests that attributes of a CORBA Component belong in the component definition. Also, the mapping in the other direction (EJB view of a CCM), described in 8.3.1, suggests that CCM attributes are always found in the component definition itself. It appears that both versions will work, but this point is worth clarifying. 

Summary:

8.2.1.2 of the CCM specification says that EJB finder and creator methods
which return an RMI object reference are mapped to methods which return a
Components::CCMObject reference.  It is unclear whether the actual base
class CCMObject is intended or whether the specific component subclass
(e.g., Widget) is intended.   The specific subclass seems more sensible,
and is consistent with the equivalent IDL mappings shown in section 5.8.4.

Proposal:

Change 8.2.1.2 to make it clear that the specific subclass (e.g., Widget)
is the return type.

Chapter 8 omits to mention how the CCMHome::get_home_def call is mapped by
the bridge at runtime to an EJB operation.


Issue:
The very similar call CCMHome::get_component_def is shown as mapped to the
EJBHome.getEJBMetaData operation, but there is no mapping shown for
CCMHome::get_home_def.  It appears that get_home_def could be also be
implemented using the EJBHome.getEJBMetaData operation, and if necessary,
with the help of Java introspection.


Proposal:
Add a line in Table 8-1 to show CCMHome::get_home_def mapped at runtime to
EJBHome.getEJBMetaData.

The very similar call CCMHome::get_component_def is shown as mapped to the EJBHome.getEJBMetaData operation, but there is no mapping shown for CCMHome::get_home_def. It appears that get_home_def could be also be implemented using the EJBHome.getEJBMetaData operation, and if necessary, with the help of Java introspection. 

Table 8-1 shows a mapping for CCMObject::get_home.  It looks like it should
say CCMObject::get_ccm_home


Proposal:

Change "CCMObject::get_home" to "CCMObject::get_ccm_home" in Table 8-1.

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) The isBasic Attribute needs to be removed from HomeDef to synchronize
with the regular CORBA IR.

Resolution: Remove isBasic attribute from HomeDef in the metamodel and regenerate the XMI and IDL for the metamodel.  Theoretically the generated code can be hand-modified to remove artifacts generated from the isBasic attribute of HomeDef, but this is a dangerous practice and is not recommended. 

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.

1. Should a session component have a way to save and restore its private state? 
	Problem: The current component specification provides no way for the component programmer to explicitly save and restore its private state for session components.

Since basic components do not participate in creating references, there is no way for them to control saving and restoring of their state. Extended components already have the required operations. No change is required. 
Revised Text: No change. 

2. Implementation of get_component with separate ORB and component vendors 
	Problem: A design goal of the components specification was to permit the component container to be provided by a different vendor than the ORB vendor. When this is true, how does the implementation of get_component work?

Resolution: A CORBA 3.0 ORB must implement get_component even if it does not provide an implemention of CORBA components and therefore, a CCM implementation from any other vendor can rely on a get_component implementation being available. 

Problem: The current specification does not provide an interface for registering homes that can be used outside of the container. Should it?

Homes cannot be registered outside the container, since HomeFinder are not federated (see resolution of issue 3215). This means that the scope of a HomeFinder is a single CCM implemementation. Clients may use the Naming Service instead, which is federated. 

Problem: Can home finders be federated?

Problem: The new IDL keywords use mixed case, rather than the lower case style used by current keywords. Should the new keywords be changed to comply with the existing style?

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 use