Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — Closed Issues

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

Issues Descriptions

question re BiDir IIOP

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

    Summary: I am having difficulty understanding the intended use of
    BiDirPolicy::BidirectionalPolicy. This is described (in section 15.9) as
    a POA policy to be passed to create_POA. That section also says that
    both client and server must have the policy with the value of BOTH for
    bi-directional communication to take place.

    My problem is that I don"t see how this policy applies to a particular
    POA. Once bi-directional communication has been negotiated on a
    connection, it applies to any request targetted at the negotiated
    address(es), regardless of what POA is the recipient of the request. Nor
    is it tied to the lifetime of a particular POA. And, what is supposed to
    happen if one POA has the policy with value BOTH, and another POA has
    the policy with value NORMAL?

  • Reported: CORBA 2.2 — Fri, 19 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    :BidirectionalPolicy. This is described (in section 15.9) as

  • Updated: Wed, 11 Mar 2015 04:29 GMT

Query Service IDL code

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

    Summary: The Query Service IDL code (document 97-12-18) has multiple syntax
    errors. I have checked it with Orbix, OrbixWeb and Visibroker IDl
    compiler.

  • Reported: CORBA 2.3 — Thu, 25 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 04:16 GMT

TypeCode constants for bounded strings?

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

    Summary: CORBA 2.2 has the following sentences near the beginning of section
    8.7.2:

    In the case of an unnamed, bounded string type used directly in an
    operation or attribute declaration, a TypeCode constant named
    TC_string_n, where n is the bound of the string is produced. (For
    example, "string<4> op1();" produces the constant "TC_string_4".)

    CORBA 2.3 is missing these sentences.

  • Reported: CORBA 2.2 — Mon, 28 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 15:27 GMT

DynValue::get_members/set_members

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

    Summary: The final draft (ptc/98-10-16 - from 15-Nov-98) defines
    DynValue::get_members/set_members as:


    struct NameValueAccess

    { FieldName id; Visibility access; any value }

    ;

    typedef sequence<NameValueAccess> NameValueAccessSeq

    NameValueAccessSeq get_members();
    void set_members(in NameValueAccessSeq values) raises (InvalidSeq),

    and goes on to say "Any attempt to set or get a member which has been
    declared private in the IDL definition of the value contained in the
    dynamic any raises the exception NO_PERMISSION."

  • Reported: CORBA 2.2 — Thu, 10 Dec 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    :get_members/set_members as:

  • Updated: Sun, 8 Mar 2015 15:26 GMT

The insert_dyn_any and get_dyn_any operations are barely documented

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

    Summary: 1) The insert_dyn_any and get_dyn_any operations are barely documented. It
    seems the only explanation is given on 9-15: "The get_dyn_any and
    insert_dyn_any operations are provided to deal with any values that contain
    another any." The insert_dyn_any function should be specified as behaving
    identically to insert_any, except that it allows an any in the form of a
    DynAny to be inserted. The get_dyn_any should be specified as behaving
    identically to get_any, except that it returns its result in the form of a
    DynAny rather than an any.

  • Reported: CORBA 2.3 — Tue, 20 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    "The get_dyn_any and

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

Null Value semantics under specified

  • Legacy Issue Number: 2817
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    he description of null value semantics (in ptc/99-03-07) is insufficient to ensure an adequate mapping to an
    implementation language. Issues that should be specified include: - Creation. How are null values created? Are all declared (but
    uninitialized) values born null? Is this a language mapping requirement or allowance? - Invocation. Presumably invoking an
    operation ON a null value should result in an exception. But, what exception? Shouldn't the exception be specified for application
    portability? - Passing. Presumably, it is allowable to provide a null value as the actual parameter for a non member operation (i.e.,
    not on itself). True? - Typing: are null values typed, untyped, or is this governed by the language mapping? - Substitutability (see
    "typing" above): – Presumably: a null value may be successfully widened to a null value of an ancestor stateful value type. True?
    – Can a null value be successfully widened to a (null) supporting concrete interface? (Can a null value be activated as a servant?)
    – Can a null value be successfully widened to a (null) supporting abstract interface? – Can a null value be successfully widened
    to a (null) ancestor abstract value type? The only mentions of null values currently are: - the bullet in 5.2 - 5.2.4.2

  • Reported: CORBA 2.3 — Wed, 21 Jul 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    close issue, no change

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

DynFactory or DynAnyFactory?

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

    Summary: Page 9-10 of the new DynAny draft says that you pass "DynFactory" to
    resolve_initial_references() to get a DynAnyFactory. The third comment on
    page 9-2, however, says the string should be "DynAnyFactory". I believe the
    latter is correct.

  • Reported: CORBA 2.3 — Tue, 20 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    No Data Available

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

is_abstract parameter missing from create_interface() IDL

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

    Summary: I noticed the IDL for Container in ptc/98-12-04, page 10-59 is missing
    is_abstract parameter in create_interface() operation.
    The instance on page 10-16 does include it.

  • Reported: CORBA 2.3 — Thu, 8 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    No Data Available

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

Need clarification on GIOP::TargetAddress

  • Legacy Issue Number: 2940
  • Status: closed  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    Something seems unclear to me about how to interpret a RequestHeader_1_2
    when the AddressingDisposition of the TargetAddress is ReferenceAddr:

    In the case the request contains a full IOR, which may have several
    profiles. Since each profile has its own object_key, and there is no
    requirement that they all be the same, the key for the operation may
    depend on which profile chosen.

    The client had to choose some profile in order to send the request, but
    that information is not included in the request. So apparently the
    server must decide on its own which profile it would like to use. This
    may not be the same one the client chose.

    What if any requirements are there on how this is done?

  • Reported: CORBA 2.3 — Wed, 22 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    withdrawn by submitter...issue closed

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

profile ids & component ids

  • Legacy Issue Number: 2904
  • Status: closed  
  • Source: Real-Time Innovations ( Dave Stringer)
  • Summary:

    Section 15.7.3 includes TAG_INTERNET_IOP and TAG_MULTIPLE_COMPONENTS
    in the list of tagged component ids when they are tagged profile ids.

  • Reported: CORBA 2.3 — Tue, 28 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    editorial change to CORBA 3.0 resolved

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