Issues for 2nd CORBA/e Finalization Task Force

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

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

Issue 9755: state machine diagram
Issue 9756: Add table that captures the features that are in/out of CORBA/e
Issue 9809: Section: 6.2
Issue 9879: Section: 5.2 and 5.7
Issue 9920: Section: 8
Issue 9921: exception NoServant();
Issue 9926: document style and use of headings
Issue 10507: Section: 11.2.3
Issue 10522: Servant_to_id clarification
Issue 10598: The use of Full Services definitions in CORBA/e spec
Issue 10599: The removal of static any from micro
Issue 11113: Section: 6.2.12
Issue 11306: Section: 9.2.1.1
Issue 11324: CORBA/e and get_interface
Issue 11331: Section: 18.2.2
Issue 11334: Section: 11.4.1
Issue 11415: Wrong references in chapter 11
Issue 11416: More wrong references in chapetr 11
Issue 12211: Section: 8.2
Issue 12512: CORBA section 11 struct PortableGroup::GroupInfo
Issue 16109: Technology Related Questions - CORBA/e Mutex Interface

Issue 9755: state machine diagram (corba-e-ftf)

The "state machine diagram" on pg 8-13 of the 473 page spec isn't UML.  (See the dotted state.)

The whole spec is apparently a subset (with rationale) with compliance points of the original CORBA spec.  There should be a table that captures the features that are in/out of CORBA/e so that readers can determine quickly what is in the CORBA/e spec (or out), and how it differs.
 
Same would apply to CORBA/i when it becomes available.

The InvalidPolicies exception uses an anonymous sequence as member. Instead of exception InvalidPolicies { sequence <unsigned short> indices; }; It should be exception InvalidPolicies { UShortSeq indices; };

Under ORB Operations register_initial_reference is inside #if ! defined(CORBA_E_MICRO) on page 5-4. Under Consolidated IDL on page 5-35 it is outside the #if ! defined(CORBA_E_MICRO). Where should it fall? 

The following are included in the Micro Profile but missing from the Compact Profile // Factories for Policy objects LifespanPolicy create_lifespan_policy ( in LifespanPolicyValue value ); IdUniquenessPolicy create_id_uniqueness_policy ( in IdUniquenessPolicyValue value ); IdAssignmentPolicy create_id_assignment_policy ( in IdAssignmentPolicyValue value ); This appears to be an oversight because they are present in minimumCORBA. 

exception NoServant(); is included in local interface POA but had been removed from minimumCORBA. Is it definitely back in? 

In each of 2.4.1 thru 2.4.4 the document titles have paragraphs below them and if necessary then sub headings.  In 2.4.5 there is the title and then a sub heading.

I'd recommend deleting the heading of 2.4.5.1 and make 2.4.5 the Quality of Service Abstract Model (or Quality of Service Model to match 2.4.1 - 2.4.4 and put the rest of the text under it

As reads: 

2.4.5Quality of Service 

2.4.5.1 QoS Abstract Model The abstract model describes the Quality of Service (QoS) components and their relationships. The specification defines a framework within which current QoS levels are queried and overridden. This framework is intended to be of use for CORBAServices specifiers, as well as for future revisions of CORBA. 

To read: 

2.4.5Quality of Service (Abstract) Model 
The abstract model describes the Quality of Service (QoS) components and their relationships. The specification defines a framework within which current QoS levels are queried and overridden. This framework is intended to be of use for CORBAServices specifiers, as well as for future revisions of CORBA. 

What is the exact implicit activation policy the root poa should support for CORBA/e compact and micro. The page 175 says IMPLICIT_ACTIVATION but section 11.3.3.2 and 11.3.3.1 say NO_IMPLICIT_ACTIVATION

In the OMG spec the servant_to_id is described as below. If the RETAIN,
NO_IMPLICIT_ACTIVATION an UNIQUE has been set then the pre condition is
valid so we don't get wrong policy. Then we follow the steps, 1 is not
possible, 2 is also not possible, 3 is not possible, so 4 is triggered but
that looks very strange. I think there should be another step says if RETAIN
and UNIQUE and NO_IMPLICIT_ACTIVATION and not active then we get
WrongPolicy. Ok, the servant is not active, but it is more that the policies
are wrong. 


This appeared when testing for CORBA/e compact. There RETAIN,
NO_IMPLICIT_ACTIVATION and UNIQUE are the default and without a special
check for CORBA/e we got a ServantNotActive exception instead of the wrong
policy. We could add a check for CORBA/e compact but it looks that the real
issue is in the core spec already.


Johnny


This operation requires the USE_DEFAULT_SERVANT policy or a combination of
the
RETAIN policy and either the UNIQUE_ID or IMPLICIT_ACTIVATION policies if
invoked outside the context of an operation dispatched by this POA. If this
operation is
not invoked in the context of executing a request on the specified servant
and the policies
specified previously are not present, the WrongPolicy exception is raised.
This operation has four possible behaviors.
1. If the POA has both the RETAIN and the UNIQUE_ID policy and the specified
servant is active, the Object Id associated with that servant is returned.
March 2004 CORBA, v3.0.3: Interfaces 11-43
11
2. If the POA has both the RETAIN and the IMPLICIT_ACTIVATION policy and
either the POA has the MULTIPLE_ID policy or the specified servant is not
active,
the servant is activated using a POA-generated Object Id and the Interface
Id
associated with the servant, and that Object Id is returned.
3. If the POA has the USE_DEFAULT_SERVANT policy, the servant specified is
the
default servant, and the operation is being invoked in the context of
executing a
request on the default servant, then the ObjectId associated with the
current
invocation is returned.
4. Otherwise, the ServantNotActive exception is raised.

Intent of specification was exactly as specified. Use of WrongPolicy should be
independent of any state of servant to which operation is applied.
Disposition: Closed, no change

Problem:

 

Since CORBA/e is for embedded constrained systems, one should be using LW Services as a minimal compliant point this would still allow one to offer up a Full Services in its offering but the other way around would not be compliant.

 

Suggested Change

The suggested change is to use LW Services definitions for CORBA/e.

Consensus was not reached on this issue in time.

Problem: The use of static any may be needed in a micro profile. For example, SDR Deployment and Configuration which can be done for embedded constrained environments for signal processing environments such as DSP and RTL devices need this capability.

 

Suggested Change

Make the static any as an optional compliance point that is not mandatory but is part of the profile.

The profiles for CORBA/e were developed in order to cut down the confusion associated
with the number of optional compliance points in the present specification. Therefore, the
introduction of an option on a profile (which is already an option) is resisted.
Inclusion of (static) Any in the Micro profile was also considered, and rejected because it
would leave no profile without the option of removing support for type Any, a significant
cost in footprint and complexity. Therefore, no changes were made.
Disposition: Closed, no change

for localobject the interfaces are listed that raise a no_implement, but some methods are listed that are not part of corba/e, like get_component, I think these methods should be removed

A question, when I look at the CORBA/e compact info it says: no DII, DSI, Interface Repository, or Component support. But, when looking at the spec, CORBA::Object does deliver get_interface, which is documented as below. Why does CORBA/e state that we don’t support the interface repository, but we do deliver an operation for it? Shouldn't get_interface be removed from CORBA/e? >From the spec: get_interface, returns an object in the Interface Repository that describes the most derived type of the object addressed by the reference. See the Interface Repository chapter for a definition of operations on the Interface Repository. The implementation of this operation may involve contacting the ORB that implements the target object. If the interface repository is not available, get_interface raises INTF_REPOS with standard minor code 1. If the interface repository does not contain an entry for the object's (most derived) interface, get_interface raises INTF_REPOS with standard minor code 2. 

A question, when I look at the CORBA/e compact info it says: no DII, DSI,
Interface Repository, or Component support.


But, when looking at the spec, CORBA::Object does deliver get_interface,
which is documented as below. Why does CORBA/e state that we don't support
the interface repository, but we do deliver an operation for it?

See issue 11306 for disposition

In 18.2.2 the get_implementation method is mentioned, but this is not mentioned anywhere else in this spec, should the get_implementation be part of CORBA/e, to my idea not

On this page we have: #if ! defined (CORBA_E_MICRO) // POA attributes readonly attribute string the_name; readonly attribute POA the_parent; readonly attribute POAManager the_POAManager; But there is not endif associated with the !defined

Chapter 11 starts with the text below, see that it references chapter 8, that should be 11: Conformant implementations of the CORBA/e Compact Profile must comply with clauses 8.1, 8.2, 8.3 and 8.4.1 of this chapter. Conformant implementations of the CORBA/e Micro Profile must support a single root POA and must comply with clauses 8.1, 8.2, 8.3 (except 8.3.4.1, 8.3.4.2, 8.3.4.4, 8.3.4.9, and 8.3.4.12) and 8.4.2 of this chapter.

Section 11 starts with the note that 8.3.4.12 is not required for CORBA/e micro (which should be 11.3.4.12). But the consolidated IDL for corba/e micro does mention this method, probably it needs to removed from there. Maybe also add a note about this to 11.3.4.12

At the end of section 8.2, there are several sentences that are incomplete and missing cross references

In chapter 11 'Unreliable Mulicast Inter-ORB Protocol' the struct PortableGroup::GroupInfo is discussed. However in the consolidated IDL and the IDL available from the OMG web site, this struct has been replaced by PortableGroup::TagGroupTaggedComponent. Which is correct?

I have a question and perhaps a bug to report in the CORBA/e v1.0 IDL files.   According to the specification “formal/2008-11-06”, the Compliance heading in chapter 12 says implementations of the CORBA/e Micro Profile must comply with 12.8­the Mutex interface.  Does this mean all of 12.8, including RTCORBA::Mutex and the portions of RTCORBA::RTORB that are shown in the chapter?   If so, there is an error in the preprocessor directives contained in accompanying IDL file: http://www.omg.org/spec/CORBAe/20080201/RTCORBA.idl.
 
If the IDL file is correct, then a CORBA/e Micro implementation should not implement any of RTORB, even create_mutex() and destroy_mutex().  See line 174 of the IDL.  I am assuming that the specification is correct and the IDL is in error, but some clarification would be appreciated.