Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — Closed Issues

  • Acronym: CORBA
  • Issues Count: 42
  • 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
CORBA21-113 RMI repository ID references to serial version UID CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-112 Second bit of response_flags CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-111 Issue: Problem with issue 2801 resolution CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-110 fragmentation broken with bi-dir giop CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-109 CODESET_INCOMPATIBLE exception CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-108 A Messaging related issue in GIOP 1.2 CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-107 IIOP 1.2 fragmentation presents an unrecoverable error situation CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-106 New IDL types CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-105 Narrow Interop CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-104 Contents of MultiComponent component an encapsulation? CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-103 Type any marshalling rules force slow implementation CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-102 Marshalling of union type codes CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-101 Typecode encoding is too long CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-100 Type code marshalling CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-99 Typecode indirection issue CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-98 No provision for numbering the fragments in fragmented IIOP messages CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-97 CDR encoding of TypeCodes CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-96 Correct CDR encoding of an empty string CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-95 Typecode equality CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-94 Wchar and Char can both be multibyte CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-93 Issue about CDR encoding for wide characters CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-92 Query about GIOP and IIOP version numbers in 98-01-03 CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-91 GIOP Exception formatting description (12.4.2) CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-90 OMG IDL prefix pragma CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-89 Description of constant expression semantics is unclear CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-88 Object terminal missing from IDL grammar CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-87 WRONG_TRANSACTION CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-86 OTS 1.1 specification changes CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-85 Interface Repository CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-31 Page 13C-36: Editorials CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-80 Bug in C++ NVList mapping CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-79 OMG C++ Mapping: Implicit Conversion Operators CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-78 Persistent Any values CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-77 DII and DSI are useless with current Any CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-76 iterating over Any primitives CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-75 decompose Any into constituent primitives CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-74 RTTI vs. _narrow for exceptions CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-73 Implementation of parameter passing for T_var types CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-72 Return value of operator[] for array var CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-71 Taking T out of T_var CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-70 Freeing inaccessible storage for T_var as out parameter CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-69 Rethrowing exceptions CPP 1.0b1 CORBA 2.1 Resolved closed

Issues Descriptions

RMI repository ID references to serial version UID

  • Legacy Issue Number: 4283
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    CORBA formal 00-11-03 10.6.2 states

    "If the actual serialization version UID for the Java class differs from
    the hash code, a colon and the actual serialization version UID
    (transcribed as a 16 digit upper-case hex string) shall be appended to
    the RepositoryId after the hash code."

    Please comment on the following assertions. The CORBA spec is vague
    here, and it has resulted in incompatible interpretations which must be
    resolved quickly.

    1) The "actual serialization version UID" mentioned is as defined in
    the Java Object Serialization specification.

    http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/class.doc6.html#4100

    Based on this Java specification and its note that "If the SUID is not
    declared for a class, the value defaults to the hash for that class":

    2) If a serialVersionUID field is defined in the class with the proper
    modifiers, its value is used as the "actual serialization version UID"
    mentioned in the CORBA spec

    3) If a serialVersionUID field with the proper modifiers is not
    explicitly defined in a class, its value is computed as explained in the
    Java Object Serialization spec, and this computed value is used as the
    "actual serialization version UID" mentioned in the CORBA spec

    4) It is required by the CORBA spec to always include the Java
    serialVersionUID (as computed in assertions 2 and 3 above) in the RMI
    repository ID if the value is different than the OMG hash code (for
    which the algorithm is defined in CORBA formal 00-11-03 10.6.2)

    5) It is not acceptable to leave off the SUID portion of the RMI
    repository ID if the serialVersionUID field is merely absent from the
    Java class

  • Reported: CORBA 2.0 — Wed, 25 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    closed, withdrawn by submitter

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Second bit of response_flags

  • Legacy Issue Number: 2968
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The question below was posted to the corba-dev list. I have to admit
    that I don't understand the purpose of the second-least significant bit
    of response_flags either. From the text in the spec, it appears that
    this bit is set if a request expects a response and is not invoked via
    the DII, whereas if a request is oneway or invoked via the DII with
    INV_NO_RESPONSE set, the bit is clear.

  • Reported: CORBA 2.0 — Tue, 2 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    closed issue ...clarified

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Issue: Problem with issue 2801 resolution

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

    Summary: > > Add the following paragraph to 15.8:
    > >
    > > "To avoid collisions of requestId in fragment messages when
    > > bi-directional GIOP is in use:
    > >
    > > - a request may not be sent by an endpoint if a reply has been
    > > sent by that endpoint without a terminating fragment.
    > >
    > > - a reply may not be sent by an endpoint if a request has been
    > > sent by that endpoint without a terminating fragment."
    > >
    >
    > Why is a plain (non-fragmented) request/reply prohibited here? There has
    > never been and feature interaction between fragmented request/replies and
    > non-fragmented ones, so why have this restriction.

    Jishnu Mukerji wrote:

    > After poking around some it seems to me that the following words address
    > Martin"s concern and hence the issue of inadvertently disallowing something
    > that wasn"t broken in the current resolution of 2801. The additional word
    > "fragmented" in two places is bracekted between "*"s.
    >
    > "To avoid collisions of requestId in fragment messages when
    > bi-directional GIOP is in use:
    >
    > - a fragmented request may not be sent by an endpoint if a
    > fragemented reply has been sent by that endpoint without a terminating
    >fragment.
    >
    > - a fragemented reply may not be sent by an endpoint if a
    > fragmented request has been sent by that endpoint without a terminating
    >fragment."

  • Reported: CORBA 2.0 — Wed, 15 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved, see below

  • Updated: Sat, 7 Mar 2015 04:35 GMT

fragmentation broken with bi-dir giop

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

    Summary: I wish to raise the following as an urgent issue:

    The way that message fragments are encoded in giop 1.2, in conjunction
    with the giop 1.2 specification for bi-directional use of a connection,
    can lead to situations where the protocol is ambiguous.

    (This is urgent because it is impossible to implement the bi-directional
    part of GIOP 1.2 without it.)

  • Reported: CORBA 2.0 — Tue, 13 Jul 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

CODESET_INCOMPATIBLE exception

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

    Summary: if a code set negotiation fails the CORBA 2.3 specfication says that a
    CODESET_INCOMPATIBLE exception is to be raised. There doesn"t seem to be
    any further reference to a CODESET_INCOMPATIBLE exception elsewhere. So
    where is the CODESET_INCOMPATIBLE exception defined? Or should it read
    INV_OBJREF?

  • Reported: CORBA 2.0 — Thu, 22 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

A Messaging related issue in GIOP 1.2

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

    Summary: Tom and I have discovered a minor outage in GIOP 1.2 relative to the
    Messaging spec. The outage exists if we want to keep the door open for
    publishing Messaging before GIOP is revved again. If we do not fix this
    the publishing of Messaging will have to wait until the next rev of
    GIOP. The outage is the following:

    1) In the Request header the boolean field "response_expected" was
    changed to an octet field "response_flags" in Messaging, with more
    precise definition of the meanings of various flag values.

    2) The Messaging spec defines a IOP::TaggedComponent for including QoS
    policies in an IOR.

    3) The Messaging service defines a ServiceContext for carrying QoS
    policies in GIOP messages that carry ServiceContexts.

  • Reported: CORBA 2.0 — Tue, 13 Oct 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Close with No change required

  • Updated: Sat, 7 Mar 2015 04:35 GMT

IIOP 1.2 fragmentation presents an unrecoverable error situation

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

    Summary: IIOP 1.2 fragmentation presents an unrecoverable error situation
    1.2 IIOP attempted to provide fragment interleaving by defining a 1.2
    fragment header containing request id. This does not solve the
    possibility of receiving multiple first fragments over the same
    connection which do not contain request id"s. There is no way to
    associate subsequent fragments with these initial fragments since the
    initial request id is received after the 1.2 Fragment header specified
    request_id.

  • Reported: CORBA 2.0 — Mon, 24 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

New IDL types

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

    Summary: When the new IDL types were added (fixed, long double, etc), no new
    IIOP or GIOP version was introduced, and no new version of CDR was introduced.
    Instead, the marshaling rules for the new types were simply added to CDR,
    and the type code interface was extended to handle these.

    Unfortunately, this creates some rather serious problems for interoperability.

  • Reported: CORBA 2.0 — Tue, 21 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Narrow Interop

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

    Summary: Narrowing is used in CORBA to check if an object reference obtained by
    a client is of the desired type, ie. supports a specific IDL interface
    that the client wants to use.

    The client program has static information about the interface it wants
    to use from the IDL specification. However, this is not enough as it
    must also be possible to invoke remote objects that support an IDL
    interface derived from the interface the client knows of.

    There are at least 4 possiblities how the type checking can be resolved
    (+ combinations of them):

    Narrow makes a query to an interface repository.
    (ii) Narrow makes a call to the remote object.
    (iii) The object reference contains enough information, e.g. the whole
    interface type hierarchy that the remote object supports.
    (iv) There is no narrow; the type check is made when a request is
    received by the server-side ORB.

  • Reported: CORBA 2.0 — Mon, 13 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Contents of MultiComponent component an encapsulation?

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

    Summary: I can"t find any text in the CORBA 2.2 spec which says explicitly
    whether the "component_data" field of IOP::TaggedComponent is actually
    an encapsulation, or something else.

    Why don"t we define a typedef "Encapsulation" for "sequence<octet>",
    and use it in the IDL for those octet sequences which are really
    encapsulations?

  • Reported: CORBA 2.0 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    :TaggedComponent is actually

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Type any marshalling rules force slow implementation

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

    Summary: type any marshalling rules force slow implementation

    Proposal: require that type any are marshalled as encapsulations

  • Reported: CORBA 2.0 — Thu, 25 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Marshalling of union type codes

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

    Summary: On page 13-14, the spec says for marshaling of type codes:

    "Note that the tuples identifying struct, exception, and enum
    members must be in the order defined in the OMG IDL definition
    text."

    This is right and proper, otherwise I wouldn"t know in what order things are
    encoded or what their ordinal values are. However, the text does not
    mention unions, so the order in which a type code describes the union
    members is left to the implementation.

    Suggestion: Require union members to also appear in the order in which
    they are defined in the IDL.

  • Reported: CORBA 2.0 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Typecode encoding is too long

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

    Summary: Proposal: allow for alternate, compact encoding of typecodes
    It is clear that typecodes are quite long when encoded into CDR and
    transmitted over the wire. This is particularly painful when the CORBA::Any
    type is used in interfaces. Besides, the use of any is becoming increasingly
    important in multiple CORBA specifications, and a global solution to this
    problem should be provided.

    My proposal is to allow for an alternate encoding of typecodes, for those
    specific cases where type identification can be achieved either by other
    application specific mechanisms (for example, Name-Value pairs) or where
    the Repository Id of the type is enough to reconstruct the full typecode
    information locally on the receiving side.

  • Reported: CORBA 2.0 — Thu, 18 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Type code marshalling

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

    Summary: If a type code does not have a repository ID

    (e.g. dynamic type ) then the member names for
    structs and unions etc. should be required to be
    sent on the wire for GIOP marsalling of Typecodes.
    This may help the type code comparision issue to be resolved.

  • Reported: CORBA 2.0 — Sun, 14 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Typecode indirection issue

  • Key: CORBA21-99
  • Legacy Issue Number: 1503
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: We have come across the following issue with regard to typecode
    indirections. The specification states:

    the indirection is a numeric octet offset within the scope of some
    "top level" TypeCode and points to the TCKind value for the
    typecode.

    The question arrises then is it legal to point to the (possible)
    padding bytes preceeding the TCKind value or must the numberic value
    indicate the position of the actual TCKind value. If you assume the
    former then having rewound the required number of bytes you would word
    align before interogating the TCKind enum value.

  • Reported: CORBA 2.0 — Thu, 4 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:
  • Updated: Sat, 7 Mar 2015 04:35 GMT

No provision for numbering the fragments in fragmented IIOP messages

  • Key: CORBA21-98
  • Legacy Issue Number: 1302
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There seems to be no provision for numbering the fragments in fragmented
    IIOP messages. It is apparently assumed that the fragments will always
    be received in the order that they are generated, however in unreliable
    networks, such as mobile networks, this may not be a safe assumption.

  • Reported: CORBA 2.0 — Fri, 1 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

CDR encoding of TypeCodes

  • Key: CORBA21-97
  • Legacy Issue Number: 1292
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I just stumbled on the following paragraph in 13.3.4 describing the CDR
    encoding of TypeCodes:

    "The name parameters in tk_objref, tk_struct, tk_union, tk_enum,
    tk_alias, and tk_except TypeCodes and the member name parameters in
    tk_struct, tk_union, tk_enum and tk_except TypeCodes are not specified
    by (or significant in) GIOP. Agents should not make assumptions about
    type equivalence based on these name values; only the structural
    information (including RepositoryId values, if provided) is significant.
    If provided, the strings should be the simple, unscoped names supplied
    in the OMG IDL definition text. If omitted, they are encoded as empty
    strings."

    This would suggest that the name and member name parts of a typecode
    should never be considered significant when an ORB compares typecodes.

  • Reported: CORBA 2.0 — Mon, 30 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:
  • Updated: Sat, 7 Mar 2015 04:35 GMT

Correct CDR encoding of an empty string

  • Key: CORBA21-96
  • Legacy Issue Number: 1138
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What is the correct encoding for an empty string according to GIOP?

    In section 13.3.2, page 13-11 of CORBA 2.2, the following paragraph
    describes the encoding of strings:

    "A string is encoded as an unsigned long indicating the length of the string
    in octets, followed by the string value in single- or multi-byte form
    represented as a sequence of octets. Both the string length and contents
    include a terminating null."

    This does not clarify what is the correct encoding for empty strings,
    as there are two possibilities:
    a) length=0, no string follows
    b) length=1, "\0" (one-char with the terminating null)

  • Reported: CORBA 2.0 — Wed, 15 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Typecode equality

  • Key: CORBA21-95
  • Legacy Issue Number: 1136
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I just stumbled on the following paragraph in 13.3.4 describing the CDR
    encoding of TypeCodes:

    "The name parameters in tk_objref, tk_struct, tk_union, tk_enum,
    tk_alias, and tk_except TypeCodes and the member name parameters in
    tk_struct, tk_union, tk_enum and tk_except TypeCodes are not specified
    by (or significant in) GIOP. Agents should not make assumptions about
    type equivalence based on these name values; only the structural
    information (including RepositoryId values, if provided) is significant.
    If provided, the strings should be the simple, unscoped names supplied
    in the OMG IDL definition text. If omitted, they are encoded as empty
    strings."

    This would suggest that the name and member name parts of a typecode
    should never be considered significant when an ORB compares typecodes.

    Of course, this still leaves the issue of what to do about aliases up in
    the air.

  • Reported: CORBA 2.0 — Sun, 29 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:
  • Updated: Sat, 7 Mar 2015 04:35 GMT

Wchar and Char can both be multibyte

  • Key: CORBA21-94
  • Legacy Issue Number: 1111
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: With regard to the character encoding issue.

    This is not just a problem with Wchar, and Wstring, it can happen
    with char and string as well. Multibyte encodings are used for
    normal strings in the enhanced IDL as well as for
    Wchars.
    I think the problem is in the definition of char. For interop, the char type could be either:
    1) restricted to a syntactic thing which can only be used with single byte encodings, or
    2) we need to bite the bullet and make the encoding for char a sequence
    of bytes if a multibyte encoding is chosen.

  • Reported: CORBA 2.0 — Wed, 25 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Issue about CDR encoding for wide characters

  • Key: CORBA21-93
  • Legacy Issue Number: 1096
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. When encoding a wchar, always put 4 bytes into the CDR stream,
    > adding any zero pad bytes as necessary to make the value 4 bytes
    > long.
    2. When encoding a wstring, always encode the length as the total
    > number of bytes used by the encoded value, regardless of whether the
    > encoding is byte-oriented or not.

  • Reported: CORBA 2.0 — Tue, 24 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Query about GIOP and IIOP version numbers in 98-01-03

  • Key: CORBA21-92
  • Legacy Issue Number: 960
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"ve been reading through 98-01-03.pdf (Change pages from Interop 1.2
    RTF), and come across a problem concerning version numbers.

    On page 13-39, the following paragraph has been added:

    "The version number published in the Tag Internet IIOP Profile body
    signals the highest GIOP minor version number that the server supports
    at the time of publication of the IOR"

    As far as I can see, the only version information in the profile body is
    "iiop_version", which has the following note in its description:

    "Note - This value is not equivalent to the GIOP version number
    specified in GIOP message headers. Transport-specific elements of the
    IIOP specification may change independantly from the GIOP specification"

    Which is correct?

  • Reported: CORBA 2.0 — Thu, 5 Feb 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

GIOP Exception formatting description (12.4.2)

  • Key: CORBA21-91
  • Legacy Issue Number: 935
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA 2.1"s GIOP Exception formatting description (12.4.2)
    partitions the space of valid minor codes, with
    20 bits reserved for unique vendor IDs and only 12 bits
    (4096) for possible minor codes for each exception.
    This seems backwards (1 million vendors each with
    only 4 thousand minor codes!) and I would like
    to request a change to (at least) swap these
    numbers with the following textual change:

    The high order 10 bits of minor_code_value contain a 10-bit
    "vendor minor codeset ID" (VMCID); the low order 22 bits
    contain a minor code. A vendor (or group of vendors)
    wishing to define a specific set of system exception
    minor codes should obtain a unique VMCID from the OMG, and
    then define up to (22 bits of) 4194304 minor codes for each
    system exception. Any vendor....

  • Reported: CORBA 2.0 — Mon, 2 Feb 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

OMG IDL prefix pragma

  • Key: CORBA21-90
  • Legacy Issue Number: 566
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: All standard OMG IDL including the CORE and all services have implicit #pragma prefix "omg.org". Make sure this appears intext of ALL IDL that is specified, particular in CORBAServices

  • Reported: CORBA 2.0 — Thu, 22 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    closed issue

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

Description of constant expression semantics is unclear

  • Key: CORBA21-89
  • Legacy Issue Number: 564
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:

  • Reported: CORBA 2.0 — Thu, 1 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved, closed issue

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

Object terminal missing from IDL grammar

  • Key: CORBA21-88
  • Legacy Issue Number: 563
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Given the current IDL grammar, there is no way to parse any IDL containing the keyword "Object". It never appears in the grammar as a terminal symbol.

  • Reported: CORBA 2.0 — Thu, 1 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved, closed in "97

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

WRONG_TRANSACTION

  • Key: CORBA21-87
  • Legacy Issue Number: 557
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: OTS 1.1 spec (page 10-17 and 10-18) is not clear whether the WRONG_TRANSACTION exception is intended to be a system exception or a user exception

  • Reported: CORBA 2.0 — Mon, 28 Apr 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    issue resolved, see revised text

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

OTS 1.1 specification changes

  • Key: CORBA21-86
  • Legacy Issue Number: 556
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: OTS 1.1 spec doesn"t clearly say which module defines the TRANSACTION_REQUIRED, TRANSACTION_ROLLEDBACK, INVALID_TRANSACTION WRONG_TRANSACTION exceptions.

  • Reported: CORBA 2.0 — Mon, 28 Apr 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved close issue

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

Interface Repository

  • Key: CORBA21-85
  • Legacy Issue Number: 542
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the Interface Repository spec, StructDef,UnionDef, and ExceptionDef should be derived from Container,since types can be defined within structs,unions,and exceptions according to IDL gram

  • Reported: CORBA 2.0 — Tue, 15 Apr 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved, close issue

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

Page 13C-36: Editorials

  • Key: CORBA21-31
  • Legacy Issue Number: 711
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The typpedef enum at top of page should be called CORBA_CompletionStatus, not CORBA_ExceptionType. Second line 4th paragraph, text should refer to table 13-5, not 3-5

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    closed with issue 901-2 revision text

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

Bug in C++ NVList mapping

  • Key: CORBA21-80
  • Legacy Issue Number: 501
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: NVList has an item () operation, which returns a NamedValue reference. The same special memory management rules should apply to item().

  • Reported: CORBA 2.0 — Thu, 20 Feb 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by portability submission

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

OMG C++ Mapping: Implicit Conversion Operators

  • Key: CORBA21-79
  • Legacy Issue Number: 484
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I propose that public interface of _var types, the similar "smart pointer" types used in struct fields, and "smart pointer" types returned from sequence index operators be extended. (see file)

  • Reported: CPP 1.0b1 — Thu, 30 Jan 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

Persistent Any values

  • Key: CORBA21-78
  • Legacy Issue Number: 480
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It"s currently not possible for a C++ client or server to receive a parameter value of type Any, store that value in filesystem or a database and later reconstruct Any value from persistent represe

  • Reported: CPP 1.0b1 — Wed, 22 Jan 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by portability submission

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

DII and DSI are useless with current Any

  • Key: CORBA21-77
  • Legacy Issue Number: 479
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Cannot use DII to invoke an operation that expects or returns a complex user-defined type. Any needs to provide member functions for composing Any"s containing arbitrary user-defined values

  • Reported: CPP 1.0b1 — Wed, 22 Jan 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

iterating over Any primitives

  • Key: CORBA21-76
  • Legacy Issue Number: 254
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There hsould be a way to access an unknown type inside an Any by "iterating" over the Any to examine the type in terms of the primitive types that make it up.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

decompose Any into constituent primitives

  • Key: CORBA21-75
  • Legacy Issue Number: 251
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Here is an extremely simple extension to the any type to allow decomposition of values to their constituent parts: <EXAMPLE issue251>

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

RTTI vs. _narrow for exceptions

  • Key: CORBA21-74
  • Legacy Issue Number: 244
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Since RTTI is not ubiquitous, the _narrow operations for Exceptions should be defined, even when RTTI available. They are trivial to implement using RTTI.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

Implementation of parameter passing for T_var types

  • Key: CORBA21-73
  • Legacy Issue Number: 239
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: Implementation of parameter passing using T_var types

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

Return value of operator[] for array var

  • Key: CORBA21-72
  • Legacy Issue Number: 220
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.12 Pg 16-27 CORBA2.o Why are we returning a Long * from operator[] rather than an LongArray_slice&?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

Taking T out of T_var

  • Key: CORBA21-71
  • Legacy Issue Number: 205
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Sec 16.8.1 Pg 16-14 CORBA2.0 p31, Section 3.10.1 para 14: If I have T_var referring to T. How can I take ownership?How to stop it from being deallocated when T_var goes out of scope?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

Freeing inaccessible storage for T_var as out parameter

  • Key: CORBA21-70
  • Legacy Issue Number: 187
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Standard requires that a conforming implementation must free the inaccessable storage associated with a parameter passed as a managed type(T_var). How to achieve it for out parameters??

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

Rethrowing exceptions

  • Key: CORBA21-69
  • Legacy Issue Number: 144
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If all I want to do is rethrow an exception in my C++ client code, there is no convenient and compliant way. It would be useful to add extra members to allow this.

  • Reported: CPP 1.0b1 — Tue, 1 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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