Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — Closed Issues

  • Acronym: CORBA
  • Issues Count: 19
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA31-112 Section: 15.4.5.1 struct has to be updated CORBA 3.0.3 CORBA 3.1 Deferred closed
CORBA31-218 ZIOP has to be part of the core CORBA specification ZIOP 1.0 CORBA 3.1.1 Resolved closed
CORBA31-217 Japan CORBA Part 2 PAS Ballot Comments - comment 12 CORBA 3.1 CORBA 3.1.1 Resolved closed
CORBA31-216 Sections 8.1.1, 8.2.1: CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-212 Section 7.1, line1: CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-211 Figure 1 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-215 Section 8.1.1 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-214 7.2, sentence 3 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-213 - Figure 2 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-210 use the proper notation for expressing Profiles CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-209 Minor comments re Components FTF CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-208 Section 7.2 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-207 On Page 18 - Figure 11 Home mapping CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-206 Section 7, Overview CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-205 sections 1, 3, 4, 5 essentially empty CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-204 Section: exceptions CORBA 3.0.3 CORBA 3.1 Closed; No Change closed
CORBA31-203 Codec Interface Deficiencies CORBA 3.0.3 CORBA 3.1 Duplicate or Merged closed
CORBA31-110 ValueMembersSeq CORBA 3.0.2 CORBA 3.1 Resolved closed
CORBA31-111 Make a typedef for the POA id new CORBA 3.0.3 CORBA 3.1 Resolved closed

Issues Descriptions

Section: 15.4.5.1 struct has to be updated

  • Legacy Issue Number: 12858
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    this section says: // GIOP 1.0 struct LocateRequestHeader_1_0

    { // Renamed LocationRequestHeader unsigned long request_id; sequence <octet> object_key; }

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

  • Reported: CORBA 3.0.3 — Tue, 23 Sep 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 18 Feb 2019 00:01 GMT

ZIOP has to be part of the core CORBA specification

  • Legacy Issue Number: 16922
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The ZIOP specification is an addition to CORBA and should be merged into the main CORBA specification instead of being a stand alone specification

  • Reported: ZIOP 1.0 — Tue, 20 Dec 2011 05:00 GMT
  • Disposition: Resolved — CORBA 3.1.1
  • Disposition Summary:

    Move the ZIOP Compression module to CORBA Part 1, section 18
    Move the ZIOP Module to CORBA Part 2, section 12

  • Updated: Thu, 12 Mar 2015 02:25 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 12

  • Legacy Issue Number: 14394
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    7.5
    Comment:
    "see CORBA part1, clause 4" is ambiguous.
    Proposed change:
    Replace "see CORBA part1, clause 4" with "in clause 5 of ISO/IEC 19500-1, The Object Model".

  • Reported: CORBA 3.1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — CORBA 3.1.1
  • Disposition Summary:

    Agree to refer to named clause in 19500-1

  • Updated: Sun, 8 Mar 2015 18:08 GMT

Sections 8.1.1, 8.2.1:

  • Legacy Issue Number: 7920
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    8.1.1, 8.2.1: the description of the metamodel is very skimpy: for
    example there is no description anywhere about what FinderDef is. There
    should be a separate section for each class with a description of each
    attribute/reference. Conversely the text also talks about 'component
    types' which have 'attributes' (and ports) - this has no obvious
    correspondence with the metamodel (are the attributes in the BaseIDL
    package?). Likewise the text refers to a component being able to inherit
    from one other interface - this is not depicted.

    • most of the OCL constraints make use of 'isStereotyped()' which is
      not OCL, UML nor defined in this specification.
    • Table 10: most of the Tags seem to have no correspondence in the
      metamodel e.g. containerType.
  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Section 7.1, line1:

  • Legacy Issue Number: 7916
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    7.1, line1: It's not strictly true to say that the CCM Profile
    'specializes' the UML Core package: the latter is the reference
    metamodel for the former.

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Figure 1

  • Legacy Issue Number: 7915
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Figure 1 - the import dependencies should be shown with an 'import'
    stereotype

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Section 8.1.1

  • Legacy Issue Number: 7919
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    8.1.1 the heading is 'IDL metamodel' but the caption is 'IDL3
    Metamodel', and in 7.2 it is 'ComponentIDL'.

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

7.2, sentence 3

  • Legacy Issue Number: 7918
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    7.2, sentence 3: it is confusing to refer to BaseIDL as the
    'reference metamodel' since that terminology has a specific meaning for
    Profiles which does not apply here.

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

- Figure 2

  • Legacy Issue Number: 7917
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:
    • Figure 2: the arrows are not correct: they should represent a valid
      MOF 1.4 Package relationship (one of clustering, generalization,
      nesting, import). More seriously, since ComponentIDL is nested within
      metamodel CCM it is not allowed to have an import/cluster relationship
      with an external metamodel (BaseIDL in this case): MOF constraint [C49]
      states that "Nested Packages cannot import or cluster other Packages or
      Classes.".
  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

use the proper notation for expressing Profiles

  • Legacy Issue Number: 7914
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Should use the proper notation for expressing Profiles. The
    presentation of the Profile (e.g. in Table 1) is confusing in mixing
    references to the equivalent metamodel with references to the reference
    metamodel (UML) being extended by the Profile. Though the diagrams in
    the separate section 8.1.3 make things a lot clearer.

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Minor comments re Components FTF

  • Legacy Issue Number: 7913
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The Report should reference the document number of the Final Adopted
    Spec as the base document.

    • Issue 7628: the final line of the resolution is too vague "add the
      package...and update relations"
    • There should be accompanying MOF XMI (for the metamodel) and UML XMI
      (for the profile).
  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Section 7.2

  • Legacy Issue Number: 7912
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 7.2 states says that "BaseIDL that is a MOF-compliant
    description of the pre-existing CORBA Interface Repository that is
    already specified in the UML Profile for CORBA" - however in the
    document referred to for the latter (ptc/00-10-01) there is no mention
    of BaseIDL - in fact there is no metamodel only a pure profile. BTW a
    more up-to-date reference would be formal/02-04-01. This spec is clearly
    dependent on BaseIDL and so it's important to have a proper reference
    (and this should be in Section 3). In fact the appropriate reference for
    BaseIDL seems to be the CORBA components spec.

    The front page of convenience document, and document footer, still refer
    to it as a (Final) Adopted Specification

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

On Page 18 - Figure 11 Home mapping

  • Legacy Issue Number: 7911
  • Status: closed  
  • Source: Technical University Berlin ( Christian Hein)
  • Summary:

    On Page 18 - Figure 11 Home mapping. To me, it doesn't seems properly that CORBAValue inherits from AssociationClass. Perhaps it make sense that the HomeDef gets an attribute with name 'primary key'.

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Section 7, Overview

  • Legacy Issue Number: 7903
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 7, Overview consists only of 3 bullets that are instructions to an author rather than an overview e.g. "Explain relations to BaseIDL package"

  • Reported: CORBA 3.0.3 — Thu, 4 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

sections 1, 3, 4, 5 essentially empty

  • Legacy Issue Number: 7902
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The Convenience Document has sections 1, 3, 4, 5 essentially empty except for 'Editorial Comment: Needs to be completed'. They do need to be completed!
    Even worse, section 2, Conformance, also has a similar 'needs to be completed': though it does contain some text it is nothing like a conformance statement.
    I found it unclear whether the spec was providing a normative metamodel or just a normative profile: the text to be added to Section 1 (Scope) and Section 2 (Conformance) should clarify.

  • Reported: CORBA 3.0.3 — Thu, 4 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    see below

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Section: exceptions

  • Legacy Issue Number: 11027
  • Status: closed  
  • Source: wipro ( Rashmi)
  • Summary:

    org.omg.CORBA.NO_PERMISSION: vmcid: 0x0 minor code: 103 completed: No | | at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native | | Method) | | at | | sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcces | | sorImpl.java:39) Feb 19 15:48:44 NMADR2CMT1 root: [NotificationChannel]NotificationChannel( ). Creating channel NpmChannel Feb 19 15:52:28 NMADR2CMT1 root: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No Feb 19 15:52:28 NMADR2CMT1 root: above mentioned are the errors we are getting from the the client appilcation. can anybody provide us the information why these execptions are generated and how to fix this kind of errors.

  • Reported: CORBA 3.0.3 — Mon, 21 May 2007 04:00 GMT
  • Disposition: Closed; No Change — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Codec Interface Deficiencies

  • Legacy Issue Number: 7731
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    CORBA 3, chapter 13.8, defines the Codec interface to encode
    arbitrary data values into CORBA::OctetSeq "blobs" and vice
    versa. This interface can be used, e.g., to supply and retrieve
    ServiceContext data using the PortableInterceptor interfaces.

    In practice, the Codec interface is also being used for data
    serialization, i.e., to store and retrieve arbitrary values in
    files or other databases.

    However, the interface is deficient in that it does not consider
    all possible variables that are needed for interoperability.
    It supports setting the CDR version that is to be used, but
    neglects byteorder and codeset settings.

    Consequently, the encoded values are platform-specific. If a
    value was encoded on a little-endian system, it will not decode,
    or worse, decode erroneously, on a big-endian system. The same
    caveats apply to codesets, e.g., when an ISO-8859-1 encoded
    blob is decoded using UTF-8 or Windows-1252.

    To support interoperability, the Codec interface needs to be
    extended.

    My recommendation is to extend the CodecFactory interface,
    so that it supports creating CDR version-, byteorder-, and
    codeset-specific Codec instances, either supplying user-
    provided values for each, or informing the user about chosen
    defaults.

    Example:

    module IOP {
    const EncodingFormat ENCODING_DEFAULT = -1;

    typedef short ByteorderFormat;
    const ByteorderFormat BYTEORDER_DEFAULT = -1;
    const ByteorderFormat BYTEORDER_BIGENDIAN = 0;
    const ByteorderFormat BYTEORDER_LITTLEENDIAN = 1;

    struct EncodingExt

    { EncodingFormat format; octet major_version; // set to 0 for default octet minor_version; ByteorderFormat byteorder; CONV_FRAME::CodeSetId char_data; // set to 0 for default CONV_FRAME::CodeSetId wchar_data; // set to 0 for default }

    ;

    local interface CodecFactory

    { // create_codec remains as before Codec create_codec_ext (inout EncodingExt enc) raises (UnknownEncoding); }

    ;
    };

    The create_codec_ext operation would create an appropriate
    Codec instance, if available; it will then set all "default"
    members of the EncodingExt structure to their actual values,
    so that the application can store this information along
    with any encoded values.

    One potential criticism of the above is that the encoding
    format's parameters depend on the encoding format. For example,
    there may be encoding formats that are byteorder-independent,
    or that consistently use UTF-32 for strings, thus not needing
    codeset parameters. Also, they may use wildly different
    versioning. So a "better" solution might involve passing
    the EncodingFormat, and an Any with a format-specific data
    type.

    That could look like:

    module GIOP {
    typedef short ByteorderFormat;
    const ByteorderFormat BYTEORDER_DEFAULT = -1;
    const ByteorderFormat BYTEORDER_BIGENDIAN = 0;
    const ByteorderFormat BYTEORDER_LITTLEENDIAN = 1;

    struct CDREncodingParameters

    { octet major_version; // set to 0 for default octet minor_version; ByteorderFormat byteorder; CONV_FRAME::CodeSetId char_data; // set to 0 for default CONV_FRAME::CodeSetId wchar_data; // set to 0 for default }

    ;
    };

    module IOP {
    const EncodingFormat ENCODING_DEFAULT = -1;

    local interface CodecFactory

    { // create_codec remains as before Codec create_codec_ext (inout EncodingFormat format, inout Any parameters) raises (UnknownEncoding); }

    ;
    };

    Once we have consensus on the approach, I will gladly volunteer
    to come up with a full set of editing instructions

  • Reported: CORBA 3.0.3 — Thu, 9 Sep 2004 04:00 GMT
  • Disposition: Duplicate or Merged — CORBA 3.1
  • Disposition Summary:

    duplicate

  • Updated: Fri, 6 Mar 2015 22:25 GMT

ValueMembersSeq

  • Legacy Issue Number: 5939
  • Status: closed  
  • Source: MetroApp Entertainment ( Keith Allyn Baker)
  • Summary:

    ValueMembersSeq is not defined in the CORE Specification and appears in interface ORB, but I believe it is a typo of ValueMemberSeq:

    TypeCode create_value_tc ( in RepositoryId id, in Identifier name, in ValueModifier type_modifier, in TypeCode concrete_base, in ValueMembersSeq members );

  • Reported: CORBA 3.0.2 — Sun, 11 May 2003 04:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    In CORBA v3.3 Part 1 Interfaces, section section 8.2 change ValueMembersSeq to
    ValueMemberSeq

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

Make a typedef for the POA id new

  • Legacy Issue Number: 7891
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Made a typedef for the POA id new: local interface POA

    { typedef CORBA::OctetSeq POAid; }

    change: local interface POA

    { readonly attribute CORBA::OctetSeq id; }

    to: local interface POA

    { readonly attribute POAid id; }
  • Reported: CORBA 3.0.3 — Mon, 1 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

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