Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — All Issues

  • Acronym: CORBA
  • Issues Count: 40
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA34-249 Internalizing roles-IDL optimization CORBA 2.1 CORBA 3.4 Deferred closed
CORBA24-186 Section 3.3.8.16:deactivate_object() operation CORBA 2.1 CORBA 2.4 Resolved closed
CORBA22-142 union typecode CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-141 CDR encoding of TypeCode names inconsistent with equal operation CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-133 marshalling service context CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-132 Alignment and offsets in the presence of fragmentation CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-131 Changes to and strategy for 1.2 CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-130 Section 12.7.2 type IIOP::ProfileBody_1_0 not compatible CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-129 IIOP marshalling of empty strings CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-128 Additional enumeration to the ReplyStatusType CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-127 Additional Requirement for GIOP 1.2 CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-126 Clarification on IIOP2.1 12.3.2 fixed point type representation needed CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-140 Typos in PIDL to C++ mappings CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-139 Typo in C++ mapping CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-106 CORBA::Contained::describe() underspecified CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-105 Incorrect definition of "object type" CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-104 Resetting #pragma prefix? CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-103 Trader constraint language and international characters CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-102 defined_in member of ModuleDescription for top-level module CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-101 Inheritance of Exceptions CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-100 Question about typecode creation CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-99 #pragma processing CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-98 Ambiguity in non_existent() specification CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-97 Appendix B lists incorrect CORBA Components IDs CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-96 union typecode (02) CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-95 locally constrained CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-94 IDL types are ambiguous with inheritance CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-93 RIDs CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-92 Containers CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-91 Proposed IFR exceptions CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-90 TypedefDef issue CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-89 CORBA 2.1 IR Structdef typo CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-88 Minor bug in 2.1 spec CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-87 Inheriting exceptions in IDL CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-86 Inclusion of standard exception CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-85 Issue with ObjectId_to_string and string_to_ObjectId CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-84 Bug in the 2.1.spec for IDL unions CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-83 Figure 2-2 in CORBA 2.0 and CORBA 2.1 CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-82 Octet and enum constants CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-81 Non ASCII alphabetics in IDL identifiers CORBA 2.1 CORBA 2.2 Resolved closed

Issues Descriptions

Internalizing roles-IDL optimization

  • Legacy Issue Number: 706
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The IDL for internalizing roles could be optimized to reduce the size of the externalized data as well as simplifying the implementation

  • Reported: CORBA 2.1 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Section 3.3.8.16:deactivate_object() operation

  • Legacy Issue Number: 675
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section states that the deactivate_object() operation doesn"t wait for etherialize operation to complete before it returns. This is impossible to implement in single-threaded ORB

  • Reported: CORBA 2.1 — Wed, 13 Aug 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

union typecode

  • Legacy Issue Number: 811
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. The label value corresponding to a default label should be
    designated explicitly either as an ignored field whose size equals the
    size for the discriminator type, as some value that does not coincide
    with another label value, as reserverd for future use, or as absent
    (Table 12-2 and page 12-16, "encoding the tk_union Default Case" of
    IIOP 2.1).

  • Reported: CORBA 2.1 — Tue, 23 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:34 GMT

CDR encoding of TypeCode names inconsistent with equal operation

  • Legacy Issue Number: 719
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should the TypeCode equal operation compare the results of name() to determine TypeCode equality? Same question for member_name()

  • Reported: CORBA 2.1 — Wed, 10 Sep 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Duplicate of issue 665

  • Updated: Fri, 6 Mar 2015 21:34 GMT

marshalling service context

  • Legacy Issue Number: 905
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The question is: What is the exact marshalling for an encapsulation
    of a zero length sequence? (Service context is an encapsulation of a
    sequence. CORBA 2.1, Section 10.6.7, page 10-22.)
    While it may or may not be an ambiguity,
    it does appear that ORB vendors differ in their interpretations, so
    it might be important to clarify it.

  • Reported: CORBA 2.1 — Wed, 14 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed, no revision required

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

Alignment and offsets in the presence of fragmentation

  • Legacy Issue Number: 904
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Its not clear to me how octet indices used for alignment and for
    TypeCode indirection offsets are calculated in the presence of
    fragmentation. Different interpretations will prevent successful
    interoperablity when fragmentation is used. IIOP 1.2 should clarify how alignment and TypeCode indirection work in the presence of fragmentation.

  • Reported: CORBA 2.1 — Tue, 13 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with revision

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

Changes to and strategy for 1.2

  • Legacy Issue Number: 886
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are 2 changes:
    1. add the request id to message fragments so that fragmentation is usable.
    2. change the alignment rules so that message headers may be changed
    without having to remarshal the body.
    [ as an aside we"d really like to remove all the alignment rules so that
    any"s no longer have to be double marshaled, but we don"t think its
    possible to deal with all the details quickly ]
    3. Add some more addressing information to request, locate_request,etc.

  • Reported: CORBA 2.1 — Thu, 8 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

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

Section 12.7.2 type IIOP::ProfileBody_1_0 not compatible

  • Legacy Issue Number: 885
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 12.7.2 defines the type IIOP::ProfileBody_1_0, which is
    supposed to be compatible with the type ProfileBody of earlier
    versions of CORBA. Unfortunately, it has a different repository
    ID, leading to incompatibilities.
    Proposed change: Add two pragmas to section 12.7.2, inside
    the module IIOP

  • Reported: CORBA 2.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

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

IIOP marshalling of empty strings

  • Legacy Issue Number: 817
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Add a rule to CDR that allows an empty string to be marshaled as a four byte count of zero, followed by nothing. This change is backward compatible because a count value of zero is currently impossible.
    For a structure with five simple data members, this reduces the size of the
    TypeCode on the wire from 88 bytes to 60 bytes (32% saving).

  • Reported: CORBA 2.1 — Mon, 1 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

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

Additional enumeration to the ReplyStatusType

  • Legacy Issue Number: 807
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Add an additional enumeration to the ReplyStatusType (and
    LocationStatusType) called LOCATION_FORWARD_PERM (and
    OBJECT_FORWARD_PERM) that acts like the current LOCATION_FORWARD (and
    OBJECT_FORWARD), but can be used as a hint by the client that it should
    permanently discard the original IOR and replace it with the new IOR.

  • Reported: CORBA 2.1 — Wed, 10 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

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

Additional Requirement for GIOP 1.2

  • Legacy Issue Number: 798
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"d like to suggest that for GIOP 1.2 that we add an additional requirement
    that an eight byte alignment occur before the body of any message.
    This allows for numerous optimizations that currently cannot be performed
    because the alignment of the beginning of the bodies is not consistent.

  • Reported: CORBA 2.1 — Mon, 22 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

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

Clarification on IIOP2.1 12.3.2 fixed point type representation needed

  • Legacy Issue Number: 782
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In CORBA /IIOP 2.1, 12.3.2 OMG IDL Constructed Types, Fixed-Point Decimal Type Section it is unclear to me that where is the decimal point in the IDL Fixed Type Representation (Figure 12-3), how the scale information is represented in the format

  • Reported: CORBA 2.1 — Fri, 7 Nov 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close with no change: The scale information is in the IDL definition of the fixed-point type

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

Typos in PIDL to C++ mappings

  • Legacy Issue Number: 804
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I think that there is a pervasive Typo in Appendix A of chapter 18.
    A number of the PIDL classes include a member function _duplicate.
    It should be declared as a static member function
    with an argument; i.e. the pointer to be "duplicated".

  • Reported: CORBA 2.1 — Thu, 4 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

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

Typo in C++ mapping

  • Legacy Issue Number: 732
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: C++ mapping in CORBA 2.1 has a typo in the array mapping (section 18.15 page 18-33).Same typo appears in orbos/97-05-15 in section 16.12 page 16-33. It would be nice to actually show the C++ definitions for the types F, V, and M. Find details in corresponding file

  • Reported: CORBA 2.1 — Thu, 25 Sep 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in CORBA 2.2 editing process

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

CORBA::Contained::describe() underspecified

  • Legacy Issue Number: 918
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The describe() operation of the CORBA::Contained interface of the
    Interface Repository is under-specified in CORBA 2.1. (section 7.5.3
    on page 7-12). The text should add that the "kind" field of the returned
    Description struct should give the DefinitionKind for the "most derived"
    type of the object. Without this, the spec can be read as allowing
    describe() to return a kind of dk_Typedef, or even dk_all!

  • Reported: CORBA 2.1 — Sun, 25 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    incorporate the proposed clarification

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

Incorrect definition of "object type"

  • Legacy Issue Number: 917
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The definition of interface and object type in the Object Model
    are imprecise, if not incorrect. [See section 1.2.5 of the Corba 2.1
    spec (Aug 1997)]

  • Reported: CORBA 2.1 — Tue, 27 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Clarify as follows

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

Resetting #pragma prefix?

  • Legacy Issue Number: 916
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the spec doesn"t say how I can reset a repository ID prefix back to nothing
    after I have set it. Consider

    #pragma prefix "dstc.edu.au"
    interface foo {};
    #pragam prefix "" // Attempt to reset prefix
    interface bar {};

    This doesn"t work with at least one ORB I have tried.

  • Reported: CORBA 2.1 — Mon, 26 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    See resolution of issue 999 , close issue

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

Trader constraint language and international characters

  • Legacy Issue Number: 915
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the trader constraint language (page 16-98, 2.1 spec) defines a
    character class "<other>". This class is used in the definition of
    what characters may appear inside a string literal (on page 16-97).
    The problem is that the definition limits the legal character values
    that may appear in a string literal. Only character positions 0x1
    to 0x7f are legal, anything else is illegal.

  • Reported: CORBA 2.1 — Wed, 21 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Replace section B.2.3 with corresponding text from the ISO Trader standard

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

defined_in member of ModuleDescription for top-level module

  • Legacy Issue Number: 913
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What is the value member of what is returned by
    CORBA::Contained::describe when invoked on a CORBA::ModuleDef object
    corresponding to a top-level IDL module?

  • Reported: CORBA 2.1 — Wed, 21 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate change in 2.3 and close issue

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

Inheritance of Exceptions

  • Legacy Issue Number: 912
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This is a request to add an optional extension to IDL which would
    permit an exception declaration to include a specification of the
    superexception or superexceptions for a given exception, exactly the
    same way superinterfaces may be specified when defining an interface.The advantage of this extension is that it (optionally) permits
    interface designers to organize exceptions into categories, which can
    help clarify the design of the exceptions.

  • Reported: CORBA 2.1 — Thu, 22 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue, resolved

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

Question about typecode creation

  • Legacy Issue Number: 911
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Consider the following operation in the ORB pseudointerface:

    TypeCode create_union_tc (
    in RepositoryId id,
    in Identifier name,
    in TypeCode discriminator_type,
    in UnionMemberSeq members)

    Suppose that in some mapping this is invoked with the given arguments,
    i.e. an id, a name, a discriminator_type, and members..
    For concreteness, suppose that the id argument has the value
    "IDL:foo/bar:1.0".

    There are three main cases:<<Go to issue archive>>

  • Reported: CORBA 2.1 — Wed, 21 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Add clarification to section 10.6 that consistency of RepositoryIds with the IDL source or the IR i

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

#pragma processing

  • Key: CORBA22-99
  • Legacy Issue Number: 910
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 7-32, the 2.1 spec says about #pragma processing:
    An IDL compiler must either interpret these annotations
    as specified, or ignore them completely.
    I don"t think this makes sense.
    If the prefix pragma isn"t honored in one ORB, but used by another ORB,
    the repository IDs will disagree for types generated from the same
    IDL definition, but with different IDL compilers. This in turn means
    that interoperability is destroyed.

  • Reported: CORBA 2.1 — Fri, 23 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    See resolution of 999 , close issue

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

Ambiguity in non_existent() specification

  • Key: CORBA22-98
  • Legacy Issue Number: 903
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is a minor ambiguity here. Consider the case where the ORB cannot
    make a reliable determination because the client-side run-time cannot
    reach the implementation repository or the server. In that case, most
    ORBs will raise a TRANSIENT or COMM_FAILURE exception. I can read the
    above words in the spec to mean that a compliant implementation of
    non_existent is allowed to hide the exception from me and return false
    instead.
    I suggest to amend the wording such that non_existent is obliged to propagate
    any exception other than OBJECT_NOT_EXIST back to the caller.

  • Reported: CORBA 2.1 — Tue, 13 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Sugested text below , close issue

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

Appendix B lists incorrect CORBA Components IDs

  • Key: CORBA22-97
  • Legacy Issue Number: 884
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. Appendix B lists the CORBA Component IDs. This listing is
    incorrect: Proposed resolution: Change Appendix B to correspond to the
    main text.

  • Reported: CORBA 2.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Proposed resolution: Change Appendix B to correspond to the

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

union typecode (02)

  • Key: CORBA22-96
  • Legacy Issue Number: 812
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. I cannot locate where the definition of typecodes for unions with
    members with multiple labels. The natural semantics with respect to
    the member accessor operations on that typecode and the CDR
    marshalling of that typecode would seem to be that the union
    declaration is treated as if the member definition in question were
    replicated once for each label.

  • Reported: CORBA 2.1 — Tue, 23 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

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

locally constrained

  • Key: CORBA22-95
  • Legacy Issue Number: 797
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What is the consensus for the notation to use for interfaces to objects
    that are in the orb but not outside. We use to call them psuedo objects.
    During the last talk I got the feel that there are three options:

    1. //PIDL
    2. "psuedo" keyword placed before "interface"
    3. //locally constrained

  • Reported: CORBA 2.1 — Tue, 9 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

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

IDL types are ambiguous with inheritance

  • Key: CORBA22-94
  • Legacy Issue Number: 783
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What is the return type of parent(), short or long? The spec does not say whether the inherited ::y::y::z takes precedence, or whether it is ::x::z. The scope resolution rules don"t mention how to resolve such an ambiguity. The spec should be updated to state that ::x::z takes precedence (IDL example in corresponding archive "issue783")

  • Reported: CORBA 2.1 — Tue, 25 Nov 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Close noting that this has been explained in Revised Chapter 3.

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

RIDs

  • Key: CORBA22-93
  • Legacy Issue Number: 780
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The definition of IDL Repository IDs the example in the IFR chapter 7.6.6 indicates that prefixes when not set are not separated. Definition says that "typically" it is the prefix and scoped name separated with "/".

  • Reported: CORBA 2.1 — Fri, 7 Nov 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed with sepcific example in section 10.6.5.2 in Rev 2.3

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

Containers

  • Key: CORBA22-92
  • Legacy Issue Number: 779
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On the issue of making StructDef, UnionDef, and ExceptionDef inherit from container, would it be possible to introduce the depreciation of including anything other than members in these three types?

  • Reported: CORBA 2.1 — Fri, 7 Nov 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    This issue appears to be a rehash of the essence of Issue 777 so I recommend that we close this wit

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

Proposed IFR exceptions

  • Key: CORBA22-91
  • Legacy Issue Number: 778
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Proposed IFR exceptions raised by destroy() and move(): exception DependencyExists {}; raised by create_* and move(): exception RIDAlreadyDefined {}; exception NameALreadyDefined {};

  • Reported: CORBA 2.1 — Fri, 7 Nov 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate changes in 2.3a and close issue.

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

TypedefDef issue

  • Key: CORBA22-90
  • Legacy Issue Number: 777
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is it legal for a TypedefDef to contain another TypedefDef that is NOT mentioned in it"s "members" attribute? If not, should the IR spec explicitly forbid this?

  • Reported: CORBA 2.1 — Thu, 30 Oct 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved, issue closed

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

CORBA 2.1 IR Structdef typo

  • Key: CORBA22-89
  • Legacy Issue Number: 776
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: "Read Interface" section of 7.5.10: The second sentence is a typo. The StructDef as a whole can "contain" structs, unions, and enums. However, the members attribute is a CORBA IDL data type not a subtype of Container, and hence cannot "contain" anything in the sense used elsewhere in the IR spec. The sentence should be deleted

  • Reported: CORBA 2.1 — Thu, 30 Oct 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Remove the second sentence in section 8.5.10 of Rev 2.2

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

Minor bug in 2.1 spec

  • Key: CORBA22-88
  • Legacy Issue Number: 754
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The grammar mentions fixed point literals for constsnts on page 3-12. The corresponding section of the grammar on page 3-19 does not include <fixed_pt_literal> as a valid constant initializer

  • Reported: CORBA 2.1 — Tue, 21 Oct 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    incorporate changes in 2.3 and close this issue and 1066.

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

Inheriting exceptions in IDL

  • Key: CORBA22-87
  • Legacy Issue Number: 753
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When writing IDL, why is it not possible to have an exception declaration inherit from another exception? It"s possible to have an interface inherit another interface, so it seems logical to derive an exception class from an already declared exception area

  • Reported: CORBA 2.1 — Thu, 23 Oct 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue with no change with the above explanation.

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

Inclusion of standard exception

  • Key: CORBA22-86
  • Legacy Issue Number: 751
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The proposal is to define a new standard exception, called
    EXTERNAL_ACCESS (the name is not important) that carries
    an any value. Another alternative may be to re-define
    the exception COMM_FAILURE so that it may carry an any in
    addition to the existing minor and completed fields.

  • Reported: CORBA 2.1 — Mon, 6 Oct 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close no change in 2.4

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

Issue with ObjectId_to_string and string_to_ObjectId

  • Key: CORBA22-85
  • Legacy Issue Number: 749
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 18.4 "illegal characters": It should be clarified what corresponds to the concept of "illegal characters". On the othe hand, do we want to specify that ObjectIds generated by the POA should not include those "illegal characters?

  • Reported: CORBA 2.1 — Mon, 6 Oct 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

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

Bug in the 2.1.spec for IDL unions

  • Key: CORBA22-84
  • Legacy Issue Number: 727
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Table 3-11 on page 3-26 shows wchar as al legal switch type for unions. The grammar on page 3-26 doesn"t have wchar as a legal switchtype. The same is true for grammar on page 3-13. Is wchar legal for union discriminator? Spec will need to be fixed

  • Reported: CORBA 2.1 — Fri, 17 Oct 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

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

Figure 2-2 in CORBA 2.0 and CORBA 2.1

  • Key: CORBA22-83
  • Legacy Issue Number: 726
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the figure all the interfaces/skeletons/adaptors/stubs have either an Up-call or a Normal-call arrow or both with the exception of the Dynamic Skeleton which has neither

  • Reported: CORBA 2.1 — Thu, 18 Sep 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Add an Up-Call Arrow to the Dynamic skeleton box.

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

Octet and enum constants

  • Key: CORBA22-82
  • Legacy Issue Number: 725
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IDL should permit enum and octet constants.

  • Reported: CORBA 2.1 — Wed, 17 Sep 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    The following changes add enum and octet constants to IDL:

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

Non ASCII alphabetics in IDL identifiers

  • Key: CORBA22-81
  • Legacy Issue Number: 724
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IDL identifiers can contain non-ASCII alphabetic characters. None of the language maappings deals with this. To fix this restrict IDL identifiers to ASCII characters, digits and underscore

  • Reported: CORBA 2.1 — Wed, 17 Sep 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Since most of the implementation languages to which IDL is mapped do not accept non-ASCII character

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