${taskforce.name} Avatar
  1. OMG Task Force

CORBA CORE RTF — Closed Issues

Open 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-97 CDR encoding of TypeCodes 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-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-91 GIOP Exception formatting description (12.4.2) 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-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-84 CORBA::Bounds and CORBA::TypeCode::Bounds CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-83 3.10.3 Raises Expressions CORBA 1.2 CORBA 2.0 Duplicate or Merged closed
CORBA21-82 Do simple/anonymous types have repository IDs? CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-81 Exception as explicit parameter CORBA 1.2 CORBA 2.0 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-69 Rethrowing exceptions 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-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-68 IDL grammar CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-67 8.1 Role of the Basic Object Adapter Para 1 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-66 7.4 ORB Initialization Last Paragraph - objection CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-65 7.4 ORB Initialization Last Paragraph - objection CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-64 7.2.5 Probing for Object Non-Existence Paragraph 2 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-63 7.2.4 Equivalence Checking Operation Paragraph 3 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-62 7.2.1 Determining the Object Implementation and Interface CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-61 7.1 Converting Object References to Strings Para 3 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-60 6.5.6 Repository Paragraph 4 - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-59 6.5.4 Container Last Paragraph - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-58 6.4.3 Interface Objects Paragraph 2 - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-57 6.4.3 Interface Objects Paragrapg 1 - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-56 6.3.1 Managing Interface Repositories CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-55 5.3.2 Registering Dynamic Implementation Routines Para 1- comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-54 5.2 Explicit Request State: ServerRequest Pseudo Object CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-53 4.6.5 delete_values Paragraph 1 - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-52 4.3.3 get_response CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-51 4.2.3 invoke CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-50 4.1.2 Memory usage, Para 1, editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-49 4.1 Overview, Paragraph 3, editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-48 3.15.2 Object Non-Existence, Para 1, editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-47 3.10.3 Raises Expressions CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-46 3.9 Exception Declaration CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-45 2.5 Structure of an Object Adapter CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-44 2.1 Structure of an Object Request Broker CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-43 1.2.2 Requests Paragraph last - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-42 CORBA2.0, 1.2.2 Paragraph 2 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-41 Scope of standard exceptions CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-40 Unions with enum as discriminator type CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-39 _is_a with CORBA::Object as input parameter CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-38 Unqualified names in scopes CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-37 Usage of standard exceptions CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-36 Ambiguity in DII and DSI CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-35 Request reuse CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-34 Whether unions carry exact discriminant information CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-33 Recusive Type Definitions CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-31 Page 13C-36: Editorials CORBA 2.0 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

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

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

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

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

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

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

CORBA::Bounds and CORBA::TypeCode::Bounds

  • Key: CORBA21-84
  • Legacy Issue Number: 457
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Does Bounds have data members or not? At what scope should Bounds be defined? Given that Bounds exception is also used by Request interface, I suspect what is meant is CORBA::Bounds

  • Reported: CORBA 1.2 — Wed, 13 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    no change to spec., close issue

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

3.10.3 Raises Expressions

  • Key: CORBA21-83
  • Legacy Issue Number: 390
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It would make iDL definition of an interface much more complete if they were permitted. X/Open would like OMG to consider permitting listing of Standard Exceptions in raises clauses.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.0
  • Disposition Summary:

    Duplicate of issue # 389...closed

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

Do simple/anonymous types have repository IDs?

  • Key: CORBA21-82
  • Legacy Issue Number: 137
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Do simple types like "long" have specified repository IDs? ("IDL:CORBA/long:1.0") How about anonymous types, like "sequence <long, 10>"?

  • Reported: CORBA 1.2 — Thu, 26 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    clarified, close issue

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

Exception as explicit parameter

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

    Summary: Is it permissible to declare an exception as an explicit parameter?

  • Reported: CORBA 1.2 — Sun, 18 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 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

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

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

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

IDL grammar

  • Key: CORBA21-68
  • Legacy Issue Number: 458
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is an inconsistency between the IDL grammar as defined in chapter 3 of CORBA2.0 spec and an IDL example from same chapter(Example p. 3-16..rule 71 and rule 36 specify different

  • Reported: CORBA 1.2 — Thu, 5 Dec 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

8.1 Role of the Basic Object Adapter Para 1 - comment

  • Key: CORBA21-67
  • Legacy Issue Number: 455
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Last sentence: Seems like an odd thing to say. All X/Open specs only guarantee that they are correct if system is configured correctly. Not a big deal

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

7.4 ORB Initialization Last Paragraph - objection

  • Key: CORBA21-66
  • Legacy Issue Number: 454
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Unacceptable to say that "calling the ORB_init function multiple times for the same ORB may be required where an ORB is implemented as a shared library."

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    defer to portability

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

7.4 ORB Initialization Last Paragraph - objection

  • Key: CORBA21-65
  • Legacy Issue Number: 453
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: X/Open would like to see either the provision for a system default ORB or an interface that application could use to get list of available ORBs from which to choose.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    No change to the specification. The existing spec supports a default ORB

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

7.2.5 Probing for Object Non-Existence Paragraph 2 - comment

  • Key: CORBA21-64
  • Legacy Issue Number: 452
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para describes implementation strategies that ORB implementors might use to ensure ORBS remain synchronized about presence of objects.Info really appropriate for this spec?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    no change required, close issue

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

7.2.4 Equivalence Checking Operation Paragraph 3 - comment

  • Key: CORBA21-63
  • Legacy Issue Number: 451
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Concept of "type safe narrow" isn"t really described. What"s it"s importance, announcement mechanism, and whether it can be portably relied on by programmers. Where"s more info in spec??

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

7.2.1 Determining the Object Implementation and Interface

  • Key: CORBA21-62
  • Legacy Issue Number: 450
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para 1-comment: These interfaces are very important parts of ORB interface. Their semantics are very unclear. What exceptions are they permitted to raise? Expand on this definition.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

7.1 Converting Object References to Strings Para 3 - comment

  • Key: CORBA21-61
  • Legacy Issue Number: 449
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: it"s not clear from this whether the string generated by object_to_string is portable accross ORBs or among clients. Please add text clarifying portability of generated string.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

6.5.6 Repository Paragraph 4 - editorial

  • Key: CORBA21-60
  • Legacy Issue Number: 436
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The mention of the kind attribute should be bold-face

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

6.5.4 Container Last Paragraph - editorial

  • Key: CORBA21-59
  • Legacy Issue Number: 433
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The trailing period is missing.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    changed, close issue

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

6.4.3 Interface Objects Paragraph 2 - editorial

  • Key: CORBA21-58
  • Legacy Issue Number: 419
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Change "...not by modify..." to "...not by modifying..."

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

6.4.3 Interface Objects Paragrapg 1 - editorial

  • Key: CORBA21-57
  • Legacy Issue Number: 418
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Numbered bullet list following this para is formatted poorly. Text items should be alligned and offset from the numbers in a consistent way

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

6.3.1 Managing Interface Repositories

  • Key: CORBA21-56
  • Legacy Issue Number: 417
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Paragraph 1 - editorial: Change the reference to "get_interface" to the appropriate type-face

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

5.3.2 Registering Dynamic Implementation Routines Para 1- comment

  • Key: CORBA21-55
  • Legacy Issue Number: 411
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Paragraph starts off by explaining that previous versions of CORBA weren"t complete. Not necessary to belabor this point. It"s not clear whether or not this lack has been repaired.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    This is fixed by the new DSI text from the Portability FP

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

5.2 Explicit Request State: ServerRequest Pseudo Object

  • Key: CORBA21-54
  • Legacy Issue Number: 410
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para 4: editorial Change "..OMG IDL for operation.." to "..OMG IDL for the operation...:.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

4.6.5 delete_values Paragraph 1 - editorial

  • Key: CORBA21-53
  • Legacy Issue Number: 407
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Change "value(s) values" to "value(s)

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

4.3.3 get_response

  • Key: CORBA21-52
  • Legacy Issue Number: 401
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para 0 - editorial: Add a line containing ");" to the PIDL for get_response, to match the PIDL given in section 4.2.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

4.2.3 invoke

  • Key: CORBA21-51
  • Legacy Issue Number: 398
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Paragraph 1 - editorial : The leading "c" in create_request is not boldface

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

4.1.2 Memory usage, Para 1, editorial

  • Key: CORBA21-50
  • Legacy Issue Number: 394
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is an extra space between the table reference "Table 21" and the period

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

4.1 Overview, Paragraph 3, editorial

  • Key: CORBA21-49
  • Legacy Issue Number: 392
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Dynamic Invocation Interface is a proper name, and should be capitalized and italicized

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

3.15.2 Object Non-Existence, Para 1, editorial

  • Key: CORBA21-48
  • Legacy Issue Number: 391
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Change "This standard system exception" to "The OBJECT_NOT_EXIST exception", to make explicit which exception is being discussed

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

3.10.3 Raises Expressions

  • Key: CORBA21-47
  • Legacy Issue Number: 389
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para last, comment: We understand why standard exceptions may not be listed on a raises expression, but it would make IDL definition of interface more complete if permitted.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

3.9 Exception Declaration

  • Key: CORBA21-46
  • Legacy Issue Number: 388
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para 2, editorial: Change "...(as specified by the <member> in its declaration." to "...(as specified by the <member> in its declaration)."

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

2.5 Structure of an Object Adapter

  • Key: CORBA21-45
  • Legacy Issue Number: 387
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Paragraph 2, editorial: Change " registration of implementations" to "Registration of implementations"

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

2.1 Structure of an Object Request Broker

  • Key: CORBA21-44
  • Legacy Issue Number: 386
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Paragraph 1, editorial: Change "....up the "request." to "....up the request."

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

1.2.2 Requests Paragraph last - editorial

  • Key: CORBA21-43
  • Legacy Issue Number: 385
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Change "Descriptions of the values and exceptions...." to "For descriptions of the values and exceptions..."

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

CORBA2.0, 1.2.2 Paragraph 2 - comment

  • Key: CORBA21-42
  • Legacy Issue Number: 384
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para points to C Language Binding chapter and the DII for info on dynamic invocation of objects. It implies that DII is only available in C. Text should pobably be more clear

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

Scope of standard exceptions

  • Key: CORBA21-41
  • Legacy Issue Number: 132
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 3-35 doesn"t really say that the list of standard exceptions belong to the CORBA module, although 3.12 seems to clarify.

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

Unions with enum as discriminator type

  • Key: CORBA21-40
  • Legacy Issue Number: 130
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: How is it possible in IDL to specify a union with an enum discriminator type?

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    no change necessary, close issue

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

_is_a with CORBA::Object as input parameter

  • Key: CORBA21-39
  • Legacy Issue Number: 127
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What should _is_a() return when invoking it with an input parameter designating CORBA::Object?

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    closed with revised text

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

Unqualified names in scopes

  • Key: CORBA21-38
  • Legacy Issue Number: 117
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA says "Once an unqualified name is used in a scope, it cannot be redefined", but my IDL compiler allows it. Is it legal?

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    no change to spec., close issue

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

Usage of standard exceptions

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

    Summary: Is there a difference between standard/system exception? Can an implementation raise both? Is raising a standard exception the recommended way to handle errors while setting an attribute?

  • Reported: CORBA 1.2 — Fri, 6 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

Ambiguity in DII and DSI

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

    Summary: For the DII, what value if any can be placed into the Any in the NamedValue corresponding to an OUT parameter? Must it be NULL, or is it legal to include a storage pointer? Also for DSI.

  • Reported: CORBA 1.2 — Thu, 22 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

Request reuse

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

    Summary: Can a Request pseudo object be invoked multiple times?

  • Reported: CORBA 1.2 — Tue, 20 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

Whether unions carry exact discriminant information

  • Key: CORBA21-34
  • Legacy Issue Number: 66
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It is uncertain whether or not the explicit value used to discriminate between various arms of a union is information which is required to be supported.

  • Reported: CORBA 1.2 — Mon, 5 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

Recusive Type Definitions

  • Key: CORBA21-33
  • Legacy Issue Number: 1
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What does "semantically constrained" mean in section 3.8.2 under the discussion of recursive type specifications.

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    closed issue, resolved

  • Updated: Fri, 6 Mar 2015 20:58 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