The GIOP specification does not say anything at all about the rules for marshalling ValueBoxes.

I believe the expected format is to marshal ValueBoxes as if they were a normal Value with a single member, and that they follow the normal rules about indirections and chunking. The spec should clearly state this.

21.3.9.2 states:

"In the DSI model, since the parameters are first available when the user code calls arguments, receive_request is called from within arguments. It is possible that arguments is not called in the DSI model. The target may call set_exception before calling arguments. The ORB shall guarantee that receive_request is called once, either through arguments or through set_exception."

The problem here, is that the DSI servant has already been invoked at this point, and the DSI implementation will be unaware that the server interceptor may have cancelled the invocation via raising a system exception or ForwardRequest user exception. So the DSI implementation will carry on, creating all sorts of wonderful havoc as it continues to interact with the ServerRequest PO.

Any vendors want to comment on what their PI implementation does now?

Proposed fix:

First, we should define a new system exception minor code that the servant implementation can detect so that it can clean up and get out of the way as expeditiously as possible when raised by arguments or set_exception. Perhaps a minor code for OBJ_ADAPTER? Should there be two minor codes, to distinguish a system exception from ForwardRequest as the reason for cancelling the invocation?

Second, we need some more text either in chapter 8 or 21 that states that any calls by the DSI implementation to ServerRequest::set_result or ServerRequest::set_exception will be ignored (or perhaps reraise the exception defined in the previous paragraph) if ServerRequestInterceptor::receive_request raises an exception.

There is a small issue with the restriction of where a valuetype chunk can end. The spec says

"The data may be split into multiple chunks at arbitrary points except within primitive CDR types, arrays of primitive types, strings, and wstrings, or between the tag and offset of indirections. It is never necessary to end a chunk within one of these types as the length of these types is known before starting to marshal them so they can be added to the length of the currently open chunk."

However, in the case of array of wchar, the length is not known before starting to marshal, since each char (in GIOP 1.2 and 1.3) is marshalled as a (sort-of) sequence of octets. I think it should be legal to end a valuetype chunk in the middle of an array of char.

It is impossible to use the routing protocol to communicate with servers
that only support GIOP 1.0 or 1.1, because the information contained in
struct MessageBody does not contain enough information to determine the
alignment requirements of the contents of body member. The GIOP 1.0 &
1.1 RequestHeader struct contain an octet sequence for principle as the
last member, and specify no alignment requirements for the message
body. Thus, it is impossible for the final router to determine the
proper alignment for the message body when marshalling a GIOP Request
message for delivery to the target object.

The same problem applies to the Response message.

The spec doesn't make it clear what is a valid mix of policies and what
is invalid. For example, should it be legal to set a
RequestPriorityPolicy, MaxHopsPolicy or QueueOrderingPolicy value if the
RoutingPolicy is ROUTE_NONE?

Also, should setting both RequestEndTimePolicy and
RelativeRequestTimeoutPolicy be illegal? Or must the client/server pick
which ever one expires first?

I just noticed that the description of DynValue is totally silent on the
issue of derived valuetypes.

Here's an example to set things up:

// IDL

valuetype A

;

valuetype B

;

struct S

;

// C++

DynamicAny::DynFactory df = ...;
B *b = ...;
S my_s;
CORBA::Any my_any;

s.an_a = b;
my_any <<= s;

DynamicAny::DynAny_var da = df->create_dyn_any(my_any);
DynamicAny::DynStruct_var ds = DynamicAny::DynStruct::_narrow(da);

ds->seek(0);
da = ds->current_component();

DynamicAny::DynValue_var dv = DynamicAny::DynValue::_narrow(da);
CORBA::TypeCode_var tc = dv->type();

cout << tc->id() << endl;

-----------

Now some questions:

1. What is printed by the above C++ code? "IDL:A:1.0" or "IDL:B:1.0"?

2. If the typecode is for valuetype A, what happens to the members
defined in valuetype B? Seems they must be inaccessable yet still
recoverable if I convert the DynValue back to an any and extract the
value, because I can't truncate a B to an A.

3. If the typecode is for valuetype B, we now have the interesting case
where:

tc->equivalent(ds->type()->member_type(0))

is false. Is this going to confuse programmers or programs? I think it
will, since it means that if I try to insert dv into another DynStruct
via assign() or the like, it will fail, since the TypeCodes are no
longer equivalent.

4. Do the answers change if B is truncatable and the program can find
the TypeCode for B (perhaps via SendingContextRunTime)? How about if it
can't find the TypeCode?

Fifth bullet near the beginning of this section states:

Incarnations of a particular object may not overlap; that is, incarnate shall not be invoked with a particular ObjectId while, within the same POA, that ObjectId is in use as the ObjectId of an activated object or as the argument of a call to incarnate or etherealize that has not completed.

Unfortunately, I do not see anywhere where the exception to be thrown from activate_object_with_id() for this case is specified. According to this text, if incarnate() is executing for a particular ObjectId, any calls to activate_object_with_id() should be rejected by the POA. This came up in comp.object.corba, where someone posted a question as to why Orbix 2000 throws the ObjectAlreadyActive exception for this case.

[..] It is used to indicate the relative amount
of time for which a Request or its corresponding
Reply may be delivered. After this amount of
time, the Request is cancelled (if a response
has not yet been received from the target) or
the Reply is discarded (if the Request had
already been delivered and a Reply returned from
the target) [..]
---------------------------------------------------------
Question:

• What is the precise meaning of "Request is
  cancelled"?

Does it mean that client ORB just gives up or
does it mean that client tries, in kind of best
effort semantics, to cancel request on server?

If this cancellation fails, how will client user
be informed about this? By a minor code in
thrown Timeout exception?

Is it possible to clarify this?

The spec appears silent as to whether valuetypes are allowed to support local interfaces. Table 3-10, for example, says nothing at all about local interfaces.

There's a couple ways to look at this. First, valuetypes are not CORBA objects. Servants for local interfaces are direct CORBA object instances, i.e., the "local" declaration on an interface effectively removes the distinction between a CORBA object and its servant. If a valuetype were used as a servant for a local object, then the valuetype would itself also be a CORBA object. By this analysis, valuetypes should not be allowed to support local interfaces.

Another way to look at it is that the valuetype should just inherit the local interface's operations and attributes without having any subtype/subclass relationship with the base local interface. This would be a rather pointless approach to take, is there would be no possibility of using the valuetype polymorphically with respect to the base local interface.

Suggested changes to the AssemblyFactory interface.

AssemblyFactory Issues.

1. Ease of use Issue. After the create operation is performed, one is
force to call lookup to get the Assembly that just got just created. Why is
a cookie returned by the create operation instead of an Assembly? Is the
reason because of security? If the interface were more open this would
still allow a secure implementation to be implemented.
Suggested change is to return an Assembly instead of a Cookie. Change
destroy operation to take in an Assembly parameter instead of Cookie.
Change lookup operation to take in a name parameter. These changes
make it consistent with the other CCM interfaces, such as Container,
KeyLessCCMHome, ComponentServer, and ServerActivator.
2. Multiple users Issue. For multiple users, how does a client know what
assemblies are created. Add a get_assemblies operation that returns a list
of assemblies. These changes make it consistent with other CCM interfaces,
such as Container, ComponentServer, and ServerActivator.
3. User-friendly identifier for Assembly Instance issue. Add an input
name parameter that can be assigned to the Assembly instance that gets
created. Add a read only name or label attribute to the Assembly interface.

in the BaseIDL there is a class StructDef which has the Attribute members of
Type Field. How can I model a IDL struct with more than one entry?
I think there should be a aggregation from StructDef (1<>----->*) to the Field
class (Page 8-10 of the CCM Spec).

*) With EnumDef there is the same problem, I guess a assotiation from EnumDef to
string (1<>----->*) would solve it (Page 8-10 of the CCM Spec).

*) Also with ExceptionDif and its attribute members (Page 8-11 of the CCM Spec).

• document : formal/02-06-65
• chapter : 1.5.2.4

• text in question :

module Components
{
valuetype Cookie

;
};

• Issues :

1. Naming style used in this definition violates rules defined in
"OMG IDL Style Guide" (ab/98-06-03).

2. Naming style used in this definition is inconsistent with other parts
of the CCM IDL, for example:

module Components
{
valuetype PortDescription

;

valuetype FacetDescription : PortDescription

;
}

• suggested resolution : replace `cookieValue' with `cookie_value'

In section 4.2.5 of the CCM spec formal/02-06-65, it is said that "Servant lifetime policies may be defined for each segment within a component", but there is no way to do it. Lifetime policy is declared in the CCD descriptor of the component, as an attribute of the "servant" XML element, and is implicitly applied on all the segments of the component(when it is segmented) !

Suggested resolution: to leave the servant element as it is, expressing a DEFAULT lifetime policy, and to add the same servant element as an optional child of the segment element. This will specify the lifetime policy of the segment and override the defautl one. DTD has to be changed as follows :

<!ELEMENT segment
( segmentmember+
, containermanagedpersistence?
, extension*
>
<!ATTLIST segment
name CDATA #REQUIRED
segmenttag CDATA #REQUIRED >

becomes:

<!ELEMENT segment
( segmentmember+
, servant?
, containermanagedpersistence?
, extension*
>
<!ATTLIST segment
name CDATA #REQUIRED
segmenttag CDATA #REQUIRED >

In OMG document formal/02-06-65, in section "1.3.3 Component Body", there
is this text:

"Declarations for facets, receptacles, event sources, event sinks,
and attributes all map onto operations on the component's equivalent
interface. These declarations and their meanings are described in
detail below."

In the following sections, I see facets, receptacles, event sources,
and event sinks described, but I see no mention of attributes.
It would be usefult to have an example of attributes in an appropriate
place, as outlined by section 1.3.3.

In section "1.10 Configuration with Attributes", I see that configurators
are described, but I see no example of using attributes directly
to configure a component.

It would be very useful to include a small example to illustrate
how to configure a component directly by using attributes.

Diego Sevilla Ruiz <dsevilla@ditec.um.es> gave this
C++ example on the CCM mailing list ( http://moriarty.dif.um.es/mailman/listinfo/ccm ):

======================================================

component Whatever

;

home WhateverHome manages Whatever
{
};

// C++
WhateverHome_var weh = // obtain ref
Whatever_var we = weh->create();

we->cacheMaxKb(200);

we->configuration_complete();

======================================================

I don't suggest that this example be used verbatim,
but a similar example would be useful to have in the
CCM spec.

In section 1.1.2 of the CCM specification:

1.1.2 Ports
===========
..... The component model supports four basic kinds of ports:

• Facets
• Receptacles
• Event sources
• Event sinks
• Attributes

Well, that list includes five things, not four.

So, is an attribute considered a port or not?

The wording in this section needs to be clarified in the CCM
specification, because it is not clear if an attribute
is a port or not.

The following information is sent in order for the specification to
clearly state if components and local interfaces can support abstract
interfaces (the specification is confusing on this point).

CORBA 3.0.1 does not explicitely states if a component can support an
abstract interface, thus it can be considered that it is possible. If so
a big problem arises as local interfaces inheriting abstract ones is
confusing in the specification.

In addition, it is neither explicitely stated that provides and uses
declarations can or cannot be of types defined through abstract
interfaces. It does not seem to make sense for a port to be an abstract
type. Facets will never be used by value, and an operation cannot
(should not) return the reference of a facet or a valuetype (which would
be in favor of provides to be defined using abstract interfaces).

• • Problem

Consider the following definitions which are correct regarding
formal/02-12-06:

/* omg idl3 */

abstract interface I

;

interface C : Components::CCMObject, I { } ;

local interface CCM_C : I { } ;

According to formal/02-12-06, the last line may not be correct. Local
interfaces may not inherit abstract interfaces (section 10.5.28). (I use
may as it is confusing and can lead to various understanding of the
spec.)

• • Potential solutions:

1. State in the CORBA 3.0.1 that components cannot support abstract
interfaces. In favor: Could ne considered as a minor change. Against: a
component reference cannot be returned by an operation that can return
an object by value or by reference. This solution looks cleaner that the
second one from a software engineering point of view.

2. Clearly state that components and local interfaces can support
abstract interfaces. This use may be surprising from a software
engineering point of view, but may be important for some users. This
bring back the debate "quality vs powerfulness".

In any case, I think it should be clearly stated if local interfaces may
or may not inherit abstract ones.

Identifier (FPI).

These FPIs are required for the CAD, CSD, CCD and CPF DTDs.

Proposed resolution:

Adds the CCM DTDs on the OMG web site and adds the following text in the specification:

• section 6.3, before subsection 6.3.1 :

The CORBA Software Descriptor must refer to the DTD using the following statement: <!DOCTYPE softpkg PUBLIC "-//OMG//DTD CORBA Software Descriptor 3.0//EN" "http://www.omg.org/dtd/softpkg_3_0.dtd" />

• section 6.4, before subsection 6.4.1 :

The CORBA Component Descriptor must refer to the DTD using the following statement: <!DOCTYPE corbacomponent PUBLIC "-//OMG//DTD CORBA Component Descriptor 3.0//EN" "http://www.omg.org/dtd/corbacomponent_3_0.dtd" />

• section 6.4.4:

replace

<!DOCTYPE corbacomponent SYSTEM "corbacomponen.tdtd">

with

<!DOCTYPE corbacomponent PUBLIC "-//OMG//DTD CORBA Component Descriptor 3.0//EN" "http://www.omg.org/dtd/corbacomponent_3_0.dtd" />

• section 6.7, before subsection 6.7.1 :

The Component Assembly Descriptor must refer to the DTD using the following statement: <!DOCTYPE componentassembly PUBLIC "-//OMG//DTD Component Assembly Descriptor 3.0//EN" "http://www.omg.org/dtd/componentassembly_3_0.dtd" />

• section 6.7.1:

replace

<!DOCTYPE componentassembly SYSTEM "componentassembly.dtd">

with

<!DOCTYPE componentassembly PUBLIC "-//OMG//DTD Component Assembly Descriptor 3.0//EN" "http://www.omg.org/dtd/componentassembly_3_0.dtd" />

• section 6.8, before subsection 6.8.1 :

The Component Property File must refer to the DTD using the following statement: <!DOCTYPE properties PUBLIC "-//OMG//DTD Component Property File 3.0//EN" "http://www.omg.org/dtd/properties_3_0.dtd" />

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

The CCMObject interface contains numerous operations for generic
connection management (in addition to the type-specific operations
defined by equivalent IDL for a component).

However, there's a separate set of "connect" and "disconnect"
operations for each kind of port, i.e., receptacles, emitters and
publishers. This is inconvenient for generic software that treats
ports generically, such as the deployment infrastructure in an
implementation of the Deployment and Configuration specification.

The set of operations might even get larger in the future, when
Streams for CCM becomes available.

I thus propose to add generic "connect_feature" and "disconnect_
feature" operations that is able to interconnect compatible ports
regardless of the type of port.

Proposed resolution:

In section 1.11.1, "CCMObject Interface," add the following two
operations to the CCMObject interface:

module Components {
interface CCMObject : Navigation, Receptacles, Events

;
};

Add the following explanation to the same section:

connect_feature

The connect_feature operation connects the object reference
specified by the connection parameter to the component feature
specified by the name parameter. The feature must be either a
receptacle, emitter or publisher port.

If the feature identified by the name parameter is a receptacle
port, the connect_feature operation acts equivalent to calling
the connect operation on the Receptacles interface.

If the feature identified by the name parameter is an emitter
port, the connect_feature operation acts equivalent to calling
the connect_consumer operation on the Events interface. A nil
"cookie" value is returned.

If the feature identified by the name parameter is a publisher
port, the connect_feature operation acts equivalent to calling
the subscribe operation on the Events interface.

If the feature identified by the name parameter is neither
receptacle, emitter or publisher port, or if the component does
not have any feature by that name, the InvalidName exception is
raised.

disconnect_feature

The disconnect_feature operation dissolves the connection
identified by the ck cookie to the component feature specified
by the name parameter.

If the feature identified by the name parameter is a receptacle
port, the disconnect_feature operation acts equivalent to calling
the disconnect operation on the Receptacles interface.

If the feature identified by the name parameter is an emitter
port, the disconnect_feature operation raises the InvalidConnection
exception if a non-nil cookie is passed as the ck parameter;
otherwise, it acts equivalent to calling the disconnect_consumer
operation on the Events interface.

If the feature identified by the name parameter is a publisher
port, the disconnect_feature operation acts equivalent to calling
the unsubscribe operation on the Events interface.

If the feature identified by the name parameter is neither
receptacle, emitter or publisher port, or if the component does
not have any feature by that name, the InvalidName exception is
raised.

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

I'd like to report an issue that exists in both the CORBA Component Model Specification (formal/06-04-01) and also the Lightweight CORBA Component Model specification (ptc/04-06-10) please.

In section "6.11 Component Inheritance" of formal/06-04-01 there is the statement : "A derived component type may not directly support an interface."

This same statement is made in "1.11 Component Inheritance" of ptc/04-06-10 and in "3.17.2.3 Component Inheritance" of the CORBA 3.0.3 spec (04-03-02).

But, in both "6.3.2.4 Inheritance and supported interfaces" of formal/06-04-01 and "1.3.2.4 Inheritance and supported interfaces" of ptc/04-06-10 there is the following:

"For a component declaration with the following form:

component <component_name> : <base_name>
supports <interface_name_1>, <interface_name_2>

;"

The above example is giving equivalent IDL for a declaration that the preceding statements regarding component inheritance say is not permitted. It should presumably be removed.

The CCMHome interface does not provide a mechanism for locating the container that created a home. The lack of a method to get a home's container is inconsistent with the rest of the CCM model. Furthermore, this method would be very useful as it would provide a means to navigate from a component to its ServerActivator, which is currently not possible.

Resolution:

Replace the following text in formal/02-06-05 on page 1-41

interface CCMHome

;

with

interface CCMHome

;

and add the operation description

get_container

The get_container operation returns a reference to the Container object that created this CCMHome

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

The NVList has a count, which is defined as long, it would be better to make this an unsigned long. This has impact on ORB::create_list, change the type of argumetn count to unsigned long. Also update NVList::get_count to have an unsigned long argument.

In the Interceptor interface there is a destroy method which can throw a system exception just like all other corba calls. What is the behaviour when the orb shutdown is done and an Interceptor::destroy() call throws an exception? Should the ORB ignore this exception and continue the shutdown or should it return the exception to the caller. I would except ignore the exception and continue but the spec doesn't describe the behaviour.

The tags for unreliable multicast are missing. // The following are defined in 03-01-11 const ProfileId TAG_UIPMC = 3; const ComponentId TAG_GROUP = 39; const ComponentId TAG_GROUP_IIOP = 40;

The minor code for add_reply_service_context is not correct. The spec says: Indicates the behavior of this operation when a service context already exists with the given ID. If false, then BAD_INV_ORDER with a standard minor code of 11 is raised. If true, then the existing service context is replaced by the new one. The minor code should be 15.

This corba spec describes POAManagerFactory. I have been searching on the web and it seems for example Orbacus has the possibility to do a resolve_initial_references ("POAManager"). This seems not possible with the latest corba spec. This seems an usefull extension. The only option there is now is to get the RootPOA, get from there the POAManagerFactory and use that again.

For activate_object_with_id it is described that when SYSTEM_ID has been set and the object id was not generated by this system or tis POA we throw a BAD_PARAM, but the minor code is not described. Shouldn't this have an unique minor code?

The following methods are not described in this chapter: Object make_object (in string repository_id, in ObjectId id); IOP::TaggedProfileSeq make_profiles (in string repository_id, in ObjectId id); These are mentioned in 21.10.3

In the C++ example code of 22.11.3 Messaging::ExceptionHolder_ptr is used, for valuetypes there is no _ptr, the could should read Messaging::ExceptionHolder *

There are some issues with the definition of ExceptionHolder. In 22.16 it is as below, see the raise_exception_with_list, this seems to have two arguments here, in 22.7 there is just one argument. The same problem also appears in the draft 3.1 spec. Also, there is no CORBA::ExceptionList defined in the spec at all, there is Dynamic::ExceptionList but no CORBA::ExceptionList. valuetype ExceptionHolder { void raise_exception() raises (UserExceptionBase); void raise_exception_with_list( in CORBA::ExceptionList exc_list) in Dynamic::ExceptionList exc_list) raises (UserExceptionBase); private boolean is_system_exception; private boolean byte_order;

The CORBA spec describes the following about the wait_for_completion parameter of the POA::destroy call: The wait_for_completion parameter is handled as follows: • If wait_for_completion is TRUE and the current thread is not in an invocation context dispatched from some POA belonging to the same ORB as this POA, the destroy operation returns only after all active requests have completed and all invocations of etherealize have completed. • If wait_for_completion is TRUE and the current thread is in an invocation context dispatched from some POA belonging to the same ORB as this POA, the BAD_INV_ORDER system exception with standard minor code 3 is raised and POA destruction does not occur. We have a use case where we have an ORB with two POA's, A1 and B1, each POA again has a child A2 and B2. In case we get a request for a servant of A2 to destroy POA B2 and we specify TRUE for wait_for_completion then we get an exception back, but this doesn't seem locally. We understand that when we want to destroy A1 when handling a request using a servant of A2 that we get an exception at that moment. We propose the change the description as following: The wait_for_completion parameter is handled as follows: • If wait_for_completion is TRUE and the current thread is not in an invocation context dispatched from some POA that is a child of this POA or from this POA itself, the destroy operation returns only after all active requests have completed and all invocations of etherealize have completed. • If wait_for_completion is TRUE and the current thread is in an invocation context dispatched from some POA that is a child of this POA or from the POA itself, the BAD_INV_ORDER system exception with standard minor code 3 is raised and POA destruction does not occur.

In case get_slot is called from withing an ORB itializer chapter 21.4.3.1 says a BAD_INV_ORDER with minor code 10 is thrown, this should be 14 as mentioned also in 21.7.2.11

The draft document says the following in 21.9.1. The description about the type of exceptions sounds very vague. Shouldn't the spec be more detailed, which type of exceptions should be ignored specifically? Any exceptional return from the invocation of any operation of the ORBInitializer interface other than those resulting from the failure to instantiate a portable interceptor object shall result in the abandonment of the ORB initialization and destruction of the ORB. Any ORBInitializer implementation that needs the ORB to ignore any thrown exceptions can simply catch and discard them itself.

In the draft 3.1 spec chapter 21.7 says the following: An Interceptor's behaviour may itself be modified by one or more Interceptor Policies. These Policy objects are created using a call to ORB::create_policy and are associated with an Interceptor during registration (see Section 21.7.2, ORBInitInfo Interface). All Policy interfaces defined in this section are local. The ORB can be accesed via the implicit get_orb operation of ORBInitInfo. The ORBInitInfo is passed on the pre_init and post_init call of the ORBInitializer but what should be the orb in the pre_init call? The orb is not initialized at that moment? Shouldn't it say that calling get_orb on the ORBInitInfo in the pre_init call gives the default exception that is given when get_orb is called on a local object?

The spec describes that anonymous types are deprecated and will be removed in the future (as below), but this is used throughout the spec. Before deprecating this fully, update the spec to not used anonymous types: >From 3.11.6 IDL currently permits the use of anonymous types in a number of places. For example: struct Foo

Anonymous types cause a number of problems for language mappings and are therefore deprecated by this specification. Anonymous types will be removed in a future version, so new IDL should avoid use of anonymous types and use a typedef to name such types instead. Compilers need not issue a warning if a deprecated construct is encountered.

Struct ServiceInformation is wrong, the sequence<> lines should be removed. struct ServiceInformation

;

The is an error in the ServiceDetail struct. service_detail is listed twice, the first one should be removed. struct ServiceDetail

;

Update: struct IOR

; to struct IOR

; And also use CORBA::OctectSeq instead of sequence<octet>

Minor formatting issue in: abstract valuetype Pollable

; boolean is_ready is in the wrong font in the idl overview

This section defines struct PolicyValue

; Which should be as below because anonymous types are deprecated struct PolicyValue

;

Third line of 23.1.3.4, ACTIVE must be bold

Proposal to change PortableInterceptor::AdapterState to a real enum. Now it is a short with constant values, but this means there is no real relationship between the type and the possible values as possible with an enum. With for example C++ we then can let the compiler check if we don't use incorrect values. module PortableInterceptor { enum AdapterState

; };

Proposal to change PortableInterceptor::ReplyStatus to a real enum. Now it is a short with constant values, but this means there is no real relationship between the type and the possible values as possible with an enum. With for example C++ we then can let the compiler check if we don't use incorrect values. module PortableInterceptor { enum ReplyStatus

; };

In 15.4.2 and 16.4.1 get_implementation is mentioned, but this method is nowhere else in the spec. Should this method be there? So far as I can see this is deprecated and should be removed.

Table 21-1 has the following note: When ClientRequestInfo is passed to send_request, there is an entry in the list for every argument, whether in, inout, or out. But only the in and inout arguments will be available. What is the behaviour when I request an out value? It says only that in/inout are available, but when I have an argument that is of out and I do get the value, do I then get an empty value (which could lead to a crash when using it), do I get an exception? That must be clearly specified by the spec

We see more and more use of unicode. It happens more and more that users have code that gets unicode (wchar) commandline arguments. In order to smoothen corba usage for these users we propose to add interface ORB

;

For a 24x7 system that doesn't shutdown and gets reconfigured it would be useful if we could for example change "-ORBDefaultInitRef" after the ORB has been initialized. That then would be used for any objects resolved after that. Maybe we could add CORBA::ORB::arg_list (inout arg_list argv); Which would change the arglist

ServiceContext is defined as: struct ServiceContext

; Anonymous types are deprecated, this should be struct ServiceContext

;

This chapter defines register_orb_initializer. This itself is ok, but at the moment we have a 24*7 system and we get a new ORBInitializer shipped in for example a DLL we maybe want to get rid of a certain orbinitializer that we registered earlier. This is currently not possible, we propose to add an unregister_orb_initializer which makes it possible to unregister an orbinitializer again

The corba spec defines a lot of policies. In 4.8.5 client exposed policies are listed. We do have several of them, also policies could be applied at several levels, but some of them can't be applied to each level. To our idea the scope at which policies can be applied should not only be in the possible, but also part of the policy itself. That way application code and the corba orb could check this. Maybe add this to policy typedef unsigned long PolicyScope; const PolicyScope POLICY_SCOPE_OBJECT = 0x01; const PolicyScope POLICY_SCOPE_CURRENT = 0x02; const PolicyScope POLICY_SCOPE_SCOPE = 0x04; const PolicyScope POLICY_SCOPE_POA = 0x08; const PolicyScore POLICY_SCOPE_CLIENT_EXPOSED = 0x10; Then add to the interface Policy readonly attribute PolicyScope policy_scope; This attribute can then be set in the policy with the values above as bitmask. This can be documented clearly in the documentation, orbs can check this, etc.

The CORBA spec defines the following types to proposage messaging qos. This is really nothing more then propagating policies values. struct PolicyValue

; typedef sequence<PolicyValue> PolicyValueSeq; This is now in the Messaging module, but the propagation of policy values is something that we want to use for ZIOP but also seems usable for other libraries. Instead of duplicating this struct to different modules I propose to move this to the IOP module.

The ORB is intended to be a local object, it is not to be used outside of the process, so it should be a local interface

the specification already deprecated anonymous types, but to our idea it would be time to update the specification to say that anonymous types are illegal and remove all references to them

The overview of all system exceptions is missing several ones which seem to be availalble in http://www.omg.org/docs/omg/03-01-04 For example NO_IMPLEMENT_TABLE minor code 8 is missing

The spec describes respository_id which should be repository_id. Is on two places, in 4.3.14 and 4.3

The POA state inactive is not used consistent. On several places it is called deactivated instead of inactive. For example in 11.3.8.2, in the transient bullet, it mentions: "Once the POA's POAManager enters the dactivated state". Chapter 11.3.2.1 describes clearly the states are: active, inactive, holding and discarding. I would propose to scan the complete spec for these incorrect POA Manager state.

The argument of the set_servant call has a small typo, it must be p_servant to match the full IDL spec some pages further

I would propose to change in the POAManager the following: State get_state(); string get_id(); to readonly attribute State the_state; readonly attribute string the_id; The get method just hide the fact that this are readonly attributes

Add a typedef for the POAManager id and use this throughout the spec for POAManager, POAManagerFactory and IORInterceptor add typedef string POAManagerId change in POAManager string get_id(); to POAManagerId get_id(); Or better (see other issue). readonly attribute POAManagerId the_id;

A lot of the methods on the POA which have USE_DEFAULT_SERVANT or USE_SERVANT_MANAGER as policies don't describe in detail what should happen when one of these policies is set, but no default servant/servant manager is set. For example reference_to_servant, when USE_DEFAULT_SERVANT is set and default servant is registered we return the default servant, but what when no default servant is set, is then the ObjectNotActive the correct exception? Shouldn't this be something like a system exception (bad inv order, obj adapter or something like that?)

this section says: // GIOP 1.0 struct LocateRequestHeader_1_0

; Anonymous types are deprecated so this struct has to be updated

The CCMHome interface does not provide a mechanism for obtaining references to all CCMObjects that the home has created (those that have not been removed). The lack of a method to get all the components created by a home is inconsistent with other sections of the CCM model (specifically the deployment module APIs). Furthermore, this method would be very useful as it would provide a mechanism for querying a Container for all existent components.

Resolution:

Replace the following text in formal/02-06-05 on page 1-41

interface CCMHome

;

with

typedef sequence<CCMObject> CCMObjects;

interface CCMHome

;

and add the operation description

get_components

The get_components operation returns a sequence of all existent CCMObject references (i.e. those that have not been removed) created by this CCMHome.

Document formal/02-06-05 on page 1-49 states the following:

"The implementation of a component type's home object may optionally support the
HomeConfiguration interface. The HomeConfiguration interface is derived from
Components::CCMHome. In general, the HomeConfiguration interface is
intended for use by an agent deploying a component implementation into a container,
or an agent deploying an assembly."

The first statement does not offer a clear interpretation when considering the language mapping for homes. If the implementation of a component type's home optionally supports HomeConfigurator how is this information defined in IDL? Should the component type's home definition support HomeConfiguration? This would seem to be the proper interpretation but that leads to problems in the language mapping of the defined home. In section 3.3.3.6 on page 3-45

Home Explicit Executor Interface

The home explicit executor callback interface is defined by the following rules:

1. For each home <home name>, a local explicit executor interface with the same
name as the home, but with a prefix of "CCM_" and a postfix of "Explicit" is
defined.

2. The explicit executor interface contains all attributes and operations declared by the
home.

3. If the home has a base with a name of <base name>, the explicit executor
interface inherits CCM_<base name>Explicit. If the home does not have a base,
the explicit executor interface inherits Components::HomeExecutorBase.

4. If the home has supported interfaces, they are inherited by the explicit executor
interface.

5. Additional operations are added to the explicit executor interface for factories and
finders, see below.

Item 4 would imply that the home explicit executor must include operations defined in both HomeConfigurator and CCMHome since HomeConfigurator extends CCMHome. This is clearly not the intended behavior of the home explicit executor since it specifically excludes any direct inheritance of CCMHome.

Resolution

The inheritance of CCMHome by HomeConfiguration should be removed since it is implied that every home will extend CCMHome and home definitions in IDL would then be able to explicitly support HomeConfiguration without the extra baggage of the CCMHome interface. Furthermore, the language mapping does not properly handle a component home that supports HomeConfiguration (if it extends CCMHome) since the component executor would include all CCMHome operations. The language mapping would work fine if HomeConfiguration did not extend CCMHome.

Replace text in formal/02-06-05 on page 1-49

The implementation of a component type's home object may optionally support the
HomeConfiguration interface. The HomeConfiguration interface is derived from
Components::CCMHome. In general, the HomeConfiguration interface is
intended for use by an agent deploying a component implementation into a container,
or an agent deploying an assembly.

with

The implementation of a component type's home object may optionally support the
HomeConfiguration interface. In general, the HomeConfiguration interface is
intended for use by an agent deploying a component implementation into a container,
or an agent deploying an assembly.

Replace IDL in formal/02-06-05 on page 1-49

module Components {
interface HomeConfiguration : CCMHome

;
};

I propose to introduce generic operations that allow
interconnecting ports regardless of their type. This
would ease generic programming.

The first part of the proposal is to allow generic
usage of the "connect" and "disconnect" operations
that are (currently) in the Receptacles interface,
i.e. to extend the functionality to not only work
on receptacles, but also on event source ports
(emits and publishes keywords).

The names "connect" and "disconnect" are appropriate
for any kind of port, and their signatures are the
same as "subscribe" and "unsubscribe" in the Events
interface.

The second part of the proposal is to introduce a
new operation "get_port" into the CCMObject interface.
This operation would take a FeatureName parameter and
return the object reference associated with that
facet or event sink.

So I propose the following steps:

1.) Allow connect, disconnect and get_connections to
operate on event source ports, and introduce a
get_port operation.
This change would be backwards compatible.

2.) Move connect, disconnect and get_connections from
the now inappropriate Receptacles interface into
the CCMObject interface. This step might cause
minor, easily fixable breakage for software that
widens an object reference to Receptacles instead
of CCMObject. (I don't think any such software
exists, it's more of a theoretical issue.)

3.) Discourage, then remove the "subscribe" and
"unsubscribe" operations in the Events interface.
They don't offer any more type safety than connect
and disconnect.

I believe that these changes would also be of interest
for slimming down CCM for the Lightweight CCM RFP, and
in light of the Streams for CCM RFP (which will likely
add another port type that needs interconnecting).

This change does not have any impact on component
implementations. The change to CCM implementations
(ORBs) is neglegible (I would expect a day to make
these changes in MicoCCM, another day to test them).

If there is general agreement on this issue, I will
draft the text updates.

this section says: // GIOP 1.0 struct LocateRequestHeader_1_0

; Anonymous types are deprecated so this struct has to be updated

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.