Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA34-320 Proxified object references CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-318 Clarification is needed on the passing of credentials CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-319 Reusing PASSTHRU CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-321 How to obtain initial reference to the GIOPProxy object CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-311 TcPdu User and Provider interfaces CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-313 Why one to one association between a TcPduUser and TcPduProvider interface? CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-312 Specification Translation from ASN to IDL issue CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-316 Traversal algorithm not sufficient CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-317 Problems with routing and/or traversal of firewalls. CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-314 When does a multiassociation TcUse know that it has been finished with? CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-315 Use of InvokeId as the type name for both invoke id and link id. CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-306 Use of PolicyType id CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-309 Allow GIOP 1.3 messages to be transported. CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-307 Missing definition on security tags in the SIOP CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-308 There is currently no valuetype support in SIOP. CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-310 use of the SSN number in the 1988 TCAP version CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-222 Correction of CORBA specification (page 18-51) CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-219 CosConsurrencyControl service bug or not? CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-180 Issue: CSIv2 Identity Assertion CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-181 Polymorphic Valuetypes and the DII CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-182 DynValue & custom valuetypes CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-183 Custom Value Marshaling Issue CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA24-203 What should an ORB do when it does not find any profile in an IOR CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-202 Standard System Exception minor codes missing in Chapter 13 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-201 Component ids in 13.6.2.2 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-198 IDL constant declarations CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-197 Conflict between POA & Exceptions spec for OBJECT_NOT_EXIST CORBA 2.3.1 CORBA 2.4.2 Closed; No Change closed
CORBA24-192 Typo: "Wrongpolicy" CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-191 destroy on POA CORBA 2.3.1 CORBA 2.4 Duplicate or Merged closed
CORBA24-190 Valuetype "copying" semantics underspecified? CORBA 2.3.1 CORBA 2.4 Duplicate or Merged closed
CORBA24-189 Scope of inherited valuetype initializers CORBA 2.3.1 CORBA 2.4 Duplicate or Merged closed
CORBA24-188 Null valuetypes not supported by DynValue CORBA 2.3.1 CORBA 2.4 Duplicate or Merged closed
CORBA25-55 International Strings in Encapsulations CORBA 2.3.1 CORBA 2.5 Resolved closed
CORBA24-178 Typo: "Wrongpolicy" CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-177 Minor typo CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-176 Section 4.3.7.1 get_client_policy? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-175 Typo on page 7-9 of 2.3.1 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-174 BAD_QOS system exception CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-173 attributes and system exceptions CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-172 why was is_abstract added to structs in CORBA IR? CORBA 2.3.1 CORBA 2.4 Resolved closed
ZIOP-78 Components Issues - Chapter 69 ptc/99-10-04 CORBA 2.3.1 ZIOP 1.0 Resolved closed
ZIOP-71 CCM Issue: Basic Level doesn't mention homes CORBA 2.3.1 ZIOP 1.0 Resolved closed
CORBA26-87 Length of wstring in GIOP 1.1 CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-86 padding at the end of a non-fragmented 1.2 request message CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-85 Interop, 15.7.3 unclear wording CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-12 CCM Issue: CIDL Syntax doesn't allow for modules CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA3-5 Implementing proper handling of CloseConnection CORBA 2.3.1 CORBA 3.0.2 Resolved closed
CORBA24-144 Table 13-1 needs update for valuetypes & abstract interfaces CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-143 marshalling of null values unclear CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-142 CDR Encapsulation Issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-141 Minor code allocation inconsistency CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-120 Should Components::Enumeration be an IDL interface or an IDL abstract value CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-119 CCM Issue: Is a home needed? CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-118 Components Issues - Interface Repository ptc/99-10-03 CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-117 Components Issues - Chapter 61 ptc/99-10-04 CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-116 implementing import for C++ CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-104 Nested Recursive Structs Legal in 2.3.x? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-103 incomplete rules for forward declaration of structs/unions CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-107 read_fixed() and write_fixed() methods missing CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-106 Initializers and user exceptions CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-105 IDL: Clashes with inherited identifiers CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-112 Should POA spec examples use string_to_ObjectId? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-111 Values for CORBA::ARG_IN,... not defined CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-110 module IOP_N needs a real name CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-109 "omg.org" prefix missing from interceptor specification and its reference CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-108 ORB ID accessor CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-85 ValueMemberDef section omitted from CORBA 2.3.1 spec CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-84 Inheritance description incorrect CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-83 ORB mediation for servant managers, references for servant managers? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-92 Policy Management in the ORB core CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-91 Some problems CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-90 ORB shutdown vs destroy CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-102 With reference to forward declarations of structs and unions. CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-101 There is inconsistency in the POA.IDL and description in section 11.3.8.19 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-100 description of unknown_adapter CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-99 reference_to_servant raises ObjectNotActive, WrongAdapter, and WrongPolicy CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-98 Missing exception for activation CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-97 AbstractBase not declared. CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-82 POA deactivate_object description is ambiguous CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-81 how are valid ORBids determined CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-80 POA namespace and ORB ID CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-94 servant_to_id versus servant_to_reference CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-93 ORB::shutdown underspecified CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-87 Incorrect use of negative fixed scale CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-86 is_equivalent and policies CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-89 POA servant_to_id inconsistent with servant_to_reference CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-88 Valuetypes with multiple interfaces CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-96 Pragma version 2.3 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-95 Non-escaped keywords in published IDL CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-79 return type of TypeCode::fixed_scale() CORBA 2.3.1 CORBA 2.4 Closed; No Change closed
CORBA24-78 POA status during destruction is unclear CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-77 Problem with valuetype parameter copying CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-64 Ordering issues in the DII CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-63 Efficient construction of Any types w/o DynamicAny CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-68 Does a value in a valuebox make sense? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-67 Semantics for DynAny::equal underspecified CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-73 Definition of COMPLETED_NO needs to be clarified CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-72 Minor glitch about forward declared things CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-70 Editorial mistake in IDL chapter CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-69 Can native be used in constructed IDL types? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-76 response_flags in interop draft CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-75 symbolic constants for minor exception codes CORBA 2.3.1 CORBA 2.4 Closed; No Change closed
CORBA24-66 Inheritence table 3-10 wrong? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-65 poll_response() CORBA 2.3.1 CORBA 2.4 Closed; No Change closed
CORBA24-71 #pragma rules are too restrictive CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-74 valuetype factory inheritence? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-62 special-casing TypeCode is unnecessary CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-51 Errors in published IDL for CORBA module CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-50 Non-standard system exceptions CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-49 Use of Principal in GIOP Module erroneous CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-56 valuebox and DynAny CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-55 OMG wchar <-> COM WCHAR in CORBA 2.3 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-61 local interfaces and the DII CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-60 servant_to_id CORBA 2.3.1 CORBA 2.4 Closed; No Change closed
CORBA24-54 What is the TypeCode for ValueBase? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-53 Do valueboxes have factories? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-52 DynAny & abstract interfaces don't mix! CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-48 create_POA and inactive state? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-47 value type substitutability CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-46 OMG IDL Syntax and Semantics issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-45 TypeCode issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-59 IDL scoping rules CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-57 null & void TCs and DynAny CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-58 Bug in 11.3.7.6 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-37 Problem with the "Special scoping" rules in 3.15.3 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-36 Meaningless sentence on page 3-11? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-32 Type Code Section issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-31 Minor codes for Standard System Exceptions in Chapter 8 missing CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-30 Minor codes for Standard System Exceptions in Chapter 5 missing CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-34 IDL and C++ relationship CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-33 PIDL vs Local CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-40 Missing "abstract" in forward declaration CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-39 The algorithm for TypeCode::equivalent in 10.7.1 was not updated CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-44 Editorial glitch in DynAny::destroy, section 9.2.3.6 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-43 What is the NO_RESPONSE exception good for? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-29 General Exception Question CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-28 Exception section issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-42 Section 7.6: IDL context housecleaning CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-41 Question about IDL \uxxxx escape format CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-35 Preprocessing of IDL CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-38 Codeset conversions and unions CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-17 Use of incomplete recursive TypeCodes underspecified CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-16 Semantics of DynAny with alias TypeCodes CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-15 URLs interact poorly with code set selection CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-23 Problem with text of POAManager::deactivate() CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-22 CORBA 2.3 spec hasn't been updated with corrections in COM-CORBA Part B CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-19 creation of arguments to TypeCode creation ops CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-27 CORBA 2.3 Editorial issue for TypeCodes & abstract_interface CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-26 Editorial issue for CORBA 2.3, 1.3.8.20 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-14 Why are Standard Exceptions defined in IDL chapter? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-13 What is the RepId of Object? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-21 formal/99-08-01.txt missing pragmas CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-20 CORBA::ORB::RequestSeq definition obsolete CORBA 2.3.1 CORBA 2.4 Resolved closed

Issues Descriptions

Proxified object references

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

    Summary: Proxified object references obtained by invoking
    new_target() should not be passed between ORBs. Instead the original IOR
    containing the target and firewall information should be passed. The reason
    for this is that the IOR does not contain enough information to inform the
    second ORB whether or not it is a reference for a NORMAL or PASSTHRU
    connection, or whether it is a proxified reference at all. This issue is
    very tightly related to issue 2, so we will describe how it fails for each
    of the possible solutions to the PASSTHRU establishment problem outlined in
    issue 2.
    One solution for which this is not an issue is the solution
    of using a port per target. However, this is not a viable solution because
    it is restrictive and will fail under moderate load. For solution 1 we
    don"t have a problem because no object reference is returned by
    set_target(), therefore it cannot be passed to other ORBs. For solution 2
    we have a problem because the second ORB won"t know whether it is supposed
    to first invoke start_passthru() or simply start making requests. Therefore
    it may get a connection type that it wasn"t expecting. For solution 3 we
    have a problem because once the original connection has been made, the
    reference is invalid. This occurs because the firewall does not have
    knowledge of how many clients are expected to try to connect to that target,
    and it may attempt to claim that port for reuse before another client has
    connected.

    Proposed Solution:
    The passing of object references obtained by invoking
    new_target() should be expressly prohibited by the specification. One
    example is, "The object reference returned by new_target() may not be passed
    to another client. Instead the original reference that was passed as the
    argument to new_target() must be passed to the second client, and the second
    client will follow the rules of the traversal algorithm to reach the desired
    target."

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Clarification is needed on the passing of credentials

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

    Summary: Description:
    Clarification is needed on the passing of credentials.
    Section 4.7.3 states that "Since all proxies will have access to the IOR of
    the target object, and the certificate of the client, they can judge whether
    this client may use a pass-through connection or not." Section 4.12 states
    that "When a client establishes a normal connection to a target via a
    trusted proxy and uses a secure transport (e.g. IIOP/SSL), in order to
    achieve end-to-end authentication, the proxy will have to forward the
    client"s certificate/identity to the server." Section 4.12 implies that the
    ForwardedIdentity service context will only be used when using a secure
    transport, but section 4.7.3 implies that the client certificate will always
    be available. In fact, the ForwardedIdentity service context should only be
    used in the case of a NORMAL connection using a secure transport because
    those are the only conditions under which there is a notion of trust between
    a requestor and the recipient of that request. This means that the only
    mechanism upon which to base a decision of whether or not to allow a
    PASSTHRU connection is the source host address/port.

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Reusing PASSTHRU

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

    Summary: Description:
    Reusing PASSTHRU connections by the firewall should be
    expressly disallowed by the specification. With the current wording of the
    specification, a vendor may attempt to reuse PASSTHRU connections. While
    this will work in some cases, it is not interoperable because there are
    cases when reusing PASSTHRU connections will not work. For example,
    connection reuse when SSL is in use will not work because all of the
    information that distinguishes data streams is contained within the
    encrypted portion of SSL packets. If two SSL connections try to share a
    single connection, there will be an SSL protocol failure because the server
    will not be able to separate the data streams before it processes the SSL
    packet.

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

How to obtain initial reference to the GIOPProxy object

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

    Summary: Description:
    The specification does not outline a specific method by
    which to obtain the initial reference to the GIOPProxy object. We believe
    that an interoperable solution for obtaining this initial reference is
    needed in order to insure that all implementations will be able to be
    correctly configured to contact all other implementations.

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

TcPdu User and Provider interfaces

  • Legacy Issue Number: 2919
  • Status: closed  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    As the interfaces currently stand, there is a minimum of 5 CORBA calls
    per transaction
    1. either TcPduProvider::get_dialog_id
    or TcPduProviderFactory::create_tc_pdu_provider
    2. TcPduProvider::invoke_req
    3. TcPduProvider::begin_req
    4. TcPduUser::end_ind
    5. TcPduUser::result_l_ind

    Given that a CORBA call is about 1 millisecond on average,
    this makes for a highly inefficient interface from a high-performance
    perspective,
    and renders the distribution of these interfaces undesirable, and the
    use of the TcPduProvider/User interfaces unlikely in a real system.

    Ideally this should be reduced to a minimum of 2 CORBA calls, one for a call
    going out, and one for the reply.

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

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Why one to one association between a TcPduUser and TcPduProvider interface?

  • Legacy Issue Number: 2917
  • Status: closed  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    There is an assumption in the design that there is a one to one
    association between a TcPduUser and a TcPduProvider
    during a TC Session. This is enforced in the IDL through the
    call

    TcPduProvider::get_dialog_id()

    and the factory call

    TcPduProvider create_tc_pdu_provider(
    in TcPduUser user,
    out DialogId d_id)
    raises(NoMoreDialogs);

    Since the TcPduUser reference (or some sort of reference)
    is not passed over in get_dialog_id(), the only conclusion
    is that the reference has to be the one passed over in the
    create, and therefore that each TcPduProvider is tied to
    one and only one TcPduUser.

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

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Specification Translation from ASN to IDL issue

  • Legacy Issue Number: 2918
  • Status: closed  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    The Specification Translation from ASN to IDL does not appear to
    require that each OPERATION carries a NoMoreAssociations exception.

    This is necessary if the use of DialogFlowCtr can implicitly create a new
    association during a call on an object that supports multiple associations.

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

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Traversal algorithm not sufficient

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

    Summary: Description:
    There may be some network topologies where the traversal
    algorithm is not sufficient for a firewall to find a server. This is due to
    an unstated assumption that all addresses within the outermost inbound
    firewall are addressable from the outermost inbound firewall. Consider for
    example the following topology:

    -----*Firewall
    B*-----Network B
    Internet -----Firewall A---------
    -----*Firewall
    C*-----Network C

    Service Network (DMZ)

    Assume that the addresses on the service network are
    globally routable addresses, Network B uses RFC 1597 addresses and Network C
    uses RFC 1597 addresses. This topology could be possible, say for a
    government agency that has sub-agencies that share some resources (service
    network) but maintain separately administrated networks. In this case the
    outermost inbound firewall for a server on Network B or C is Firewall A.
    However, when new target is invoked on Firewall A, it won"t know from the
    host address whether to open a connection to Firewall B or Firewall C.

    Proposed Solution:
    There are several possible solutions to this problem:
    1) Explicitly state the assumption described in the
    description section
    2) Mandate that implementations allow for the
    configuration of the next inbound firewalls
    3) Mandate that servers on Network B or C in such
    configurations use Firewall B or C as the outermost inbound firewall.

    There may be other solutions to this problem. These were
    the ones that immediately presented themselves.

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Problems with routing and/or traversal of firewalls.

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

    Summary: Issues 7-9 refer to problems with routing and/or traversal of firewalls.
    These problems arise due to a lack of required information about firewall
    topology in the IOR. Most of these problems could be eliminated if it were
    required that the servers place the entire chain of server-side firewalls
    that must be traversed into the IOR. Specifically, the first paragraph in
    section 4.8 should be modified so that the entire chain of firewalls is
    always required, or those situations in which it should be required should
    be stated. Some of those situations are outlined in the following issues.
    Specifically, it is incorrect to state that "strictly it is only necessary
    to convey information on the outermost inbound firewall."

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

When does a multiassociation TcUse know that it has been finished with?

  • Legacy Issue Number: 2916
  • Status: closed  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    The creation of a TcUser interface with multiple associations does not have
    a standardised way for destruction.

    Proposed solutions

    1. Add a destroy() method to TcUser
    2. Explicitly state in the RFP that the CosLifeCycle::destroy() method should
    be called once the object is no longer required.

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

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Use of InvokeId as the type name for both invoke id and link id.

  • Legacy Issue Number: 2915
  • Status: closed  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    The idl is

    struct TcLinkedContext

    { DialogFlowCtr ctr; InvokeId ivk_id; InvokeId lnk_id; AssociationId a_id; }

    ;

    While it is correct that these are both of the same type, the name of the type
    could be confusing.

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

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Use of PolicyType id

  • Legacy Issue Number: 3363
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    While editing the changes from the Firewall RTF into Core Chapter 15 I noticed a
    curious thing in the Firewall RTF report. It seems that the RTF chose to re-use
    a PolicyType id for a new and different policy while obsoleting a published one.
    The PolicyType Id in question is 37, which used to be BIDIRECTIONAL_POLICY_TYPE
    associated with the structure BiDirPolicy::BidirectionalPolicy

    and is now proposed to be BIDIRECTIONAL_INVOKE_POLICY associated with structure
    BiDirPolicy::InvokeMode.

    This appears to me to be a dangerous practice, since the fact that the published
    standard may have been implemented by someone using the obsolete definition.

    I would like to suggest that the recommendation of the Firewall RTF be modified
    leaving the published policy type and policy as is with a note stating that it
    is obsolete, and a new policy type id be allocated for
    BIDIRECTIONAL_INVOKE_POLICY.

  • Reported: CORBA 2.3.1 — Fri, 25 Feb 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Allow GIOP 1.3 messages to be transported.

  • Legacy Issue Number: 3184
  • Status: closed  
  • Source: Siemens AG ( Nils Fischbeck)
  • Summary:

    Align SIOP definition with GIOP 1.3 of CORBA2.3.1.

    Problem: SIOP is currently defined to carry GIOP messages with version 1.2
    and lower.

    Proposed Solution: Allow GIOP 1.3 messages to be transported.

  • Reported: CORBA 2.3.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Missing definition on security tags in the SIOP

  • Legacy Issue Number: 3314
  • Status: closed  
  • Source: Dublin City University ( Robert Brennan)
  • Summary:

    There are security tags mentioned in the SIOP
    document but no definition of how to use them is ever given.

  • Reported: CORBA 2.3.1 — Thu, 10 Feb 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

There is currently no valuetype support in SIOP.

  • Legacy Issue Number: 3313
  • Status: closed  
  • Source: Dublin City University ( Robert Brennan)
  • Summary:
  • Reported: CORBA 2.3.1 — Thu, 10 Feb 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

use of the SSN number in the 1988 TCAP version

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

    As far as I can see when using the 1988 TCAP version the submission
    does not seems to handle the case where the subsystem number (SSN) is
    used to seperate between several TC-User protcols per GT (typically
    protocols from different vendors). The naming tree proposed for the
    1988 TCAP protocol can only store one TC-User protocol per GT, that is
    only one DefAc per GT can be stored (see section 4.3.1.1 in the
    proposal).

    The use of the SSN number for this purpose is explained in chapter
    4.2.3 in the second paragraph in the ITU Recommendation Q.775.

    It should be easy to fix this as one only have to use the same naming
    tree structure proposed for the 1993 TCAP version in these cases.

  • Reported: CORBA 2.3.1 — Mon, 8 Nov 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Correction of CORBA specification (page 18-51)

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

    >You write on page 18-51:
    >In COM V2.0, interfaces can have single inheritance. However, as opposed to
    >CORBA,
    >there is a standard mechanism by which an object can have multiple interfaces
    >(without
    >an inheritance relationship between those interfaces) and by which clients can
    >query
    >for these at run-time. (It defines no common way to determine if two interface
    >references refer to the same object, or to enumerate all the interfaces
    >supported by an
    >entity.)
    >
    >It's not right, that there's no common way to determine if two interface
    >references refer to the same object. The IUnknown-Pointer of two different
    >interfaces of the same object must be the same (object identity in COM).

  • Reported: CORBA 2.3.1 — Tue, 22 Feb 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosConsurrencyControl service bug or not?

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

    I develop CosConcurrencyControl service for JacORB, but I don't
    understud from specification how client can destroy LockSet.
    When I create Object which allow concurrency access, I create LockSet.
    When I destroy this Object I must destroy LockSet, because it's garbage,
    bu no way for this does not exists.

    As solution of this problem, I add in CosConcurrencyControl.idl next
    changes:
    exception LockExists{};

    and method
    void destroy raises (LockExists);

    in interface LockSet.

    As I undestand this changes is wrong, but have you idea about desigion
    this problem.

  • Reported: CORBA 2.3.1 — Tue, 28 Mar 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Issue: CSIv2 Identity Assertion

  • Legacy Issue Number: 3907
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Issue on Document orbos/2000-08-04, CSIv2 Joint Submission

    Document: orbos/2000-08-04, CSIv2 Joint Submission
    Subject: Identity Assertion of X.501 Distinguished Name is not good enough
    Severity: Critical

    Summary:

    The Identity Token union contains a branch that is labled
    X501DistinguishedName. A single DN is insufficient to identify an entity.
    A path of X501Distinguished Names is needed instead. Also, other concerns
    about naming types are raised.

    Discussion:

    An X.501 Distinguished Name is insufficient to identify a single entity.
    The name must be accompanied by the name of its defining authority. In the
    case of public key certificates, the names certificate authority must be
    included.

    The chain of DNs in this manner must be included up to a root authority
    to have any definitive meaning.

    This approach will be consistent with the client sending a X.509
    Certificate Chain. A DN path is actually defined by the certificate chain.

    Furthermore, the DN path should only come from an authority that is
    acceptable to the server, whether it be a DN path, or an X.509
    Certificate Chain.

    The IOR should list the acceptable authorities and their name types.

    It is becoming more an more evident that we must invent GSS_NT_Export_Name
    types for X.509 Certificate Chain and X.501 DN path.

    The SAS_ContextSec structure should list, instead of the naming types,
    the naming authorities!

    We shall assume that the name types of the asserted identities shall be
    the same as the name types of listed naming authorities in the IOR.

    This is the only way this procedure can work Interoperable and without
    the client Guessing what it should do.

    Suggestions:

    An OID for an X.509 Public Key Certificate Chain shall be defined for a
    GSS Export Name, and its encoding will be a ASN1 sequence of and X.509
    certificate with the least significant certificate first.

    An OID for an X.501 Distinguished Name Path shall be defined for a GSS
    Exported Name, and its encoding shall be an ASN1 sequence of an X.501
    Distinguished Name with the least significant name first.

    To avoid having the target put a whole certificate chain in its IOR,
    a new OID shall be allocated in which its GSS Exported Name encoding is a
    X.501 DN path, but stipulates that the client should send a certificate
    chain from that named authority. This GSS Exported Name shall only be
    used in IORs and not for transmission in the Identity Token.

    typedef Security::GSS_NT_ExportedName NamingAuthority;

    struct CompoundSecMech

    { Security::AssociationOptions target_requires; IOP::TaggedComponent transport_mech; sequence<ServiceConfiguration> privilege_authorities; sequence<NamingAuthority> naming_authorities; }

    ;

  • Reported: CORBA 2.3.1 — Wed, 20 Sep 2000 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Polymorphic Valuetypes and the DII

  • Legacy Issue Number: 3674
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    Using the static invocation interfaces, it is possible to receive a
    valuetype that derives from the one declared in an operation, as long
    as a valuetype factory is known in the receiver (truncation is not the
    issue here).

    The same is not possible at the DII: When creating the request, the
    caller must indicate what type it expects, by forming a named value.
    Conceptually, the typecode in the named value should be the typecode
    of the base of all acceptable value types. However, if the ORB
    receives a derived type, it has no means of unmarshalling it - even if
    the application has knowledge about the derived type.

    What is missing is an interface to make typecodes of value types known
    to the ORB; with those, the ORB could then understand the CDR of the
    valuetype, and create a DynAny when asked to.

  • Reported: CORBA 2.3.1 — Wed, 7 Jun 2000 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

DynValue & custom valuetypes

  • Legacy Issue Number: 3459
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3.1 specification does not cover the interaction between the
    DynValue interface and custom valuetypes.

    I frankly don't see any way that the DynValue interface can possibly
    correctly handle a custom valuetype when the ORB does not have a factory
    for the type. It is theoretically possible for DynValue to properly
    work with a known custom type, but the implementation strategy could not
    be based on parsing the marshalled form of the valuetype.

    So, there are two issues that need to be addressed:

    1. Should DynValue handle custom valuetypes at all?

    2. For the set of custom valuetypes that it cannot handle, what
    exceptions should be raised by each operations?

  • Reported: CORBA 2.3.1 — Sat, 25 Mar 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Custom Value Marshaling Issue

  • Legacy Issue Number: 3097
  • Status: closed  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

    Due to the way that custom values are marshaled it is
    nearly impossible for a bridge (or other process) to
    process/forward GIOP messages which contain custom
    marshaled values (which the bridge has no compile/run-time
    knowledge of).

    The main issue is that the "alignment" of the
    custom marshaled data is unknown, other than the
    data will always start on a four byte boundry due
    to the presence of chunking.

    Should/could the value encoding format be changed to
    enforce eight byte alignment for all custom marshaled
    data (chunks)? This would allow bridges and other
    tools to process->[store]->forward messages containing
    custom values.

  • Reported: CORBA 2.3.1 — Tue, 7 Dec 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Wed, 1 Feb 2023 21:59 GMT

What should an ORB do when it does not find any profile in an IOR

  • Legacy Issue Number: 3234
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    As per the discussion in the Interop RTF meeting in Mesa, it was decided to
    split up 2457 into two parts as follows:

    Part 1: What should an ORB do when it does not find any profile in an IOR that
    it is able to use? This should usually not happen in a CORBA interoperability
    compliant ORB, but the possibility should be covered in the spec anyway.

  • Reported: CORBA 2.3.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    to close with agreed resolution

  • Updated: Sun, 8 Mar 2015 19:20 GMT

Standard System Exception minor codes missing in Chapter 13

  • Legacy Issue Number: 2961
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    Chapter 13 (formal/99-07-17) is missing specification of minor codes for many
    the standard system exceptions that are specified to be raised under various
    circumstances.

  • Reported: CORBA 2.3.1 — Tue, 26 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    correct the erroneous minor codes and add ones where missing in chaps 13 and 15. Leave the resolutio

  • Updated: Sun, 8 Mar 2015 19:20 GMT

Component ids in 13.6.2.2

  • Legacy Issue Number: 2914
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Also, 13.6.2.2 claims "ORB services are assigned component identifiers
    in a namespace that is distinct from the the profile identifiers".
    What is the significance of this statement?

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

    duplicate

  • Updated: Sun, 8 Mar 2015 19:20 GMT

IDL constant declarations

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

    Summary: the spec makes no statement as to the legality of the following constant
    definitions:

    const long C1 = 3.14;
    const short C2 = 1.0;
    const unsigned long C3 = -1;
    const char C4 = 10;
    const char C5 = 500;
    const long C6 = 999999;
    const short C7 = C6;
    const octet C8 = 1000;
    const short C9 = C5;
    const short C10 = 100 * 100 * 100;

    I"m sure that there are lots of others I haven"t thought of, but you get
    the idea...

    There are certainly lots of holes in the spec, with respect to both the
    legal types of the RHS and rules for overflow/underflow and mixed-type
    arithmetic. Looks like this will require a major cleanup...

  • Reported: CORBA 2.3.1 — Sun, 12 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 15:24 GMT

Conflict between POA & Exceptions spec for OBJECT_NOT_EXIST

  • Legacy Issue Number: 3919
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    There is a conflict between the specification of the OBJECT_NOT_EXIST
    exception and its use in the POA spec. The exception definition says
    that OBJECT_NOT_EXIST means that an object has gone away forever, and
    that clients should tidy up references to it. However, the POA spec
    requires an ORB to raise this exception in cases where the object may
    not have gone away for ever.

    In particular, 11.2.6 (in the 5 May 2.4 Draft) requires an ORB to raise
    OBJECT_NOT_EXIST if request comes in for a child POA that is not active
    and was not activated by the application's POA Activator. While this
    may mean that the object has gone away for ever, it doesn't always
    mean that. For example:

    1) If the server admin has stuffed port number allocations, a server
    may accidentally get requests for POAs that it doesn't know about.

    2) If the server has been incorrectly (re-)built one of its "static"
    child POAs might not be activate.

    3) If the server is buggy and / or its persistent state is flakey,
    it may temporarily fail to dynamically activate a child POA.

    In each case, the problem MAY be one that can be fixed, allowing the
    missing POA to reappear in a few minutes. It is therefore inappropriate
    for the ORB to be telling the client that the Object has gone away for
    ever.

    For what it is worth, I think the ORB should raise another exception,
    say OBJ_ADAPTER, in the default case. It might raise OBJECT_NOT_EXIST
    if it (somehow) tracks the lifecycle of transient and / or persistent
    POAs, or if the application code tells it the POA no longer exists.
    Note: I'm not suggesting that an ORB be required to support such things.

    The other alternative is to change the definition of OBJECT_NOT_EXIST
    to remove the implication that the object has gone away forever and
    the suggestion that clients should throw away references to the object.
    [I think that's wrong though ...]

  • Reported: CORBA 2.3.1 — Thu, 28 Sep 2000 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4.2
  • Disposition Summary:

    Close no change

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

Typo: "Wrongpolicy"

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

    Page 11-47, reference_to_servant, uses "Wrongpolicy". That should be
    "WrongPolicy".

  • Reported: CORBA 2.3.1 — Sun, 21 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Duplicate of 3634.

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

destroy on POA

  • Legacy Issue Number: 3402
  • Status: closed  
  • Source: Borland Software Corporation ( Andy Cutright)
  • Summary:

    ection 11.3.8.4 of the 2.3 spec states: "After all descendant POAs have
    been destroyed and their servants etherealized, the POA continues to
    process requests until there are no requests executing in the POA."

    does that mean new requests are rejected or that new requests for that
    POA are processed?

    also, if a parent POA is being destroyed, once a descendant has been
    destroyed, can an adapter activator be called for the descendant during
    this period? in the same paragraph, the spec says "After destruction has
    become apparent, the POA may be recreated .. via an Adapter Activator".
    should the request block, or can it be rejected?

  • Reported: CORBA 2.3.1 — Mon, 6 Mar 2000 05:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.4
  • Disposition Summary:

    closed no change

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

Valuetype "copying" semantics underspecified?

  • Legacy Issue Number: 3330
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Core issue #1: The Core should explicitly state that valuetype
    parameters are copied for collocated interface invocations.

  • Reported: CORBA 2.3.1 — Fri, 18 Feb 2000 05:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.4
  • Disposition Summary:

    Merge with issue 3364 and close this issue

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

Scope of inherited valuetype initializers

  • Legacy Issue Number: 3329
  • Status: closed  
  • Source: IONA ( Mark Spruiell)
  • Summary:

    Are the names of valuetype initializers introduced into the
    scope of a derived valuetype? I'm proposing that they are
    not introduced. The implication is that derived valuetypes
    are free to reuse the names of base type initializers.

    Proposed resolution:

    Change the last sentence of the first paragraph in 3.8.1.5:

    "The names of the initializers are part of the name scope of
    the value type, but are not part of the name scope of derived
    valuetypes."

  • Reported: CORBA 2.3.1 — Thu, 17 Feb 2000 05:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.4
  • Disposition Summary:

    Same as Issue 3305, Therefore same resolution as 3305

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

Null valuetypes not supported by DynValue

  • Legacy Issue Number: 3250
  • Status: closed  
  • Source: IONA ( Mark Spruiell)
  • Summary:

    DynValue is missing support for null valuetypes. There is no
    way to determine whether a DynValue represents a null valuetype,
    nor is there any way to dynamically construct an Any containing
    a null valuetype.

    Proposed resolution:

    Add the following operations to the DynValue interface:

    boolean is_null();
    void set_to_null();
    void set_to_value();

    And replace the description of the interface with the following text:

    The DynValue interface can represent both null and non-null
    valuetypes. For a DynValue representing a non-null valuetype, the
    DynValue's components comprise the public and private members of
    the valuetype, including those inherited from concrete base valuetypes,
    in the order of definition. A DynValue representing a null valuetype
    has no components and a current position of -1.

    boolean is_null();

    The is_null operation returns TRUE if the DynValue represents
    a null valuetype.

    void set_to_null();

    The set_to_null operation changes the representation of a DynValue
    to a null valuetype. Specifically, the current components of the DynValue
    are destroyed, component_count returns zero and the current position is
    set to -1.

    void set_to_value();

    The set_to_value operation changes the representation of a DynValue
    to a non-null valuetype. The state of the DynValue is initialized
    exactly as if create_dyn_any_from_type_code had been invoked.
    The set_to_value operation has no effect when invoked on a DynValue
    representing a non-null valuetype.

    The remaining operations of the DynValue interface have equivalent
    semantics to DynStruct. When invoked on a DynValue representing a
    null valuetype, get_members and get_members_as_dyn_any return an empty
    sequence.

  • Reported: CORBA 2.3.1 — Tue, 25 Jan 2000 05:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.4
  • Disposition Summary:

    Merge with 3135 and provide resolution as part of 3135

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

International Strings in Encapsulations

  • Key: CORBA25-55
  • Legacy Issue Number: 3221
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    It seems that the only time an international string will ever appear in an
    encapsulation
    would be a private IOR component.

    If we can keep the issue down to International strings in encapsulations
    this will
    simplify the solution.

    If anyone has an example of how any other GIOP header string could carry an
    international
    string please come forth with it quickly.

    The use of international strings in GIOP 1.1 and 1.2 is dependant on the
    asserted use
    of service context code set negotiation. In particular:
    1) if the negotiatiation is not initiated, then strings are passed
    as latin-1 only and wstrings are not allowed to be passed as parameters.
    2) If the negotiation is initated and successfully completed, the
    agreed codesets are used
    respectively for string and wstring
    3) If negotiation is initated by no comon codeset is agreed, then
    UTF-8 is the default for
    string and UTF-16 is the default for Wstring (note: the current codeset
    negotiation does not
    discuss the big endian or litte endian aspects of UTF-16).

    There is also text somewhere in GIOP stating that Encapsulations in IORs
    should be
    encoded in giop 1.0 for maximum interoperability.

    It just occured to me that disallowing international strings in IOR
    encapsulations (i.e., private
    IOR components) is equivalent to assuming that negotiation is not initiated
    for encapsulations.
    This seems to be a consistent set of semantics.

    The only problem with this interpretation, is that it does not allow
    international strings
    in IOR encapsulations.

  • Reported: CORBA 2.3.1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    closed in interop/2000-05-01

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

Typo: "Wrongpolicy"

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

    Page 11-47, reference_to_servant, uses "Wrongpolicy". That should be
    "WrongPolicy".

  • Reported: CORBA 2.3.1 — Sun, 21 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Editorial, fixed editorially in 2.4

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

Minor typo

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

    Pages 11-30 (twice), 11-31 (three times), and 11-52 (once) mention
    the OBJECT_ADAPTER exception. That's wrong – it should be OBJ_ADAPTER.

  • Reported: CORBA 2.3.1 — Thu, 18 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Editorial, fixed editorially in 2.4

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

Section 4.3.7.1 get_client_policy?

  • Legacy Issue Number: 3582
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 4.3.7.1 refers to a get_client_policy operation, but it is not
    defined anywhere in the CORBA specification.

  • Reported: CORBA 2.3.1 — Thu, 27 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    temporary bug....fixed, and issue closed

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

Typo on page 7-9 of 2.3.1

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

    Page 7-9 of 2.3.1 shows

    boolean poll_response(in Request req);

    However, on page 7-5, we have:

    boolean poll_response();

    The version on page 7-5 is the correct one because poll_response() is
    an operation on Request.

    Proposal:

    Change the signature on page 7-9 to read:

    boolean poll_response();

  • Reported: CORBA 2.3.1 — Fri, 14 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed issue...editorial

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

BAD_QOS system exception

  • Legacy Issue Number: 3337
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    This system exception is listed in the notification specification but
    does not exist in CORBA 2.3 (nor CORBA 2.0 AFAIK).

  • Reported: CORBA 2.3.1 — Mon, 21 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed issue, available in current draft

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

attributes and system exceptions

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

    The components spec permits attributes to raise user exceptions, to
    bring them in line with operations. That's a really nice idea, but
    raises yet another versioning problem. In particular, no new IDL that
    uses an attribute with a raises clause can be compiled by an older IDL
    compiler. (Simply deleting the raises clause and then compiling with
    an older compiler is risky at best – marshaling code won't in general
    expect to get a user exception in reply to accessing an attribute...)

  • Reported: CORBA 2.3.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    withdrawn by submitter

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

why was is_abstract added to structs in CORBA IR?

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

    I was wondering if anyone can explain the rationale for adding the field
    'is_abstract' to the CORBA::InterfaceDescription and
    CORBA::InterfaceDef::FullInterfaceDescription struct types in the CORBA
    2.3 Interface Repository specification. (I do know about abstract interfaces,
    I am really looking for the rationale for breaking backwards compabitility).

    Basically, a CORBA 2.3 client using stubs compiled from the latest IDL cannot
    interoperate using IIOP with the Interface Repository of a pre-CORBA 2.3 ORB,
    because virtually any client of the IR will want to obtain a
    FullInterfaceDescription from an InterfaceDef, and a pre-CORBA 2.3 ORB will
    not marshal the 'is_abstract' field for the description struct, thereby the
    CORBA 2.3 client will fail to unmarshal the struct.

  • Reported: CORBA 2.3.1 — Tue, 9 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    flagged as urgent....resolved

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

Components Issues - Chapter 69 ptc/99-10-04

  • Key: ZIOP-78
  • Legacy Issue Number: 3062
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    The following errors in the deployment chapter 69 need to be fixed as
    follows to align the IDL in the text with the final IDL published in
    Appendix A (orbos/99-08-08).

    1. In IDL on page 330, section 69.9.2 replace two occurences of
    raises InvalidLocation;
    with
    raises (InvalidLocation);
    and one occurence of
    raises UnknownImplId;
    with
    raises (UnknownImplId);
    2. In IDL on page 331, section 69.9.3 replace one occurence of
    raises InvalidLocation;
    with
    raises (InvalidLocation);
    and two occurences of
    raises InvalidAssembly;
    with
    raises (InvalidAssembly);
    3. In section 69.9.1.2 on pages 328 and 329, items 2 and 9 change
    Installation to ComponentInstallation

  • Reported: CORBA 2.3.1 — Mon, 22 Nov 1999 05:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Change text as indicated below

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

CCM Issue: Basic Level doesn't mention homes

  • Key: ZIOP-71
  • Legacy Issue Number: 3064
  • Status: closed  
  • Source: Oracle ( Dan Frantz)
  • Summary:

    There is nothing in the FTF documents about leveling with
    respect to homes. Basic CCM does not allow components to inherit from
    other components. Why is there no similar restriction for homes?

  • Reported: CORBA 2.3.1 — Thu, 2 Dec 1999 05:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    There is no basic and extended distinction for homes as there is for components.

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

Length of wstring in GIOP 1.1

  • Key: CORBA26-87
  • Legacy Issue Number: 3075
  • Status: closed  
  • Source: Fujitsu ( Masayoshi Shimamura)
  • Summary:

    I have a question about GIOP wstring encoding. Section "15.3.2.7 Strings
    and Wide Strings" in CORBA 2.3.1 says:

    For GIOP version 1.1, a wide string is encoded as an unsigned long
    indicating the length of the string in octets or unsigned integers
    (determined by the transfer syntax for wchar) followed by the
    individual wide characters. Both the string length and contents
    include a terminating null. The terminating null character for a
    wstring is also a wide character.

    In the sentence above, I believe that the "length" represents number of
    octets (in the case of byte oriented codeset) or number of unsigned
    integers (in the case of non-byte oriented codeset).

    For example,

    "abc" (ASCII code) ----> length is 4 (including one null terminate)
    L"abc" (Unicode, USC2) ----> length is 4 (including one null terminate of wchar)

    Is my understanding right?

  • Reported: CORBA 2.3.1 — Fri, 3 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above

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

padding at the end of a non-fragmented 1.2 request message

  • Key: CORBA26-86
  • Legacy Issue Number: 3014
  • Status: closed  
  • Source: AT&T ( Sai-Lai Lo)
  • Summary:

    Suppose a GIOP 1.2 request message is sent for an operation with no
    argument. In this case the request body is empty because there is no
    argument.

    Furthermore, the whole request message is non-fragmented, i.e. the
    2nd least significant bit of Flags in the request header is 0. Now if the
    request message header ends on a boundary which is not 8-byte
    aligned. Should the request message be extended with extra padding after the
    request message header to make the whole request message multiple of 8?

    I think the relevant statement is in section 15.4.1 (page 15-31):

    "For GIOP version 1.2, if the second least significant bit of Flags is 1,
    the sum the message_size value and 12 must be evenly divisible by 8"

    My intepretation of the statement is that the condition I just described
    does not meet this critera. Hence the message should not be padded to
    multiple of 8. It should just be ended with the end of the message header,
    just like previous GIOP versions.

    I'm asking for clarification on this issue because I'm seeing a different
    behaviour in another ORB implementation and would like to pre-empt any
    interoperability problem in future.

  • Reported: CORBA 2.3.1 — Tue, 9 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above

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

Interop, 15.7.3 unclear wording

  • Key: CORBA26-85
  • Legacy Issue Number: 2952
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I do have a quick question on one part and that is
    Section 15.7.3 IIOP IOR Profile Components. This first paragraph has the
    following line in it: " All these components are optional presence in the
    IIOP profile
    and cannot be dropped from an IIOP 1.1 or 1.2 IOR". Now I must admit that I
    am
    new to this CORBA thing, but is there something wrong with this sentence?
    I am not quite sure what this means and the grammar seems quite odd ("are
    optional prensence"?). Any chance someone could translate?

  • Reported: CORBA 2.3.1 — Fri, 15 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above

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

CCM Issue: CIDL Syntax doesn't allow for modules

  • Key: CORBA26-12
  • Legacy Issue Number: 3065
  • Status: closed  
  • Source: Oracle ( Dan Frantz)
  • Summary:

    The FTF draft does not allow a CIDL composition to be
    included in a module.

    Discussion: In the FTF Draft, the CIDL BNF (Section 60.3) is not yet
    tied into IDL syntax. As it stands, a composition cannot be embedded
    in a module. The draft recognizes that with the note (Section 60.4):

  • Reported: CORBA 2.3.1 — Thu, 2 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Implementing proper handling of CloseConnection

  • Key: CORBA3-5
  • Legacy Issue Number: 3076
  • Status: closed  
  • Source: ZeroC ( Marc Laukien)
  • Summary:

    The CORBA 2.3 spec says in chapter 15.7.1:

    "After receiving a CloseConnection message, an ORB must close the TCP/IP
    connection. After sending a CloseConnection, an ORB may close the TCP/IP
    connection immediately, or may delay closing the connection until it
    receives an
    indication that the other side has closed the connection. For maximum
    interoperability with ORBs using TCP implementations which do not
    properly implement orderly shutdown, an ORB may wish to only shutdown
    the sending side of the connection, and then read any incoming data
    until it receives an indication that the other side has also shutdown,
    at which point the TCP connection can be closed completely."

    Most (or all?) Unix TCP/IP implementations suffer from the problem
    described above, i.e., with most Unix TCP/IP implementations the last
    message sent is discarded if the connection is closed. The workaround,
    to shut down the sending side only, and then to read data until EOF is
    received, works fine for C++ ORBs.

    However, there is no equivalent to shutdown() in Java, so I don't see
    any way to reliably transmit the CloseConnection message from a Java ORB
    running on Unix.

    Questions:

    • Is there perhaps some other way to reliably transmit the last message
      before closing the connection, using Java running on Unix?
    • If not, doesn't this mean that IIOP's connection closure strategy is
      unimplementable in Java under most Unixes?
  • Reported: CORBA 2.3.1 — Fri, 3 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, close, no change

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

Table 13-1 needs update for valuetypes & abstract interfaces

  • Legacy Issue Number: 3128
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Table 13-1 is missing a row:

    Feature Version 1.0 Version 1.1 Version 1.2
    -----------------------------------------------------------
    Valuetypes and yes
    Abstract
    Interfaces

  • Reported: CORBA 2.3.1 — Thu, 16 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    add table row as suggested.

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

marshalling of null values unclear

  • Legacy Issue Number: 3102
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    Description: Instruction for marshalling of null values is missing (in

    ptc/99-03-07). Issues include:

    • The null_tag token is included in the grammar, but it's purpose is
      described nowhere. If this is the intended encoding of any null value,
      how are the typing semantics of values to be maintained? For example,
      which type-specific factory is to be used to create the null value to
      be
      passed to the servant? How are the truncation semantics to be
      preserved?
    • There is a statement in 15.3.4.5 that "[t]he tag value 0 is reserved
      for future use". Does this refer to null_tag? (Note that there seems to
      be
      inconsistent use of "tag" within the text.) If so, how are null values
      to be marshalled? The grammar doesn't seem to allow for zero length
      value_data.
  • Reported: CORBA 2.3.1 — Fri, 10 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    to close with revision

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

CDR Encapsulation Issue

  • Legacy Issue Number: 3096
  • Status: closed  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

    In the current 2.3 spec section 15.3.3 on Encapsulation
    states in the last paragraph:
    "Note that this gaurantees a four-octet alignment of the
    start of all encapsulated data within GIOP messages and
    nested encapsulations(2)"

    There's a foot note on the bottom of the page stating:
    (2) "Accordingly, in cases where encapsulated data holds
    data with natural alignment of greater than four
    octets, some processors may need to copy the octet
    data before removing it from the encapsulation. The
    GIOP protocol itself does not require encapsulation
    of such data"

    Here's the problem, the latest revisions have added support
    for a "[unsigned] long long" being the discriminator type
    within a union and therefore the encapsulated information
    for a tk_union TypeCode could have alignment needs of eight,
    not four.

    The footnote needs to be revised to indicate that copying
    could be necessary for some type code indirections or at
    least the sentence stating that "GIOP problem itself..."
    should be removed/revised. Of course we could try to
    remove support for "long long" discriminators....

    Some of the interoperability testing we've been doing
    indicates that all but one vendor who supports long long
    discriminator types are not doing things correctly...

  • Reported: CORBA 2.3.1 — Tue, 7 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    to close with revision

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

Minor code allocation inconsistency

  • Legacy Issue Number: 3040
  • Status: closed  
  • Source: International Business Machines ( Russell Butek)
  • Summary:

    CORBA 2.3, section 15.4.3.2 - Reply Body - states:

    "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 4096 minor codes for each system exception."

    Section 3.17 - Standard Exceptions - states:

    "Within a vendor assigned space, the assignment of values to minor codes is
    left to the vendor."

    The first dictates that minor code numbers are in the space of each
    Standard Exception. Ie, the true # of minor codes is (4096 times
    #-of-Standard-Exceptions). But the second implies that vendors can
    allocate their minor codes however they wish.

    So which is it? The first mandate (if you read it as a mandate) or the
    second freedom?

  • Reported: CORBA 2.3.1 — Fri, 12 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Take proposed resolution from Core RTF discussion in issue Archive

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

Should Components::Enumeration be an IDL interface or an IDL abstract value

  • Legacy Issue Number: 3099
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    Summary: Section 8.2.1.2 of the spec defines Components::Enumeration as an
    IDL interface, with the implication
    that it is intended as a remote type.

    Issue: It has been noted that java.util.Enumeration is usually implemented
    as a java.io.Serializable and that making
    Components::Enumeration an IDL interface would prevent this from happening
    for collections of primary keys returned
    from EJB Homes that are mapped to CCM Homes.

    Proposal: Define Components::Enumeration as an IDL abstract valuetype.

  • Reported: CORBA 2.3.1 — Wed, 8 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Define Components::Enumeration as an IDL abstract valuetype

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

CCM Issue: Is a home needed?

  • Legacy Issue Number: 3066
  • Status: closed  
  • Source: Oracle ( Dan Frantz)
  • Summary:

    Summary: The CCM FTF IDL chapter does not state whether a home must be
    declared for a component. A home must have a component, but must a
    component have a home?

  • Reported: CORBA 2.3.1 — Thu, 2 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    A component must have a home

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

Components Issues - Interface Repository ptc/99-10-03

  • Legacy Issue Number: 3063
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    The following errors in the interface repository chapter 10 need to be fixed.

    1. In IDL for interface HomeDef on Page 52 and Page 88:
    Remove the line: readonly attribute boolean is_basic;
    2. In IDL for struct HomeDescription on Page 52 and Page 88:
    Remove the line: boolean is_basic;
    3. In section 10.5.38.1 on page 53: Remove the paragraph that begins with:
    "The is_basic attribute is TRUE if this is a basic home......."

  • Reported: CORBA 2.3.1 — Mon, 22 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Since there is no basic and extended distinction for homes as there is for components, change text a

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

Components Issues - Chapter 61 ptc/99-10-04

  • Legacy Issue Number: 3060
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    The following errors in the component model chapter 61 need to be fixed as
    follows to align the IDL in the text with the final IDL published in
    Appendix A (orbos/99-08-08).
    1. In IDL on page 46, section 61.6.3 add a “;” after expected_event_type.
    2. In IDL on page 43, section 61.5.3 replace
    ConnectionList get_connections (in FeatureName name)
    raises (InvalidName);
    with
    ConnectedDescriptions get_connections (in FeatureName name)
    raises (InvalidName);
    3. In IDL on page 68, section 61.10.1.2 replace
    valuetype ConfigValue

    { FeatureName name; any value; }

    ;
    with
    valuetype ConfigValue

    { public FeatureName name; public any value; }

    ;

  • Reported: CORBA 2.3.1 — Mon, 22 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    resolved

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

implementing import for C++

  • Legacy Issue Number: 2973
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    I'm concerned that for C++, implementing "import" as currently specified in
    the Components spec will be extremely difficult.

    Imagine how you might implement this: your IDL compiler generates a C++
    header file for all imported name scopes and creates #include directives
    for these files in the C++ code generated for the main IDL file. The main
    problem is that importable name scopes are modules, interfaces, valuetypes,
    structures, unions, and exceptions. To import an exception, for example,
    the import mechanism would have to keep a dependency graph for that
    exception type and make sure that all dependencies are generated into the
    header file so the C++ compilation won't fail. This seems way too complex,
    and I don't see the value of being able to import individual structs and such.

  • Reported: CORBA 2.3.1 — Fri, 29 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Remove structure, union and exception from the list of name scopes (and repository ids) that can be

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

Nested Recursive Structs Legal in 2.3.x?

  • Legacy Issue Number: 3764
  • Status: closed  
  • Source: Perot Systems ( Bill Binko)
  • Summary:

    Given the IDL below, is the third case (labeled "Nested Recursive
    Case") legal in CORBA 2.3.x? (I understand that the answers to my questions
    may change in 2.4: I am interested in possible flaws in 2.3 at the moment).
    If it is legal, I have some concerns listed after the IDL:

    //IDL
    module recurse
    {
    //Recursive Struct: This is legal
    struct TestStruct1

    { sequence<TestStruct1> list; }

    ;
    // Nested Struct: This is legal
    struct TestStruct2 {
    struct TestStruct3

    { long threeMember; }

    twoMember;
    };
    // Nested Recursive Case: IS THIS LEGAL?
    struct One {
    struct Two

    { sequence<One> twoMember; }

    oneMember;
    };
    };

    1) If this IDL is loaded into an IFR, and the type() method of the StructDef
    for ::recurse::One::Two is called, what should happen? I can think of at
    least three interpretations of the spec (in particular, section 10.5) :

    a) type() should fail since the TypeCode for Two is not valid
    outside of the definition of One. If this is the case, what should it
    throw? (the natural result of many implementations would be MARSHAL, but
    that seems wrong)

    b) type() should succeed and should include a complete, valid
    TypeCode of the form:

    //BEGIN TYPECODE//
    Struct_tc(Two)
    MemberList
    StructMember
    twoMember,
    TypeCode: Struct_tc(One)
    MemberList
    StructMember
    oneMember,
    TypeCode: Recursive_tc("IDL:recurse/One/Two:1.0")
    //END TYPECODE//

    c) type() should succeed and should include a complete, valid
    TypeCode of the form:

    //BEGIN TYPECODE//
    Struct_tc(Two)
    MemberList
    StructMember
    twoMember,
    TypeCode: Struct_tc(One)
    MemberList
    StructMember
    oneMember,
    TypeCode: Struct_tc(Two)
    MemberList
    StructMember
    twoMember,
    TypeCode: Recursive_tc("IDL:recurse/One:1.0")
    //END TYPECODE//

    2) Similarly, what should the behavior be when the type() method on the
    generated structs (or their Helper classes in Java) are called? In
    particular, at what point is the ORB responsible for "embedding" the
    recursive TypeCode in its enclosing TypeCode as specified by section 10.7.3
    "Creating TypeCodes"?

    For example, given the following code (in Java, but applied to other
    languages):

    TypeCode recursiveTC = orb.create_recursive_tc("IDL:recurse/One:1.0");

    org.omg.CORBA.StructMember[] members = new
    org.omg.CORBA.StructMember[1];
    members[0] = new org.omg.CORBA.StructMember("twoMember",
    _orb().create_sequence_tc(0, recursiveTC), null);
    /1/ TypeCode twoType = _orb().create_struct_tc(id(), "Two", members);

    members = new org.omg.CORBA.StructMember[1];
    members[0] = new org.omg.CORBA.StructMember("oneMember", twoType,
    null);
    /2/ TypeCode oneType = _orb().create_struct_tc(id(), "One", members);

    If 1 attempted to resolve the recursive TC, it would fail.
    If 2 attempted to resolve the recursive TC, it would succeed, but would
    have to traverse all of twoType's members to see if there was a recursive TC
    in there.

    Any other thoughts on this issue would be appreciated.

  • Reported: CORBA 2.3.1 — Tue, 25 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close no change with explanation as above.

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

incomplete rules for forward declaration of structs/unions

  • Legacy Issue Number: 3751
  • Status: closed  
  • Source: ICL ( Trevor Nash)
  • Summary:

    1. The phrase "the only recursion permitted for constructed types with the exception of value types" is confusing: a) valuetypes are not constructed types b) the definition of a valuetype may indeed be recursive, but then so can interfaces - why are these not mentioned? Are you trying to say something specific with regard to valuetypes?

    2. The cross reference in the first example should be 3.10.7 not 3.10.3.

    3. Why does the second paragraph on page 3-38 insist that a forward declared definition must follow "in the same source file"? While this is sensible I do not see the point in enforcing it (there is a separate rule about repository IDs which has a bearing). I couldn't find a statement requiring completion of forward interface and valuetype declarations to compare with - I have always assumed these must be satisfied too.

  • Reported: CORBA 2.3.1 — Sat, 8 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

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

read_fixed() and write_fixed() methods missing

  • Legacy Issue Number: 3799
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • Summary:

    The org.omg.CORBA.DataInputStream and
    org.omg.CORBA.DataOutputStream do not define read_fixed() and
    write_fixed() methods. To enable custom marshalling/unmarshalling
    of the fixed data types, these methods should be added to the
    above classes.

  • Reported: CORBA 2.3.1 — Thu, 31 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue.

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

Initializers and user exceptions

  • Legacy Issue Number: 3781
  • Status: closed  
  • Source: IONA ( Mark Spruiell)
  • Summary:

    The IDL grammar does not allow valuetype initializers to be declared
    as raising user exceptions, which seems like a potentially useful thing
    to do. Was this possibility considered and rejected for some reason?

  • Reported: CORBA 2.3.1 — Wed, 9 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No won for B above so this issue is closed no change.

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

IDL: Clashes with inherited identifiers

  • Legacy Issue Number: 3768
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    Is the following IDL legal?

    interface A

    { void B(); }

    ;
    interface B : A {};

    Interface B has an inherited operation named B. Whether it is legal or
    not depends on whether the inherited operation is considered "defined"
    within interface B.

    This issue is subtly different from the discussions in issue 3525.
    Operations and attributes are more strongly "introduced" into the
    inherited interface than type declarations are, since inherited type
    declarations can be overridden, but operations and attributes cannot.

    I think the IDL specification should be clarified to state whether the
    above IDL is legal or not.

  • Reported: CORBA 2.3.1 — Mon, 31 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close no change with explanation as above.

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

Should POA spec examples use string_to_ObjectId?

  • Legacy Issue Number: 3918
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    As I understand things, string_to_ObjectId is an artifact of the
    C++ POA mapping. It certainly isn't defined in the core POA spec.
    However, some of the example code in the POA spec uses this routine.
    Is this kosher? Shouldn't the relevant examples at least have a
    cross-reference to the C++ mapping?

  • Reported: CORBA 2.3.1 — Thu, 28 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Resolve no change

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

Values for CORBA::ARG_IN,... not defined

  • Legacy Issue Number: 3905
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    This is a core issue.

    formal/99-10-07 (and orbrev/00-09-01) section 7.1.1 claims
    arg_modes is a bit mask with CORBA::ARG_IN, ... as possible values.
    The values are not defined in that document.

    The values defined in ptc/00-01-08 (IDL to Java mapping)
    section 1.19.4 do not look like bit masks:

    typedef unsigned long Flags;
    const Flags ARG_IN = 1;
    const Flags ARG_OUT = 2;
    const Flags ARG_INOUT = 3;
    const Flags CTX_RESTRICT_SCOPE = 15;

    This needs clarification (e.g., how wide is the bit mask, what
    are the values, or, if not a bit mask, a better definition).

  • Reported: CORBA 2.3.1 — Wed, 20 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

module IOP_N needs a real name

  • Legacy Issue Number: 3877
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    The interceptors specification, ptc/00-08-06, defines:

    IOP_N

    Issue: "_N" needs to be replaced with the correct version such that
    this module has a real name.

  • Reported: CORBA 2.3.1 — Tue, 19 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

"omg.org" prefix missing from interceptor specification and its reference

  • Legacy Issue Number: 3862
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    The specification, ptc/00-08-06, defines the following modules:

    Dynamic
    IOP_N
    PortableInterceptor

    These modules reference the following modules:

    CORBA
    IOP
    Messaging

    The CORBA 2.4 specification, orbrev/00-09-01, only explicitly specifies:

    #pragma prefix "omg.org"

    for:

    DynamicAny (page 196)
    CORBA, the Interface Repository Case, (p 280)
    PortableServer (page 338)

    and the Messaging specification, orbos/98-05-05, specifies the prefix
    for messaging.

    ----------

    Proposed solution:

    Either explicitly add

    #pragma prefix "omg.org"

    before Dynamic, IOP_N, PortableInterceptor, CORBA (in general), and IOP

    OR

    Change, the second paragraph of 10.6.7 RepositoryIDs for OMG-Specified Types
    (page 270)

    from:

    "All official OMG IDL files shall contain the following pragma prefix
    directive:

    #pragma prefix "omg.org"

    unless said file already contains a pragma prefix identifying the
    original source of the file (e.g., "w3c.org")."

    to:

    "All official OMG IDL modules shall contain the following pragma prefix
    directive:

    #pragma prefix "omg.org"

    unless said file already contains a pragma prefix identifying the
    original source of the module (e.g., "w3c.org")."

    ----------

    Discussion:

    Perhaps we can interpret 10.6.7 above to mean already mean the all
    official OMG modules have the "omg.org" prefix. In that case, there
    is no issue.

  • Reported: CORBA 2.3.1 — Tue, 19 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    The last sentence of the summary states the way things are, so there really is no issue here

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

ORB ID accessor

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

    ORB_init allows me to specify an ORB ID, but there is no way to get that
    ORB ID back from an ORB. It seems wrong to force people to specify an
    object identity during object creation but to not allow access to that
    identity later.

    I would suggest to add an accessor to the ORB interface:

    interface ORB

    { ORBid id(); // ... }

    ;

  • Reported: CORBA 2.3.1 — Fri, 8 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Add the proposed accessor to ORB.

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

ValueMemberDef section omitted from CORBA 2.3.1 spec

  • Key: CORBA24-85
  • Legacy Issue Number: 3560
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the CORBA 2.3.1 99-10-07.pdf spec, where "The Interface Repository
    chapter has been updated based on CORE changes from
    ptc/98-09-04 and the Object by Value documents (orbos/98-01-18 and
    ptc/98-07-06).", ValueMemberDef is not fully documented.

    ValueMemberDef should have it's own section in the Interface Repository
    chapter but it does not. This would contain it's IDL and at least two
    subsections, one for the read interface and one for the write interface.

  • Reported: CORBA 2.3.1 — Thu, 13 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Missing section should be filled in

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

Inheritance description incorrect

  • Key: CORBA24-84
  • Legacy Issue Number: 3525
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    On page 3-46, CORBA 2.3, we have some old words that got forgotten during
    the scope resolution rule cleanup we did some time ago:

    Inheritance produces shadow copies of the inherited identifiers;
    that is, it introduces names into the derived interface, but these
    names are considered to be semantically the same as the original
    definition. Two shadow copies of the same original (as results
    from the diamond shape in Figure 3-1 on page 3-21) introduce a
    single name into the derived interface and don't conflict with
    each other.

    That's wrong because it confuses visibility of an identifier with introduction
    of an identifier (which are different things). I would suggest to reword
    as follows:

    Inheritance produces shadow copies of the inherited identifiers;
    that is, inherited identifiers are visible in derived interfaces.
    Such identifiers are considered to be semantically the same as
    the original definition. Two shadow copies of the same original (as
    results from the diamond shape in Figure 3-1 on page 3-21) do
    not conflict with each other.

    This simply gets rid of the word "introduces", which has the wrong meaning.

    Note that these words have been wrong all along, even before we changed
    the name lookup rules. That's because, if inherited identifiers were
    indeed introduced into the derived interface, the following would be illegal
    (but has in fact never been illegal):

    interface B

    { typedef string S; }

    ;

    interface D : B

    { typedef long S; }

    ;

  • Reported: CORBA 2.3.1 — Fri, 31 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Fix as suggested below

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

ORB mediation for servant managers, references for servant managers?

  • Key: CORBA24-83
  • Legacy Issue Number: 3460
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Two questions:

    1) Are calls to operations on servant managers mediated by the ORB?

    2) Is it legal to export the object reference for a servant manager
    to another process?

    For question 1, the answer would appear to be no. Here is why:

    Page 11-17:

    Inactive state

    When a POA manager is in the inactive state, the associated POAs
    will reject new requests. [...] If the client is co-resident in
    the same process, the ORB could raise the OBJ_ADAPTER system
    exception, with standard minor code 1, to indicate that the
    object implementation is unavailable. [...]

    If the transition into the inactive state is a result of calling
    deactivate with an etherealize_objects parameter of

    • TRUE - the associated POAs will call etherealize for
      each active object associated with the POA once all
      currently executing requests have completed processing
      (if the POAs have the RETAIN and USE_SERVANT_MANAGER
      policies). If a servant manager has been registered for
      the POA, the POA will get rid of the object. If there
      are any queued requests that have not yet started
      executing, they will be treated as if they were new
      requests and rejected.

    If calls to servant managers were to be ORB-mediated, the calls to
    etherealize() cannot possibly be dispatched because the corresponding
    servant manager is already in the inactive state. The only logical conclusion
    I can see is that calls to servant managers are not mediated by the ORB.

    I think the spec should be updated to state this.

    For question 2, the answer would also appear to be no:

    Exporting a reference to a servant manager outside my own address space
    makes no sense whatsoever. Here a servant manager offers either
    incarnate() and etherealize(), or it offers preinvoke() and postinvoke().
    These are the only operations that are possible (apart from operations
    on Object). If it were possible to export a reference to a servant
    manager to another address space, there is nothing the receiver of
    the reference could do with it (other than call operations on Object).
    That's because incarnate(), etherialize(), and preinvoke use a native
    type (servant). postinvoke() doesn't use a native type, but
    accepts a parameter of type POA, so postinvoke cannot be invoked
    remotely either (because POA is locality constrained and its
    reference cannot be marshaled).

    So, it appears clear that export of servant manager references should be
    illegal and flagged the same way as an attempt to export a POA manager
    reference.

    The spec currently says this about servant managers:

    A ServantManager object must be local to the process containing
    the POA objects it is registered with.

    Contrast this with POA managers, for which the spec says:

    A POAManager object must not be exported to other processes,
    or externalized with ORB::object_to_string. If any attempt is
    made to do so, the offending operation will raise a MARSHAL
    system exception. An attempt to use a POAManager object with
    the DII may raise the NO_IMPLEMENT exception.

    To me, it looks like we should say the same thing for servant managers as
    for POA managers.

    And, by the same reasoning, I think it also must be said for the
    AdapterActivator interface: it doesn't make sense to marshal a reference
    for an adapter activator because the only operation (unknown_adapter) has
    an in parameter of type POA, which cannot come from a remote location.

  • Reported: CORBA 2.3.1 — Tue, 28 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Merge into Issue 4264 and close this with the resolution of 4264.

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

Policy Management in the ORB core

  • Key: CORBA24-92
  • Legacy Issue Number: 3614
  • Status: closed  
  • Source: foxfield-sw.demon.co.uk ( Nick Sharman)
  • Summary:

    (All document refs to ptc/00-03-02, but I think the relvant sections are the
    same in ptc/00-04-05)

    (a) Sec. 4.3.7.1 (Object::get_policy) says that the "effective Policy is the
    intersection of the values allowed by the effective override and the
    IOR-specified Policy." What does this mean? For example, the example
    MyPolicy given in 4.8.5 appears to define some range or interval, so the
    intersection of two MyPolicy objects has some meaning - but I doubt if it's
    reasonable to expect the ORB to deduce that.

    I suggest that the effective policy is:

    • any override of that type if there is one, else
    • any IOR-specified policy of that type if there is one, else
    • the system default of that type if there is one, else
    • the null Policy reference (or a system exception? which?).

    This is feasible and consistent with normal meaning of "override" as
    "replace", not "modify".

    (b) Sec. 4.3.7.2 (Object::get_client_policy) suggests that the ORB searches
    the object's overrides, then PolicyCurrent's overrides, then PolicyManager's
    overrides. If it can't find any in those, then it can return the system
    default. I suggest the system default be left out of this search - it's not
    an override, it's a final default - and that we define what happens if no
    policy of the right type can be found, either null or a system exception.

    (c) Sec. 4.3.8.1 (Object::set_policy_overrides) and sec. 4.9.3.1
    (PolicyManager::set_policy_overrides) both allow the existing set of
    overrides either to be replaced or to be extended.

    If the set is to be extended, and the new overrides contain a Policy of a
    type for which there is already an override, should the supplied Policy
    (1) replace the existing Policy silently, or
    (2) be ignored silently, or
    (3) cause a system exception (and which)?

    Whatever the value of 'set_add', if the supplied Policy list contains two
    Policies of the same type, which one prevails, if any? I suggest
    "implementation defined", but we could mandate a system exception.

  • Reported: CORBA 2.3.1 — Mon, 15 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

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

Some problems

  • Key: CORBA24-91
  • Legacy Issue Number: 3612
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I thought there are some error in Grammer which number are (24) and (27).
    The grammer which number is 24 in specification is
    <init_param_decls> ::= <init_param_decl>

    { "," <init_param_decl> }

    I thought it may be <init_param_decls> ::= <init_param_decl> { "," <init_param_decl> }

    *
    Can you see asterisk?

    And grammer number 27 is miss-printing.

    It is all of my question in grammer and next problem is in Preprocessing.
    User can use #include for source inclusion.
    But in case of C++, there are two kind of source inclusion. One is standard library inclusion using angle brackets.
    Another is using quotation mark.
    Is the rule adapted in IDL preprocessor?
    Could you send me a document about Preprocessing rule?

    Another question is #ifdef, #ifndef.
    Is this option able to be duplicated?

    Last question is about position of inclusion command.
    In some example in specification 2.3, I find this example.

    module M

    { #include <E.idl> }

    ;

    • from CORBA V2.3, June 1999, 10-43

    The source inclusion command - #incude - is in module block.
    How that source will be compiled and mapped?
    I thought that source is wrong....

  • Reported: CORBA 2.3.1 — Mon, 15 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close no change with explanation as above.

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

ORB shutdown vs destroy

  • Key: CORBA24-90
  • Legacy Issue Number: 3608
  • Status: closed  
  • Source: Borland Software Corporation ( Vishy Kasar)
  • Summary:

    CORBA2.3.1 section 4.11.5 destroy() has following information.

    Once an ORB is destroyed, another call to ORB_init with same ORBid will
    return a reference to a newly constructed ORB.

    My assumption here is if I call shutdown() on an ORB followed by
    ORB_init() with the same ORBid as of the shutdown ORB, I get the same
    ORB back. Essentially, we can not get rid of that ORB until destroy() is
    called. Is this a valid assumption? If so, can we add a sentence to that
    effect to shutdown() section?

  • Reported: CORBA 2.3.1 — Fri, 12 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

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

With reference to forward declarations of structs and unions.

  • Legacy Issue Number: 3749
  • Status: closed  
  • Source: ICL ( Trevor Nash)
  • Summary:

    Clause 48 <constr_type_spec> in the syntax has been modified to include a choice <constr_forward_decl>. This does not in fact allow things like struct a; though that is the obvious intention. But it does allow bizarre stuff such as typedef struct a, array_of_a[100]; which IMHO should not be legal (I am not that keen on typedef struct a b

    I think this choice should be deleted from clause 48 and inserted in clause 42 <type_dcl> instead.

  • Reported: CORBA 2.3.1 — Sat, 8 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

There is inconsistency in the POA.IDL and description in section 11.3.8.19

  • Legacy Issue Number: 3743
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • Summary:

    There is inconsistency in the POA.IDL and description in section 11.3.8.19
    in formal/99-10-07.pdf.

    According to poa.idl the signature for create_reference_with_id is:

    Object create_reference_with_id ( in ObjectId oid,
    in CORBA::RepositoryId intf )
    raises (WrongPolicy);

    whereas, section 11.3.8.19 completely omits this exception in the
    signature and does not even describe under what condition it is raised.

  • Reported: CORBA 2.3.1 — Fri, 14 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    The POA IDL should be fixed by removing the raises(WrongPolicy) clause

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

description of unknown_adapter

  • Legacy Issue Number: 3740
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • Summary:

    2. According to CORBA V2.3 spec, 99-10-07.pdf, section 11.3.3.2
    description of unknown_adapter, indicates that:
    " The implementation of this operation should either create the specified
    POA and return TRUE, or it should return FALSE. If the operation returns TRUE,
    the ORB will proceed with processing the request. If the operation returns
    FALSE,
    the ORB will return OBJECT_NOT_EXIST to the client."

    In Section 11.3.8.3, find_POA specifies the following:

    "If a child POA with the specified name does not exist and the value of
    the activate_it parameter is TRUE, the target POA's AdapterActivator,
    if one exists, is invoked, and, if it successfully activates the child POA,
    that child POA is returned. Otherwise, the AdapterNonExistent exception is
    raised."

    Since find_POA itself invokes the unknown_adapter() method on the
    AdapterActivator.
    If the unknow_adapter() returns false, the find_poa() should throw an
    OBJECT_NOT_EXIST exception. This is not very clear from explanation in
    section 11.3.8.3.

  • Reported: CORBA 2.3.1 — Wed, 5 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Clearly the current text potentially leads readers astray, so clarify it as shown below:

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

reference_to_servant raises ObjectNotActive, WrongAdapter, and WrongPolicy

  • Key: CORBA24-99
  • Legacy Issue Number: 3739
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • Summary:

    1. According to CORBA V2.3 spec, 99-10-07.pdf, section 11.3.8.22,
    reference_to_servant raises ObjectNotActive, WrongAdapter, and WrongPolicy
    exceptions.

    This is inconsistent with the method signature specified in the poa.idl (section
    11.4). According to the idl the reference_to_servant raises only
    ObjectNotActive and WrongPolicy exceptions.

    It is requested that the signature of reference_to_servant in poa.idl be changed
    to match the description in section 11.3.8.22.

  • Reported: CORBA 2.3.1 — Wed, 5 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Fix the editorial error

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

Missing exception for activation

  • Key: CORBA24-98
  • Legacy Issue Number: 3738
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    For explicit activation, the spec says:

    11.3.8.15 activate_object

    ObjectId activate_object(in Servant p_servant)
    raises (ServantAlreadyActive, WrongPolicy);

    This operation requires the SYSTEM_ID and RETAIN policy; if not
    present, the WrongPolicy exception is raised.

    And:

    11.3.8.16 activate_object_with_id

    void activate_object_with_id(
    in ObjectId oid,
    in Servant p_servant)
    raises (ObjectAlreadyActive, ServantAlreadyActive, WrongPolicy);

    This operation requires the RETAIN policy; if not present, the
    WrongPolicy exception is raised.

    Neither section says that IMPLICT_ACTIVATION would be required.

    The intent for IMPLICIT_ACTIVATION was that it permits implicit activation
    as well as explicit activation. However, I can infer this only by reading
    between the lines. In particular, in section 11.2.7, the intent is never
    made clear.

    I would suggest to change the the text in section 11.2.7 from:

    When a POA supports implicit activation, an inactive servant may
    be implicitly activated in that POA by certain operations that
    logically require an Object Id to be assigned to that servant.
    Implicit activation of...

    to read:

    When a POA supports implicit activation, an inactive servant may
    be implicitly activated in that POA by certain operations that
    logically require an Object Id to be assigned to that servant.
    (IMPLICIT_ACTIVATION does not disallow explicit activation; instead,
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    it enables both implicit and explicit activation.)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Implicit activation of...

  • Reported: CORBA 2.3.1 — Wed, 5 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    The proposed clarification is in order.

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

AbstractBase not declared.

  • Key: CORBA24-97
  • Legacy Issue Number: 3737
  • Status: closed  
  • Source: Département Informatique & Réseaux ( Thomas Quinot)
  • Summary:

    The standard IDL files included in the corba/ subdirectory
    of the IDL text files archive, formal/00-04-01, should be compilable
    with any compliant IDL parser. Most notably, these files comprise
    a "corba/orb.idl" source file, whose inclusion in application
    IDL files is necessary whenever an application has to manipulate
    type CORBA::TypeCode (as mandated by section "3.14 CORBA module"
    of the CORBA specification v. 2.3).

    It is thus expected that the file corba/orb.idl be a legal
    IDL specification.

    This is not the case, because the corba/orb.idl files #includes
    a CORBA_Stream.idl file, which contains the following declaration:

    abstract valuetype DataOutputStream

    { [...] void write_Abstract (in AbstractBase value); [...] }

    In this declaration, the syntax of the language imposes that
    the name AbstractBase be interpreted as a <scoped_name>.
    This <scoped_name> is not defined in corba/orb.idl or any of
    the files it #includes.
    The declaration is therefore illegal.

    According to the CORBA 2.3 specification, section
    "4.2 The ORB operations", module CORBA contains a declaration
    "native AbstractBase".

    The following resolution is therefore proposed for this issue:

    In file corba/orb.idl, include the followinf declaration:

    native AbstractBase; // Chapter 4

  • Reported: CORBA 2.3.1 — Tue, 4 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Declaration of native AbstractBase needs to be added to orb.idl as stated above.

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

POA deactivate_object description is ambiguous

  • Key: CORBA24-82
  • Legacy Issue Number: 3449
  • Status: closed  
  • Source: Borland Software Corporation ( Vishy Kasar)
  • Summary:

    CORBA 2.3.1 section 11.2.8.17 states that "An ObjectId which has been
    deactivated continues to process requests until there are no active
    requests for that ObjectId"

    In the short window where deactivate_object is called but object is not

    yet deactivated, the above sentence is open to interpretation. The 2
    interpretation are:

    1. Active requests are those requests that came before
    deactivate_object was called. In this case, POA continues to service
    those requests and throws OBJECT_NOT_EXIST for future requests if the
    object is not activable.

    2. Active requests are any requests. In this case, POA will continue
    to service requests that come even after deactivate_object was called
    as long as deactivation is not complete.

    So what is the intended interpretation? I suspect it is 1. If so, can we

    make this section clearly state that?

  • Reported: CORBA 2.3.1 — Thu, 23 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

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

how are valid ORBids determined

  • Key: CORBA24-81
  • Legacy Issue Number: 3443
  • Status: closed  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    Section 4.5.1 of the CORBA core document explains the ORBid argument to
    ORBinit. However, it is sufficiently vague to present implementation and
    usage problems.

    It says:

    "All ORBid strings other than the empty string are allocated
    by ORB administrators and are not managed by the OMG."

    It fails to define ORB administrator. This administrator could be the
    developer of the application calling the ORB, or it could be the
    administrator of the machine on which the ORB will run, or it could be the
    developer of the ORB itself. Each answer to this question may result in a
    different mechanism for determining if a supplied ORBid is valid.

  • Reported: CORBA 2.3.1 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate change and close issue

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

POA namespace and ORB ID

  • Key: CORBA24-80
  • Legacy Issue Number: 3441
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    Section 4.6 of CORBA 2.3.1 addresses the meaning of the ORBid argument. It is clear
    that ORB_init can be called multiple times in the same address space resulting in
    different ORBs. I think the CORBA spec should make it clear that all of these ORBs
    have different POA namespaces. This should probably be indicated in section 11.2.3
    by stating something like:

    If an application makes use of multiple ORBs in the same address space, each
    ORB defines its own separate POA namespace. In particular, each ORB returns a
    distinct root POA in response to a resolve_initial_references( "RootPOA" )
    call.

  • Reported: CORBA 2.3.1 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Clarifying sentence is justified.

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

servant_to_id versus servant_to_reference

  • Key: CORBA24-94
  • Legacy Issue Number: 3636
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    This operation requires the USE_DEFAULT_SERVANT policy or a
    combination of the RETAIN policy and either the UNIQUE_ID or
    IMPLICIT_ACTIVATION policies; if not present, the WrongPolicy
    exception is raised.

    Note that there is nothing conditional here. If these policies are not
    present, the operation raises an exception.

    Compare this with servant_to_reference:

    This operation requires the RETAIN policy and either the
    UNIQUE_ID or IMPLICIT_ACTIVATION policies if invoked outside
    the context of an operation dispatched by this POA.

    Note that, in this case, we have a qualification:

    "... if invoked outside the context of an operation..."

    Why the difference between the two? They almost do the same thing, namely,
    map from a servant to an object ID. It's just that servant_to_reference,
    after it has the object ID, also embeds that object ID in a reference.

    So, shouldn't the two operations behave the same way? In particular,
    why should servant_to_id raise an exception if I call it from within the
    context of an executing operation on the specified servant?

    In other words, it seems that the behavior specified for servant_to_reference
    is correct and should apply equally to servant_to_id. In effect, calling
    the operation from withing an executing operation on the specified servant
    should do the same thing as calling get_object_id on the POA Current and
    use the resulting id.

    Am I missing something?

  • Reported: CORBA 2.3.1 — Mon, 22 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

ORB::shutdown underspecified

  • Key: CORBA24-93
  • Legacy Issue Number: 3618
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    If I call ORB::shutdown(), it implicitly calls POA::destroy() on the
    Root POA.

    I assume that the value of the wait_for_completion parameter to
    ORB::shutdown() should be passed through to POA::destroy()? The spec isn't
    entirely clear on this point.

    Further, what is the effect of calling ORB::shutdown() on the value
    of the etherealize_objects parameter for POA::destroy()? Since ORB::shutdown()
    doesn't have an etherealize_objects parameter itself, the value passed
    through to POA::destroy must be implicit, but the spec doesn't say what
    it is.

    Similarly, ORB::destroy() implicitly calls ORB::shutdown(). From the
    second-last para on page 4-35, it would appear that this implicit call
    is made as ORB::shutdown(true) rather than ORB::shutdown(false). It
    might be nice to make this explicit so I don't have to read between the
    lines to figure it out.

  • Reported: CORBA 2.3.1 — Wed, 17 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue.

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

Incorrect use of negative fixed scale

  • Key: CORBA24-87
  • Legacy Issue Number: 3581
  • Status: closed  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    In section 3.9.2 (of ptc/99-12-07) on semantics of constants,
    an example is given showing 3000.00D being of type fixed<1,-3>.
    This is inconsistent with statements elsewhere that fixed scale is a
    non-negative quantity.

    Also, the preceding explanation states: "... leading and trailing zeros are
    factored out, INCLUDING NON-SIGNIFICANT ZEROS BEFORE THE DECIMAL POINT."
    This rule of course leads to negative scale factors, so it must also be
    incorrect.

    Suggested Revision:

    Change the following text:

    "A fixed-point literal has the apparent number of total and fractional
    digits, except leading and trailing zeros are factored out, including
    non-significant zeros before the decimal point. For example, 0123.450d is
    considered to be fixed<5,2> and 3000.00d is fixed<3,-1>."

    to:

    "A fixed-point literal has the apparent number of total and fractional
    digits, except leading zeros before the decimal point and trailing zeros
    after the decimal point are factored out. For example, 0123.450d is
    considered to be fixed<5,2> and 3000.00d is fixed<4,0>."

  • Reported: CORBA 2.3.1 — Tue, 25 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Remove the specification for stripping leading and trailing zeros, and fix the examples accordingly

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

is_equivalent and policies

  • Key: CORBA24-86
  • Legacy Issue Number: 3566
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    How should is_equivalent() behave if I compare two references that denote
    the same object at the same location, using the same profiles, etc, but
    differ in the policies? Do differences in the policies affect the outcome?

    My gut feeling is that is_equivalent() should return false in this case
    because it uses reference identity, not object identity. However, we
    are rapidly approaching the point where is_equivalent() might as well
    unconditionally return false because we are adding more and more flavours
    of additional information into IORs as time goes by. Invocation policies,
    transaction policies, codesets, multiple profiles, optional components,
    etc, etc.

    Does is_equivalent() require a more precise definition in order to remain
    useful?

  • Reported: CORBA 2.3.1 — Sat, 15 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

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

POA servant_to_id inconsistent with servant_to_reference

  • Key: CORBA24-89
  • Legacy Issue Number: 3607
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    In CORBA 2.3, servant_to_id does not work if the POA has the RETAIN,
    MULTIPLE_ID, and NO_IMPLICIT_ACTIVATION policies, even if
    servant_to_id is invoked in the context of the specified servant.
    According to 11.3.8.20, such a call raises WrongPolicy.

    Inconsistent with that specification, it is apparently still possible
    to obtain the ID for that servant, using

    id = poa.reference_to_id(poa.servant_to_reference(self))

    This works since 11.3.8.21/3 supports all cases of currently-active
    servant, not only USE_DEFAULT_SERVANT

  • Reported: CORBA 2.3.1 — Wed, 10 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Same as Issue 3636, and is fixed by the fix for 3636.

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

Valuetypes with multiple interfaces

  • Key: CORBA24-88
  • Legacy Issue Number: 3589
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    consider the following, which as valid IDL as best as I can figure out:

    interface I1 {};
    abstract valuetype V1 supports I1 {};

    interface I2 {};
    abstract valuetype V2 supports I2 {};

    interface I3 {};
    valuetype V3 : V1, V2 supports I3 {};

    The above raises some very interesting issues. For one, this can't be
    mapped into C++ for a number of reasons (largely having to do with
    ambiguous multiple inheritance). However, there much deeper issues here
    relating to the object model. Some questions:

    • What is the type of the a V3 instance?
    • What is the repository ID of that instance?
    • What is the return value of a call to _this()?
    • What is the result of invoking

    is_a("IDL:I1");
    is_a("IDL:I2");
    is_a("IDL:I3");

    on an I3 reference?

    • What are the results of I1::narrow(), I2::narrow(), and I3::narrow()
      on an I3 reference?
    • What is returned by a call to get_interface()?
    • What are the results of traversing the above in an IFR?

    There are probably more questions along these lines. They all aim at
    the fact that the above construct effectively creates an object that has
    multiple unrelated interfaces. This flies in the face of the CORBA
    type system, which fundamentally requires every object to have exactly
    one most-derived type.

    I think we need to put the axe through constructs such as the one above
    in a hurry!

  • Reported: CORBA 2.3.1 — Fri, 28 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Resolve no change with explanation as above.

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

Pragma version 2.3

  • Key: CORBA24-96
  • Legacy Issue Number: 3694
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Bill Beckwith)
  • Summary:

    Since pragma version only applies to the name given in the
    pragma and not to anything in the scope of the name this
    means that the rep id of things like Bounds and BadKind are
    still "...:1.0":

    interface TypeCode { // PIDL

    1. pragma version TypeCode 2.3
      exception Bounds {};
      exception BadKind {};

    This is just one example of many things inside version 2.3
    pragma'ed scopes that are defaulting to 1.0.

  • Reported: CORBA 2.3.1 — Fri, 9 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Non-escaped keywords in published IDL

  • Key: CORBA24-95
  • Legacy Issue Number: 3685
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I know that this is probably not the best RTF to send this to, but the
    issue spans RTFs and we don't have RTFs for the collection or the life cycle
    service, so I'm sending this to the Core RTF for want of a better task force...

    In the CosLifeCycle IDL (formal/98-10-01.idl), we have:

    module CosLifeCycle{

    typedef CosNaming::Name Key;
    typedef Object Factory;
    typedef sequence <Factory> Factories;

    The two occurences of "Factory" are illegal. According to the comment
    at the beginning of the module, this should read:

    module CosLifeCycle{

    typedef CosNaming::Name Key;
    #ifdef NO_ESCAPED_IDENTIFIERS
    typedef Object Factory;
    typedef sequence <Factory> Factories;
    #else
    typedef Object _Factory;
    typedef sequence <_Factory> Factories;
    #endif

    The same problem also appears in formal/98-10-15.idl.

    Also in formal/98-10-01.idl:

    // C o l l e c t i o n F a c t o r i e s
    interface CollectionFactories : CollectionFactory {
    boolean add_factory (
    in Istring collection_interface,
    in Istring impl_category,
    in Istring impl_interface,
    in CollectionFactory factory);

    // ...

    // R A C o l l e c t i o n F a c t o r i e s
    interface RACollectionFactories : RACollectionFactory {
    boolean add_factory (
    in Istring collection_interface,
    in Istring impl_category,
    in Istring impl_interface,
    in RACollectionFactory factory);

    Both operation definitions need the same #ifdef to map away from the
    "factory" keyword that is used as a parameter name.

    That same problem also appears in formal/98-10-03.idl.

    I guess the IDL in the formal CORBAservices documents should be fixed too.

  • Reported: CORBA 2.3.1 — Thu, 6 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Fix IDL as suggested

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

return type of TypeCode::fixed_scale()

  • Key: CORBA24-79
  • Legacy Issue Number: 3439
  • Status: closed  
  • Source: AdNovum Informatik ( Stefan Wengi)
  • Summary:

    in 10.7.1 the fixed_scale() operation is defined to return a short but
    the 'scale' value of a fixed type is defined to be a positive integer
    (in 3.4 (96)) and also in the C++ mapping.
    It seems to me there is some inconsistency here.

  • Reported: CORBA 2.3.1 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4
  • Disposition Summary:

    Close no change.

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

POA status during destruction is unclear

  • Key: CORBA24-78
  • Legacy Issue Number: 3436
  • Status: closed  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    The description of POA destroy in section 11.3.8.4 is unclear.
    There are several ways to implement this, which may result in problems
    porting application code between orbs.

    Some of the ambiguities are:

    1) It may or may not be legal for an application to create new child POAs
    while the existing children are being destroyed. This could happen
    explicitly or via AdapterActivators. Such behavior could prevent destruction
    from ever completing.

    2) If the POA's POAManager is in the holding state at the time of
    destruction (or if its state is changed to holding during the destruction
    process), it isn't clear what happens to the held requests.

    3) If the POA's POAManager is active, what happens to requests that arrive
    after the call to destroy but before the destruction becomes apparent? If
    they are to be serviced, a sufficiently rapid arrival rate may prevent the
    destruction from ever completing.

  • Reported: CORBA 2.3.1 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Clarify POA behavior during destruction as described below

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

Problem with valuetype parameter copying

  • Key: CORBA24-77
  • Legacy Issue Number: 3364
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Corba 2.3.1 section 5.2.4.3 states that valuetypes passed as parameters
    are copied when passed into the receiving context. Is this also true
    for valuetypes that are embedded in a contructed IDL type passed as a
    parameter?

    Example:

    // IDL

    valuetype V { };

    struct S

    { V a_v; }

    ;

    interface I

    { S op(in S s1, inout S s2, out S s3); }

    ;

    When I::op is called are the valuetypes embedded in s1, s2, s3 and the
    return value supposed to be copied when making a collocated call?

    Example 2:

    // IDL

    interface J

    { any op(in any a1, inout any a2, out any a3); }

    ;

    If one of the any parameters to J::op contains a valuetype, must it be
    copied before/after a collocated call? What if the any contains a
    struct S instead?

    It seems to me we need to revisit the valuetype copying issue. We have
    three choices:

    1. Valuetypes are not copied for collocated calls.
    2. Only valuetypes as explicit parameters are copied for collocated
    calls.
    3. All valuetypes are copied no matter how deeply they are nested in
    parameters.

    Currently the specification is ambiguous as to whether the semantics are
    supposed to be case 2 or 3. Case 3 is the only one that provides
    guaranteed location transparency, but the cost to implement case 3 for
    collocated calls far too high. It would effectively require the same
    overhead as marshalling/unmarshalling for any operation that has a
    valuetype embedded in a complex IDL type or any.

    So, given that transparency for collocated calls cannot be maintained
    without high overhead, should we completely remove the copying
    requirement because transparency cannot be maintained, or should we just
    document that case 2 is the accepted semantic?

  • Reported: CORBA 2.3.1 — Fri, 25 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    resolved, see below

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

Ordering issues in the DII

  • Key: CORBA24-64
  • Legacy Issue Number: 3194
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The following are currently undefined in the spec:

    • What happens if poll_response or get_response is called
      before send_deferred?
    • What happens if get_response is called after invoke?
    • What if get_response is called more than once?

    [ Interestingly, the resolution to issue 2341 resolved something,
    but it wasn't issue 2341 That's because the resolution
    doesn't say that calling get_response twise is illegal. ]

    • Is it legal to call poll_response more than once?

    I think that, for the first three, we should raise BAD_INV_ORDER. We
    also need minor codes for those.

    For case four, I'd suggest that calling poll_response multiple times is OK,
    but that calling it once get_response was called should raise BAD_INV_ORDER.

  • Reported: CORBA 2.3.1 — Tue, 11 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Fix as described above.

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

Efficient construction of Any types w/o DynamicAny

  • Key: CORBA24-63
  • Legacy Issue Number: 3185
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The current C++ mapping does not offer efficient insertion or
    extraction of data from CORBA::Any if static type information
    (IDL-generated insertion and extraction operators) are not
    available.

    I'm thinking of a dynamic DII gateway that needs to shovel large
    amounts of data, such as a sequence<octet>. Presently, the gateway
    must employ the DynAny type, and loop over the number of elements,
    calling insert_octet() or get_octet() repeatedly. This is inefficient,
    especially for large sequences/arrays of basic types.

    I think that a more efficient mechanism might be useful for some
    applications.

  • Reported: CORBA 2.3.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

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

Does a value in a valuebox make sense?

  • Key: CORBA24-68
  • Legacy Issue Number: 3220
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Although legal in the CORBA 2.3 IDL grammar, creating a valuebox of
    another valuebox or valuetype is of dubious use. I can't see why having
    an extra level of indirection here would ever be useful. None of the
    language mappings that have defined mappings for valuebox (C++, Java,
    Ada) address this issue either.

    Does it make sense to disallow valueboxing valueboxes or valuetypes?

  • Reported: CORBA 2.3.1 — Sat, 15 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue.

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

Semantics for DynAny::equal underspecified

  • Key: CORBA24-67
  • Legacy Issue Number: 3205
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    CORBA 2.3.1, 9.2.3.5 says: "Two DynAny values are equal if their
    TypeCodes are equivalent and, recursively, all component DynAnys have
    equal values."

    We already added text in the Y2K RTF to clarify equal for object
    references & typecodes, but this leaves an exercise for the reader to
    figure out what equal means for some IDL types, particularly fixed,
    sequences & valuetypes. I believe that an experienced person thinking
    about it can come up with the correct rules, but why leave it up to
    mistaken interpretation.

  • Reported: CORBA 2.3.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Resolve as suggested

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

Definition of COMPLETED_NO needs to be clarified

  • Key: CORBA24-73
  • Legacy Issue Number: 3302
  • Status: closed  
  • Source: BROKAT Informationssysteme ( Blake Biesecker)
  • Summary:

    In order to resolve the OTS RTF issue 1819, we need
    to have clearer wording regarding what COMPLETED_NO.

    Since we now have the POA, the following phrase from
    section 3.17 is not clear enough:

    COMPLETED_NO The object implementation was never initiated prior to the exception being raised

    In order to get proper rollback logic for transactions
    that get system exceptions and, I'd imagine, to get
    proper fault tolerant behavior, it needs to be made
    clear that COMPLETED_NO means that absolutely no execution
    on the server took place prior to the exception being
    raised. Without such a clarification, it is not possible
    to guarantee data integrity for fault tolerance and it
    forces the OTS to insist on a strict rollback policy when
    a system exception is raised.

    In particular, with the advent of the POA, "object implementation"
    is not as clear as it once was. Does this include servant
    locators, for example.

    As a place to start, I'd like to suggest this instead:

    COMPLETED_NO No execution was initiated in the server prior to the exception being raised

    (The archive for issue 1819 contains a lot more
    discussion on this topic as it relates to the
    OTS.)

  • Reported: CORBA 2.3.1 — Tue, 8 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close no change

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

Minor glitch about forward declared things

  • Key: CORBA24-72
  • Legacy Issue Number: 3270
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    When value types added forward declarations, and when we added forward
    declarations for structs and unions, we forgot to update the version pragma
    text. Currently, it says (page 10-45):

    Attempts to assign a prefix to a forward-declared interface
    and a different prefix to that interface later result in
    a compile-time diagnostic:

    Proposal:

    Change that sentence to read:

    Forward-declared constructs (interfaces, value types, structures,
    and unions) must have the same prefix in effect wherever they appear.
    Attempts to assign conflicting prefixes to a forward-declared
    construct result in a compile-time diagnostic. For example:

  • Reported: CORBA 2.3.1 — Fri, 4 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Add the following clarification:

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

Editorial mistake in IDL chapter

  • Key: CORBA24-70
  • Legacy Issue Number: 3268
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    On page 10-46 of the latest draft, at the end of section 10.6.5.2,
    there are three paragraphs that talk about a SoftCo printer. It looks
    like these are somewhere else in previous version and accidentally
    got moved or left behind during the edition for the chapter.
    (If that's a wrong guess, I'd like to know what they are doing there
    because they most certainly don't contribute to the content of this
    section

  • Reported: CORBA 2.3.1 — Wed, 2 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Move the text in question to a more appropriate place as suggested below

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

Can native be used in constructed IDL types?

  • Key: CORBA24-69
  • Legacy Issue Number: 3258
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    CORBA 2.3.1, section 3.10.5 says:

    "A native type may be used to define operation parameters and results.
    However, there is no requirement that values of the type be permitted in
    remote invocations, either directly or as a component of a constructed
    type."

    This is ambiguous as to whether a native type may be used in a
    constructed IDL type that is intended to be used only locally:

    // IDL

    native MyNative;

    struct MyStruct

    { MyNative a_native; }

    ;

    So, should the first sentence in 3.10.5 be read to mean that native may
    ONLY be used in parameters & results? If so, we ought to put the word
    "only" in there.

  • Reported: CORBA 2.3.1 — Wed, 26 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue.

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

response_flags in interop draft

  • Key: CORBA24-76
  • Legacy Issue Number: 3338
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    n the interop draft (ptc/00-02-04) the response_flags are defined now in terms
    of SyncScope. However, SyncScope does only apply to oneway, DII with
    INV_NO_RESPONSE, and sendc-stubs with no reply handler. The Messaging
    submission explicitly defines that it is ignored in the other cases.

    from CORBA Messaging:

    interface SyncScopePolicy

    This interface is a local object derived from CORBA::Policy. It is applied to
    oneway
    operations to indicate the synchronization scope with respect to the target of
    that
    operation request. It is ignored when any non-oneway operation is invoked. This
    policy is also applied when the DII is used with a flag of INV_NO_RESPONSE since
    the implementation of the DII is not required to consult an interface
    definition to
    determine if an operation is declared oneway. The default value of this Policy
    is not
    defined. Applications must explicitly set an ORB-level SyncScopePolicy to ensure
    portability across ORB implementations. When instances of SyncScopePolicy are
    created, a value of type Messaging::SyncScope is passed to
    CORBA::ORB::create_policy. This policy is only applicable as a client-side
    override. The client’s SyncScopePolicy is propagated within a request in the
    RequestHeader’s response_flags as described in GIOP Request Header.

  • Reported: CORBA 2.3.1 — Mon, 21 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    resolved in interop RTF

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

symbolic constants for minor exception codes

  • Key: CORBA24-75
  • Legacy Issue Number: 3319
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    in section 3.17.2, we show all the minor codes for exceptions. Unfortuantely,
    these are all magic numbers rather than symbolic constants. In turn,
    these means that I can't write portable code unless I use the magic numbers
    directly.

    It would be nice to have constant definitions for these instead, so I
    can refer to minor numbers in the code without having to resort to
    hard-wired magic numbers.

  • Reported: CORBA 2.3.1 — Wed, 16 Feb 2000 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4
  • Disposition Summary:

    Close no change.

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

Inheritence table 3-10 wrong?

  • Key: CORBA24-66
  • Legacy Issue Number: 3203
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There appears to be a minor glitch in table 3-10. It states that
    stateful valuetypes can only support one non-abstract interface, but it
    is not clear what is correct for abstract valuetypes or abstract
    interfaces, since it uses the words "supports", not "supports single" or
    "multiple" which are used elsewhere. It certainly does not appear
    reasonable for abstract valuetypes to be able to inherit from more than
    one non-abstract interface when stateful valuetypes cannot.

    This brings up a question: Can abstract valuetypes support non-abstract
    interfaces? It's not clear to me what the answer to this ought to be.

    Anyway, it appears to me that part of the table should look like this
    instead:

    May inherit from: | Interface | Abstract Interface
    ---------------------------------------------------------------------------
    Abstract | *no or supports single| multiple
    Value |
    ---------------------------------------------------------------------------
    Stateful | supports single | multiple
    Value | |
    ---------------------------------------------------------------------------

    • depending on the answer to the question above
  • Reported: CORBA 2.3.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    The table needs to be changed to clarify as shown below

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

poll_response()

  • Key: CORBA24-65
  • Legacy Issue Number: 3196
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    there really is a different issue here. On page 7-5:

    boolean poll_response();

    On page 7-9:

    boolean poll_response ( in Request req);

  • Reported: CORBA 2.3.1 — Tue, 11 Jan 2000 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4
  • Disposition Summary:

    Already fixed editorially in draft.

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

#pragma rules are too restrictive

  • Key: CORBA24-71
  • Legacy Issue Number: 3269
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I think the current rules for #pragma are too tight and we need to relax
    them. In particular, for the ID pragma (page 10-43):

    If an attempt is made to assign a repository ID to the same
    IDL construct a second time, a compile-time diagnostic shall
    be emitted, regardless of whether the second ID is in conflict or not:

    interface A {};
    #pragma ID A "IDL:A:1.1"
    #pragma ID A "IDL:X:1.1" // Compile-time error

    interface B {};
    #pragma ID B "IDL:BB:1.1"
    #pragma ID B "IDL:BB:1.1" // Compile-time error

    This causes problems with separate compilation. For example:

    // x.idl
    namespace Foo

    { // ... };
    #pragma ID Foo "IDL:blah:1.0"

    // y.idl
    namespace Foo { // ... }

    ;
    #pragma ID Foo "IDL:blah:1.0"

    // z.idl
    #include "x.idl"
    #include "y.idl"

    The same problem arises with the version pragma, because I may want to
    change the version in two different source files.

  • Reported: CORBA 2.3.1 — Fri, 4 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Clarify as suggested

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

valuetype factory inheritence?

  • Key: CORBA24-74
  • Legacy Issue Number: 3305
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3.1 Core specification is silent on the issue of whether
    factories defined for a valuetype are "inherited" into derived
    valuetypes. I assume that there is no such inheritence.

    Proposal:

    Add to the end of the first paragraph in 3.8.1.5:

    "Initializers defined in a valuetype are not inherited by derived
    valuetypes."

  • Reported: CORBA 2.3.1 — Wed, 9 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Add clarifying text as shown below:

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

special-casing TypeCode is unnecessary

  • Key: CORBA24-62
  • Legacy Issue Number: 3181
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    The resolution to issue 3048 special-cases TypeCode in a manner that
    essentially makes it a keyword. First of all, given that TypeCode lives in
    the CORBA module, and thus is properly named CORBA::TypeCode, this is
    highly irregular because it means we have a scoped keyword. Second, this
    change also significantly breaks working products – it adopts
    implementation details of certain compilers and rules out already-working
    implementation approaches of other existing compilers. The OMG is not
    supposed to dictate implementation. Finally, the rationale for the changes
    made for 3048 centered around unquantifiable performance issues that IMO
    affect only a very small minority of applications.

  • Reported: CORBA 2.3.1 — Thu, 6 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue.

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

Errors in published IDL for CORBA module

  • Key: CORBA24-51
  • Legacy Issue Number: 3105
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I found a lot of errors in the CORBA IDL text file that's on the server
    for download:
    In general, the layout of the file is a mess. Inconsistent, meaningless
    indentation, whitespace before semicolons on occasion, comments indented
    poorly, etc, etc. Wouldn't hurt to clean this up – it's quite embarrassing
    as it is now.

  • Reported: CORBA 2.3.1 — Fri, 10 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Non-standard system exceptions

  • Key: CORBA24-50
  • Legacy Issue Number: 3104
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    Section 3.17.1 says that "ORB implementations may raise non-standard system
    exceptions." This raises a number of questions:

    1. How are non-standard system exceptions defined? Are they defined using
    IDL, or are they PIDL? If they are IDL, how are they identified as
    system exceptions by the language mappings?

    2. The definitions in section 3.17.1 for standard system exceptions appear
    to be IDL, but I believe the intention is that they are PIDL. This
    should be stated clearly.

    3. Should non-standard system exceptions be defined in the CORBA module like
    the standard system exceptions? There are three choices:
    a. They must be in the CORBA module.
    b. They must not be in the CORBA nmodule.
    c. They can either be in the CORBA nodule or in other modules.

    4. Point 3 raises the more general question of whether it is legal for ORB
    vendors to add non-standard definitions to the CORBA module. Section 3.14
    says that "Names defined by the CORBA specification are in a module named
    CORBA," but it does not say whether these are the only names that may appear
    in the module named CORBA. This should be clarified.

  • Reported: CORBA 2.3.1 — Fri, 10 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    See text below for resolution

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

Use of Principal in GIOP Module erroneous

  • Key: CORBA24-49
  • Legacy Issue Number: 3095
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    In spite of objections based on misunderstandings from certain quarters
    I would like to propose that Principal in the IDL describing GIOP as
    excerpted below be replaced by "sequence <octet>". For whatever it might
    be worth, doing so would make the IDL in the GIOP module actually
    compilable for the first time in its entire existence!

    module GIOP { // IDL extended for version 1.1 and 1.2
    // GIOP 1.0
    struct RequestHeader_1_0

    { // Renamed from RequestHeader IOP::ServiceContextList service_context; unsigned long request_id; boolean response_expected; sequence <octet> object_key; string operation; Principal requesting_principal; ^^^^^^^^^ }

    ;

    // GIOP 1.1
    struct RequestHeader_1_1

    { IOP::ServiceContextList service_context; unsigned long request_id; boolean response_expected; octet reserved[3]; // Added in GIOP 1.1 sequence <octet> object_key; string operation; Principal requesting_principal; ^^^^^^^^^ }

    ;

    ...
    };

    Firstly, ever since the GIOP standard was adopted, the use of Principal
    in that struct has been erroneous, since it is undefined in GIOP module,
    unless adorned with a CORBA:: prefix. Secondly, in effect all that it is
    trying to say
    is that the Principal is represented as a sequence<octet> in the header
    field
    requesting_principal, not a Principal pseudo-interface, which is
    undefined in that context anyway. Thirdly, even if you could find a
    definition for an unadorned Principal somewhere, what is the meaning of
    that type when CDR encoded? It really is
    nothing but sequence<octet>.

    I think this issue should go to the Interop RTF.

  • Reported: CORBA 2.3.1 — Mon, 6 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed in interop/2000-01-01

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

valuebox and DynAny

  • Key: CORBA24-56
  • Legacy Issue Number: 3135
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    The DynAny chapter says absolutely nothing about value boxes. Do they
    fulfill only the base DynAny interface, or the DynValue interface, or do we
    need a new DynValueBox interface? If the DynValue interface is supposed to
    be used, do you treat the boxed value as a single member? If so, what is
    its name?

  • Reported: CORBA 2.3.1 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Following text changes address the outage raised in this issue as well as the one from issue 3250

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

OMG wchar <-> COM WCHAR in CORBA 2.3

  • Key: CORBA24-55
  • Legacy Issue Number: 3134
  • Status: closed  
  • Source: IONA ( Thomas Moriarty)
  • Summary:

    The CORBA 2.3 spec states in table 18-2 that OMG IDL wstring maps to LPWSTR
    in COM.

    This was presumably added with the introduction of CORBA support for
    wstrings. I don't see any mapping defined for OMG wchar. This would
    naturally map to COM WCHAR.

    Is this an error/omission in the 2.3 spec?

  • Reported: CORBA 2.3.1 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    OMG IDL wchar should indeed map to COM WCHAR. Add it to table 18-1

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

local interfaces and the DII

  • Key: CORBA24-61
  • Legacy Issue Number: 3177
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The current spec for local interfaces disallows making calls to a local
    interface via the DII. It turns out that this is rather inconvenient
    for implementors of scripting languages. That's because, for a scripting
    language, everything is a DII request. Local interfaces, therefore, force
    the implementor to wrap all pseudo-objects and local interfaces in
    special wrapper objects.

    For pseudo-objects, there is nothing we can do. However, for local
    interfaces, we could require DII calls to be supported.

  • Reported: CORBA 2.3.1 — Wed, 5 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    resolved, see above

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

servant_to_id

  • Key: CORBA24-60
  • Legacy Issue Number: 3174
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the following text in the spec could be made a bit clearer:

    2. If the POA has the IMPLICIT_ACTIVATION policy and either the
    POA has the MULTIPLE_ID policy or the specified servant is not
    active, the servant is activated using a POA-generated Object Id
    and the Interface Id associated with the servant, and that Object
    Id is returned.

    Although it is stated elsewhere that IMPLICIT_ACTIVATION requires SYSTEM_ID,
    it wouldn't hurt to reflect this here too:

    2. If the POA has the IMPLICIT_ACTIVATION policy and either the
    POA has the MULTIPLE_ID policy or the specified servant is not
    active and the POA has the SYSTEM_ID policy, the servant is
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    activated using a POA-generated Object Id
    and the Interface Id associated with the servant, and that Object
    Id is returned.

    Another question:

    What should be returned if the USER_ID policy is present?

    The spec doesn't say. Given that we can't add a new user exception,
    OBJ_ADAPTER seems appropriate.

  • Reported: CORBA 2.3.1 — Tue, 4 Jan 2000 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4
  • Disposition Summary:

    Close with no change, since a POA cannot have IMPLICIT_ACTIVATION and USER_ID.

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

What is the TypeCode for ValueBase?

  • Key: CORBA24-54
  • Legacy Issue Number: 3132
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    I know this is late, but I think it is quite urgent, and we ought to
    add it to the last Core 2000 vote.]

    The spec is silent about the existence and properties of a TypeCode
    constant for ValueBase, even though it is necessary to define one so
    that the DII, DSI and IFR can operate properly.

    There also is no explicit information about what values operation calls
    on the TC_Object typecode constant return.

    Proposal:

    1. Add to the list of TypeCode constants in 10.7.2:

    TC_ValueBase = tk_value

    { ValueBase }

    2. Add at the end of section 10.7.2:

    For the TC_Object TypeCode constant, calling id returns
    "IDL:omg.org/CORBA/Object:1.0" and calling name returns "Object". For
    the TC_ValueBase TypeCode constant, calling id returns
    "IDL:omg.org/CORBA/ValueBase:1.0", calling name returns "ValueBase",
    calling member_count returns 0, calling type_modifier returns
    CORBA::VM_NONE, and calling concrete_base_type returns a nil TypeCode.

  • Reported: CORBA 2.3.1 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Yes, this is a signficant outage. It should be fixed and the fix should be incorporated in 2.3 via t

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

Do valueboxes have factories?

  • Key: CORBA24-53
  • Legacy Issue Number: 3115
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Nowhere in the CORBA 2.3 specification is it made clear whether or not
    valueboxes have or need a valuefactory.

    Since valueboxes are clearly completely concrete types, with no
    operations, and with no factory initializers, there is no need for a
    factory for valueboxes.

    Proposal:

    Add the following to secion 5.2.8.1:

    "Value box types do not need or use factories."

  • Reported: CORBA 2.3.1 — Tue, 14 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

DynAny & abstract interfaces don't mix!

  • Key: CORBA24-52
  • Legacy Issue Number: 3109
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 9.2.2 states:

    "The operation raises InconsistentTypeCode if value has a TypeCode with
    a TCKind of tk_Principal, tk_native, or tk_abstract_interface."

    This is totally broken for abstract interfaces. What happens if I do
    this:

    // IDL
    abstract interface I {
    };

    struct S

    { I an_i; }

    ;

    // C++
    S mys;
    CORBA::Any a;

    a <<= s;

    DynamicAny::DynAnyFactory_var daf = ...;
    DynamicAny::DynAny_var da = daf->create_dyn_any(a);
    DynamicAny::DynAny_var component = da->current_component();

    Obviously the value of component must be meaningful, otherwise there is
    no way to examine or construct a value of type S.

  • Reported: CORBA 2.3.1 — Fri, 10 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

create_POA and inactive state?

  • Key: CORBA24-48
  • Legacy Issue Number: 3073
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    what should happen if I call create_POA() on a POA whose POA manager is
    in the inactive state (that is, a POA on which, previously, deactivate()
    was called?

    The spec says nothing about this. Seeing that creating a new POA on a "dead"
    POA doesn't make sense, I would suggest to raise BAD_INV_ORDER, possibly
    with a new minor code.

  • Reported: CORBA 2.3.1 — Thu, 2 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

value type substitutability

  • Key: CORBA24-47
  • Legacy Issue Number: 3072
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    Chapter 5.2.5: Value type semantics should not define that an instance of a
    value type can be passed (directly) as a parameter that is declared as an
    interface type. The reason is that this is not true in some of the language
    mappings (e.g. C++) because it contradicts the kind and nature of value types.

    A value type instance IS NOT an object reference even if it is registered with
    the ORB. Therefore, if a construct conceptually is not a subtype of another
    construct, it should not be possible that it substitutes the other. Also, it
    should not be required that there are any shortcuts which automatically convert
    a registered valuetype to it's associated object reference.

  • Reported: CORBA 2.3.1 — Tue, 30 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Clarify the ambiguity that leads to the possible inappropriate interpretation

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

OMG IDL Syntax and Semantics issue

  • Key: CORBA24-46
  • Legacy Issue Number: 3069
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The following thing is unnoticed in CORBA V2.3, June 1999, OMG document
    99-07-07.pdf, Chapter 3, "OMG IDL Syntax and Semantics", pages 3-37..3-39,
    definition of "sequence" type:

    There is no explicit definition what length sequence may have at run
    time. Things are perfectly defined for sequence bounds (i.e. maximum
    size at compile time) which is explicitly declared to be a positive
    integer. However, nothing is said whether length of sequence at run
    time can be: (a) positive; or (b) non-negative; or even (c) negative.

  • Reported: CORBA 2.3.1 — Mon, 29 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

TypeCode issue

  • Key: CORBA24-45
  • Legacy Issue Number: 3048
  • Status: closed  
  • Source: ZeroC ( Marc Laukien)
  • Summary:

    At present, the following IDL code is illegal:

    interface I

    { CORBA::TypeCode get_type(); }

    ;

    To make it legal, "orb.idl" must be included. From the spec:

    "The file orb.idl contains the IDL definitions for the CORBA module. The
    file orb.idl must be included in IDL files that use names defined in the
    CORBA module."

    I don't think that this is a good idea, because of the following
    reasons:

    • TypeCode is PIDL, not IDL. So orb.idl can only be used as a "switch"
      to enable TypeCode, but it cannot contain a "real" IDL definition for
      TypeCode.
    • Having to include orb.idl for every little program that requires
      TypeCode means a huge overhead, as orb.idl includes everything from
      the CORBA module (including the IFR!).

    I don't see any reason why TypeCode should only be available if orb.idl
    is included. To me, TypeCode is "built-in", even if it doesn't have a
    keyword. So it appears rather strange to me that I have to artificially
    disable TypeCode in our IDL parser if orb.idl is not included, just to
    be compliant with the spec.

    I would therefore propose to allow CORBA::TypeCode in IDL even if
    orb.idl is not included.

  • Reported: CORBA 2.3.1 — Tue, 23 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

IDL scoping rules

  • Key: CORBA24-59
  • Legacy Issue Number: 3173
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    on page 3-48, we have:

    On the other hand, if module Inner2 were:

    module Inner2

    { typedef Inner1::S1 S2; // Inner1 introduced typedef string inner1; // Error typedef string S1; // OK }

    ;

    The definition of inner1 is now an error because the identifier
    Inner1 referring to the module Inner1 has been introduced in the
    scope of module Inner2 in the first line of the module declaration.
    Also, the declaration of S1 in the last line is OK since the
    identifier S1 was not introduced into the scope by the use of
    Inner1::S1 in the first line.

    This is fine, but it doesn't make it clear that, if the name is qualified,
    it is not introduced into the scope.

  • Reported: CORBA 2.3.1 — Sun, 2 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Additional clarifying words are needed as shown below.

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

null & void TCs and DynAny

  • Key: CORBA24-57
  • Legacy Issue Number: 3159
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    The DynAny chapter says nothing about whether
    DynAnyFactory::create_dyn_any_from_type_code is supposed to correctly
    handle a TypeCode argument that has a TCKind of either tk_null or tk_void.

    I assume these are valid argument TypeCodes that do not result in an
    InconsistentTypeCode exception, and the returned DynAny is simply one that
    fulfills the basic DynAny interface and has no components. However, it
    would be nice to explicitly document the cases for these two TypeCodes,
    though, given that they're a little different from other TypeCodes in that
    they can't have any associated values.

  • Reported: CORBA 2.3.1 — Tue, 21 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Clarify with additional text as shown below

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

Bug in 11.3.7.6

  • Key: CORBA24-58
  • Legacy Issue Number: 3172
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    on page 11-30, we have:

    RETAIN and USE_ACTIVE_OBJECT_MAP_ONLY

    This combination represents the situation where the POA does no
    automatic object activation (that is, the POA searches only the
    Active Object Map). The server must activate all objects served
    by the POA explicitly, using either the activate_object or
    activate_object_with_id operation.

    The final sentence is wrong. Implicit activation is controlled by the
    ImplicitActivation policy.

  • Reported: CORBA 2.3.1 — Sun, 2 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Remove the incorrect sentence

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

Problem with the "Special scoping" rules in 3.15.3

  • Key: CORBA24-37
  • Legacy Issue Number: 2980
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The special scoping rules make it clear that they apply only to
    identifiers that name a type, however the second IDL example claims that
    the import of a constant definition (in this case the identifier I) into
    an interface scope behaves the same way.

    So which one is it? Do the rules only apply to type identifiers or to
    all identifiers?

  • Reported: CORBA 2.3.1 — Mon, 8 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    The changes below provide clarification.

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

Meaningless sentence on page 3-11?

  • Key: CORBA24-36
  • Legacy Issue Number: 2978
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 3-11 says about string literals:

    The size of a string literal is the number of character literals
    enclosed by the quotes, after concatenation. The size of the
    literal is associated with the literal.

    The final sentence appears to be meaningless. Suggest to delete it.

  • Reported: CORBA 2.3.1 — Wed, 3 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Type Code Section issue

  • Key: CORBA24-32
  • Legacy Issue Number: 2963
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    I was wondering why the TypCodes definition section is in Chapter 10, Interface
    Repository. Type Codes are used by lots of other things that have very little to
    do with Interface Repository. Wouldn't it be better to move the TypeCode section
    to Chapter 4.

  • Reported: CORBA 2.3.1 — Wed, 27 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Minor codes for Standard System Exceptions in Chapter 8 missing

  • Key: CORBA24-31
  • Legacy Issue Number: 2960
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    Chapter 8 (formal/99-07-12) is missing specification of minor codes for all the
    standard system exceptions that are specified to be raised under various
    circumstances.

  • Reported: CORBA 2.3.1 — Tue, 26 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Minor codes for Standard System Exceptions in Chapter 5 missing

  • Key: CORBA24-30
  • Legacy Issue Number: 2959
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    Chapter 5 (formal/99-07-09) is missing specification of minor codes for all the
    standard system exceptions that are specified to be raised under various
    circumstances.

  • Reported: CORBA 2.3.1 — Tue, 26 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

IDL and C++ relationship

  • Key: CORBA24-34
  • Legacy Issue Number: 2976
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    page 3-2 of the spec says (Section 3.1, para 3 and para 5):

    OMG IDL obeys the same lexical rules as C++.

    [ ... ]

    The OMG IDL grammar is a subset of the proposed ANSI C++ standard...

    Both paragraphs are simply wrong. IDL doesn't obey the same lexical rules
    and it isn't a subset of C++. In addition, we now have the final ISO/IEC
    C++ standard, so talking about the proposed or draft standard is out of date.

    I would suggest to systematically replace references to ANSI C++, the
    "proposed" standard, or the "draft" standard with the proper ISO/IEC
    reference.

    The verbage about IDL being a subset of C++ and obeying the same lexical
    rules should be removed. It simply isn't true.

  • Reported: CORBA 2.3.1 — Wed, 3 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

PIDL vs Local

  • Key: CORBA24-33
  • Legacy Issue Number: 2974
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Regarding using a version in a repository ID:

    If old PIDL were to be recast to local, each time the
    interface def would be enhanced (by adding new local
    operations), the IDL module would have to be appropriately
    versioned.

    I also point out that using a version for corba::object's repository
    id seems inappropriate, since there are multiple version of
    corba::object which the omg never bothered to version, since they
    did not have to.

    Thus, in summary, putting version 1.0 to correspond to a pidl interface
    implies stability in that inteface (i.e., it will not change without
    changing
    the version number), which the OMG has never enforced for PIDL.

  • Reported: CORBA 2.3.1 — Mon, 25 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed in interop/2000-01-01

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

Missing "abstract" in forward declaration

  • Key: CORBA24-40
  • Legacy Issue Number: 3018
  • Status: closed  
  • Source: Perot Systems ( Bill Binko)
  • Summary:

    In the new Core 2.3.1 (http://www.omg.org/cgi-bin/doc?formal/99-10-07),
    section 3.7.4 is incorrect in that it does not mention the optional
    "abstract" keyword.

    A forward declaration declares the name of an interface without defining it.
    This
    permits the definition of interfaces that refer to each other. The syntax
    consists simply

    of the keyword interface followed by an <identifier> that names the
    interface. The
    actual definition must follow later in the specification.

    The paragraph is not in sync with the idl grammar in section 3.4

    (6) <forward_dcl> ::= [ "abstract" ] "interface" <identifier>

  • Reported: CORBA 2.3.1 — Wed, 10 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

The algorithm for TypeCode::equivalent in 10.7.1 was not updated

  • Key: CORBA24-39
  • Legacy Issue Number: 3001
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The algorithm for TypeCode::equivalent in 10.7.1 was not updated to
    reflect the new TypeCode::member_visibility, TypeCode::type_modifier,
    and TypeCode::concrete_base_type operations.

  • Reported: CORBA 2.3.1 — Thu, 4 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Editorial glitch in DynAny::destroy, section 9.2.3.6

  • Key: CORBA24-44
  • Legacy Issue Number: 3041
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The first paragraph of 9.2.3.6 refers to "creation operations on the ORB
    interface". This needs to be changed to "creation operations on the
    DynAnyFactory interface".

  • Reported: CORBA 2.3.1 — Tue, 16 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

What is the NO_RESPONSE exception good for?

  • Key: CORBA24-43
  • Legacy Issue Number: 3022
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 3.17.1.15 states:

    "NO_RESPONSE

    This exception is raised if a client attempts to retrieve the result of
    a deferred synchronous call, but the response for the request is not yet
    available."

    Meanwhile, section 7.3.4 states:

    "get_response returns the result of a request. If get_response is called
    before the request has completed, it blocks until the request has
    completed."

    So if get_response blocks, how and when will and ORB ever raise
    NO_RESPONSE?

  • Reported: CORBA 2.3.1 — Fri, 12 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

General Exception Question

  • Key: CORBA24-29
  • Legacy Issue Number: 2955
  • Status: closed  
  • Source: International Business Machines ( Russell Butek)
  • Summary:

    Could someone explain to me the justification for all the restrictions on
    > exceptions? Why CAN'T we: pass exceptions as parameters, use them as
    > elements in container types? I know the IDL language doesn't allow it, I
    > just want to know why it was designed that way. Other languages certainly
    > allow it.

  • Reported: CORBA 2.3.1 — Tue, 26 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Exception section issue

  • Key: CORBA24-28
  • Legacy Issue Number: 2954
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    I was wondering why the Standard Exception definitions are in Chapter 3 IDL
    Syntax and Semantics. Shouldn't they be better in Chapter 4 ORB Interfaces? I would like to get a feel for how the RTF membership feels about moving the
    entire section 3.21 from Chapter 3 to Chapter 4.

  • Reported: CORBA 2.3.1 — Thu, 14 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Section 7.6: IDL context housecleaning

  • Key: CORBA24-42
  • Legacy Issue Number: 3021
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Now that we've bitten the bullet and moved the Exception section from
    chapter 3 to chapter 4, shouldn't we do the same thing with section 7.6,
    since IDL contexts actually have little to do with the DII?

    I propose that we move section 7.6 to chapter 4 as well.

  • Reported: CORBA 2.3.1 — Fri, 12 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Question about IDL \uxxxx escape format

  • Key: CORBA24-41
  • Legacy Issue Number: 3020
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Why was the \uxxxx escape from C++ added to wide string & char literals
    in IDL, but the equivalent \Uxxxxxxxx escape was not?

  • Reported: CORBA 2.3.1 — Thu, 11 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Duplicate

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

Preprocessing of IDL

  • Key: CORBA24-35
  • Legacy Issue Number: 2977
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 3-12:

    OMG IDL preprocessing, which is based on ANSI C++ preprocessing, ..
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    The highlighted phrase is meaningless and should be deleted.

    In addition, the last para of 3.3 says that

    A complete description of the preprocessing facilities may be found
    in the The Annotated C++ Reference Manual.

    For one, the ARM is badly out of date. Second, the para implies, but doesn't
    actually say, that IDL preprocessing is exactly like C++ preprocessing.

    I would suggest to replace the last para with a definitive statement to
    say that IDL is preprocessed as described for C++ in the ISO/IEC C++ standard.
    In addition, that statement should probably be used as the lead-in to
    section 3.3.

  • Reported: CORBA 2.3.1 — Wed, 3 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Codeset conversions and unions

  • Key: CORBA24-38
  • Legacy Issue Number: 3000
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Recently, we decided not to permit wchar as the discrinator type for
    unions because of the impossibility of dealing with different codesets.

    Well, it looks like we have exactly the same problem for char

  • Reported: CORBA 2.3.1 — Thu, 4 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Use of incomplete recursive TypeCodes underspecified

  • Key: CORBA24-17
  • Legacy Issue Number: 2903
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    Section 10.7.3 of the CORBA 2.3 spec says that operations on recursive
    TypeCodes and recursive sequence TypeCodes before they have been embedded
    give undefined results.

    However, it is not clear whether this applies to other uses of these
    TypeCodes ... or other incomplete TypeCodes or Anys that contain them. For
    example, can an incomplete TypeCode be used:

    • as a parameter to create_dyn_any_from_type_code,
    • as a parameter to a DII or DSI operation; e.g. the arg_type parameter
      of CORBA::Request::add_arg(), or
    • as a (CORBA IDL) parameter or result of a regular operation invocation?
  • Reported: CORBA 2.3.1 — Thu, 14 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Semantics of DynAny with alias TypeCodes

  • Key: CORBA24-16
  • Legacy Issue Number: 2901
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The CORBA 2.3 spec for DynAny makes no mention whatsoever of how it should
    handle Any values corresponding to TypeCodes whose kind is tk_alias.

    The implementation of (CORBA 2.2) DynAny in a popular free ORB strips off
    typecode aliases when it creates a DynAny. While this seems to be contrary to
    the overall intent of the DynAny spec, I can find nothing in the 2.2 or 2.3
    spec that definitively precludes this (IMO bogus) behaviour.

  • Reported: CORBA 2.3.1 — Thu, 14 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

URLs interact poorly with code set selection

  • Key: CORBA24-15
  • Legacy Issue Number: 2900
  • Status: closed  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    The corbaname & corbaloc url formats provide a situation where an IOR
    designating a server is created and used by a client without input by
    that server.

    One (optional) element of an IOR is a CodeSetComponent specifying the
    code sets that the server is willing/able to utilize. Normally these are
    examined by a client and used to select a pair of code sets (narrow and
    wide) to be used for communication between client and server.

    Chapter 13 of the Corba spec states: "If the code set component is not
    present in a multi-component profile structure, then the deault char
    code set is ISO 8859-1 for backward compatibility. However, there is no
    default wchar code set. If a server supports interfaces that use wide
    character data but does not specify the wchar code sets that it
    supports, client-side ORBs will raise exception INV_OBJREF."

    This seems to imply one of the following:
    1) URLs may not be used to reference interfaces that employ wide
    characters;
    2) URLs must generate IORs with a code set component supporting
    wchar data;
    3) The CORE must be changed to relax the above restrictio

  • Reported: CORBA 2.3.1 — Tue, 5 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Problem with text of POAManager::deactivate()

  • Key: CORBA24-23
  • Legacy Issue Number: 2911
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The first paragraph of 11.3.2.6 says:

    This operation changes the state of the POA manager to inactive. If
    issued while the POA manager is in the inactive state, the
    AdapterInactive exception is raised. Entering the inactive state causes
    the associated POAs to reject requests that have not begun to be
    executed as well as any new requests.

    But the last paragraph says:

    If deactivate is called multiple times before destruction is complete
    (because there are active requests), the etherealize_objects parameter
    applies only to the first call of deactivate; subsequent calls with
    conflicting etherealize_objects settings will use the value of the
    etherealize_objects from the first call. The wait_for_completion
    parameter will be handled as defined above for each individual call
    (some callers may choose to block, while others may not).

    So which is right? Is does a subsequent call to deactivate() raise
    AdapterInactive, or does it succeed, perhaps blocking until completion?

  • Reported: CORBA 2.3.1 — Mon, 18 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

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

CORBA 2.3 spec hasn't been updated with corrections in COM-CORBA Part B

  • Key: CORBA24-22
  • Legacy Issue Number: 2910
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I notice that the CORBA 2.3 spec hasn't been updated with one of the corrections in
    part B of the COM-CORBA Interworking spec (orbos/97-09-06).

    page 13C-130 of the Part B spec, CORBA::Char mapping to UI1 has not been updated
    in the corresponding section in the CORBA 2.3 spec (19.3.1, page 19-10).

  • Reported: CORBA 2.3.1 — Wed, 13 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

creation of arguments to TypeCode creation ops

  • Key: CORBA24-19
  • Legacy Issue Number: 2907
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    It is not clear from section 10.7.3 of CORBA 2.3 how much param checking
    the ORB operations for TypeCode creation should do. It is also unclear
    whether only the BAD_PARAM exception should be raised, or whether some
    others are legitimate; e.g. BAD_TYPECODE.

    Here are some detailed questions on TypeCode creation argument checking:

    1) should the operations that take a "name" argument check that it
    is a valid IDL name? A non null string?

    2) should the operations that take a "RepositoryId" argument check
    that it has a recognisable format?

    3) should the operations that take content and member types as
    parameters check that they are legitimate; i.e. that they
    don't have kinds tk_null, tk_void or tk_exception.

    4) should the operations that take members check that the member
    names are valid IDL names and that they are unique within the
    member list?

    5) should create_union_tc check that there are no duplicate label
    values? Should it check that the labels' TypeCodes are equal to
    discriminator TypeCode? Or equivalent?

    6) should create_union_tc check that the supplied discriminator
    type is legitimate?

    There are probably more cases as well.

  • Reported: CORBA 2.3.1 — Thu, 14 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

CORBA 2.3 Editorial issue for TypeCodes & abstract_interface

  • Key: CORBA24-27
  • Legacy Issue Number: 2945
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The comments in the definition of TypeCode in 10.7.1 shows that id() and
    name()
    are valid for TypeCodes of kind tk_abstract_interface, but the text
    descriptions of the id() and name() operations do not list abstract
    interface TypeCodes as supporting these operations.

  • Reported: CORBA 2.3.1 — Thu, 21 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Editorial issue for CORBA 2.3, 1.3.8.20

  • Key: CORBA24-26
  • Legacy Issue Number: 2944
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 11.3.8.20 (servant_to_id) was not updated in the same fashion as
    section 11.3.8.21.

    There are two problems:

    1. The RETAIN policy in the first paragraph needs bold face.

    2. Behaviors 1 & 2 should both require the RETAIN policy, just like the
    text in section 11.3.8.21.

  • Reported: CORBA 2.3.1 — Wed, 20 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Why are Standard Exceptions defined in IDL chapter?

  • Key: CORBA24-14
  • Legacy Issue Number: 2898
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    I was wondering why the Standard Exception definitions are in Chapter 3 IDL
    Syntax and Semantics. Shouldn't they be better in Chapter 4 ORB Interfaces?
    I would like to get a feel for how the RTF membership feels about moving the
    entire section 3.21 from Chapter 3 to Chapter 4.

  • Reported: CORBA 2.3.1 — Wed, 13 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

What is the RepId of Object?

  • Key: CORBA24-13
  • Legacy Issue Number: 2896
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    "Can someone please clue me in as to what the
    > repository ID of Object is? Is it "IDL:omg.org/CORBA/Object:1.0"? Or is
    > it "IDL:omg.org/Object:1.0"?"

  • Reported: CORBA 2.3.1 — Wed, 20 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

formal/99-08-01.txt missing pragmas

  • Key: CORBA24-21
  • Legacy Issue Number: 2909
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The ORB Core IDL extracted in formal/99-08-01.txt is missing the various
    '#pragma' definitions for the IFR interfaces.

  • Reported: CORBA 2.3.1 — Tue, 12 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

CORBA::ORB::RequestSeq definition obsolete

  • Key: CORBA24-20
  • Legacy Issue Number: 2908
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    CORBA 2.3 added the CORBA::RequestSeq definition to orb.idl. The C++
    mapping defines CORBA::ORB::RequestSeq, which is now redundant and
    should be removed.

  • Reported: CORBA 2.3.1 — Tue, 12 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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