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

In “full” CORBA, the exception NoServant is used on in the operation
get_servant. Since this operation is not present in either the Compact Profile or the
Micro Profile, the exception should be removed to save the corresponding footprint.

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.

These operations should not have been included in the Micro Profile. They should only
be available in the Compact Profile. In the Micro Profile, the policy settings supported for
these policies by the Root (and only) POA are specified. Therefore, there is no need to
create these policy objects

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 intent is that register_initial_reference is not in the Micro profile. The consolidated
IDL should be corrected

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

Upon further discussion, use cases that demonstrated the need for either
create_reference or create_reference_with_id in either profile are
lacking. (create_reference and create_reference_with_id were
developed for use with Servant Managers, mainly). Therefore, both of these operations
are removed from the Compact and from the Micro profile.

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.

Change as suggested

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?

close

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.

get_interface should be excluded from both profiles for the stated reasons.
get_interface was not included in the Minimum CORBA specification.

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

Add the description of register_initial_reference from section 21.8.1 in
CORBA 3.0.3 to the specification. (It is somewhat misplaced in the CORBA 3.0.3
specification).
Add correct cross references to the last three sentences before section 8.2.1.

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

Since 11.4.1 is confined to the Compact profile and section 11.4.2 separately
shows the interface supported by the Micro profile, the #if statements are
redundant and should be removed.

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

The contents of the Interoperability sections were not touched, only reorganized.
However, get_implementation was deprecated in CORBA 2.2, and should be
removed from this document and from the “full” CORBA specification.
Issue opened with CORBA RTF to reconcile.

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

Change as suggested.

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.

No Data Available

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.

No Data Available

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

NO_IMPLICIT_ACTIVATION was the intent

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.

Change as suggested

The InvalidPolicies exception uses an anonymous sequence as member. Instead of exception InvalidPolicies

; It should be exception InvalidPolicies

;

Accepted as suggested.
Issue opened with CORBA RTF to reconcile.

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.

Accept as suggested: developed and added comparison table as Annex B.

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

Correct diagram (now 11-5) to “proper syntax”.