CORBA Embedded Avatar
  1. OMG Specification

CORBA Embedded — All Issues

  • Acronym: CORBAe
  • Issues Count: 19
  • Description: All Issues
Open Closed All
All Issues

Issues Descriptions

CORBA section 11 struct PortableGroup::GroupInfo

  • Legacy Issue Number: 12512
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Steve Osselton)
  • Summary:

    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?

  • Reported: CORBAe 1.0b1 — Tue, 27 May 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred Automatically

    This proposal was generated automatically.

  • Updated: Mon, 30 Mar 2020 19:47 GMT

exception NoServant();

  • Key: CORBAE-21
  • Legacy Issue Number: 9921
  • Status: closed  
  • Source: PrismTech ( Donald Sharp)
  • Summary:

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

  • Reported: CORBAe 1.0b1 — Fri, 14 Jul 2006 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 23:30 GMT

Section: 8

  • Key: CORBAE-20
  • Legacy Issue Number: 9920
  • Status: closed  
  • Source: PrismTech ( Donald Sharp)
  • Summary:

    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.

  • Reported: CORBAe 1.0b1 — Fri, 14 Jul 2006 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 23:30 GMT

Section: 5.2 and 5.7

  • Key: CORBAE-19
  • Legacy Issue Number: 9879
  • Status: closed  
  • Source: PrismTech ( Donald Sharp)
  • Summary:

    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?

  • Reported: CORBAe 1.0b1 — Fri, 30 Jun 2006 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    The intent is that register_initial_reference is not in the Micro profile. The consolidated
    IDL should be corrected

  • Updated: Fri, 6 Mar 2015 23:30 GMT

Section: 8.2

  • Key: CORBAE-18
  • Legacy Issue Number: 12211
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

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

  • Reported: CORBAe 1.0b1 — Tue, 5 Feb 2008 05:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.2.2

  • Key: CORBAE-14
  • Legacy Issue Number: 11331
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: CORBAe 1.0b1 — Fri, 7 Sep 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.2.1.1

  • Key: CORBAE-12
  • Legacy Issue Number: 11306
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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.

  • Reported: CORBAe 1.0b1 — Sat, 25 Aug 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong references in chapter 11

  • Key: CORBAE-16
  • Legacy Issue Number: 11415
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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.

  • Reported: CORBAe 1.0b1 — Mon, 17 Sep 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Change as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA/e and get_interface

  • Key: CORBAE-13
  • Legacy Issue Number: 11324
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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?

  • Reported: CORBAe 1.0b1 — Fri, 31 Aug 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    close

  • Updated: Fri, 6 Mar 2015 20:58 GMT

More wrong references in chapetr 11

  • Key: CORBAE-17
  • Legacy Issue Number: 11416
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: CORBAe 1.0b1 — Mon, 17 Sep 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.4.1

  • Key: CORBAE-15
  • Legacy Issue Number: 11334
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: CORBAe 1.0b1 — Fri, 7 Sep 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 6.2.12

  • Key: CORBAE-11
  • Legacy Issue Number: 11113
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: CORBAe 1.0b1 — Tue, 26 Jun 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Change as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The removal of static any from micro

  • Key: CORBAE-10
  • Legacy Issue Number: 10599
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: CORBAe 1.0b1 — Fri, 19 Jan 2007 05:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Servant_to_id clarification

  • Key: CORBAE-9
  • Legacy Issue Number: 10522
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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.

  • Reported: CORBAe 1.0b1 — Tue, 12 Dec 2006 05:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 6.2

  • Key: CORBAE-6
  • Legacy Issue Number: 9809
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

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

    { sequence <unsigned short> indices; }

    ; It should be exception InvalidPolicies

    { UShortSeq indices; }

    ;

  • Reported: CORBAe 1.0b1 — Thu, 8 Jun 2006 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.2.3

  • Key: CORBAE-8
  • Legacy Issue Number: 10507
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: CORBAe 1.0b1 — Thu, 7 Dec 2006 05:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    NO_IMPLICIT_ACTIVATION was the intent

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add table that captures the features that are in/out of CORBA/e

  • Key: CORBAE-5
  • Legacy Issue Number: 9756
  • Status: closed  
  • Source: Industrial Internet Consortium ( Stephen Mellor)
  • Summary:

    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.

  • Reported: CORBAe 1.0b1 — Tue, 14 Feb 2006 05:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

state machine diagram

  • Key: CORBAE-4
  • Legacy Issue Number: 9755
  • Status: closed  
  • Source: Industrial Internet Consortium ( Stephen Mellor)
  • Summary:

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

  • Reported: CORBAe 1.0b1 — Tue, 14 Feb 2006 05:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

document style and use of headings

  • Key: CORBAE-7
  • Legacy Issue Number: 9926
  • Status: closed  
  • Source: Lockheed Martin ( Ben Calloni)
  • Summary:

    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.

  • Reported: CORBAe 1.0b1 — Tue, 18 Jul 2006 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Change as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT