Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
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-200 Transmission of type codes across 2.2/2.3 boundaries CORBA 2.2 CORBA 2.4 Resolved closed
CORBA24-199 LOCATE_FORWARD_PERM and hash() CORBA 2.2 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-196 Changebars missing from POA chapter CORBA 2.3 CORBA 2.4 Resolved 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
CORBA24-187 Expected behavior of POA configured with ServantLocator receiving LocateRe CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-186 Section 3.3.8.16:deactivate_object() operation CORBA 2.1 CORBA 2.4 Resolved closed
CORBA24-185 Definition of TRANSIENT minor code 1 confusing CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-184 IDL format for RepositoryId CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-183 Valuetypes supporting local interfaces are local types? CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-182 #pragma version issue CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-181 Servant deactivation callback? CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-180 DynUnion incomplete CORBA 2.4 CORBA 2.4.2 Resolved closed
CORBA24-179 Format of RMI Hashed Format repid CORBA 2.4 CORBA 2.4.2 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
CORBA24-132 Use of the type ComponentHome CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-131 USING Components::Enumeration CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-130 destroy() for local objects CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-128 Implementation of get_component CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-129 New IDL keywords CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-127 CORBA IR METAMODEL CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-126 Is the ccm_home method shown in Table 8-1 a typo? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-123 Do EJB-mapped attributes go to the ComponentDefault interface? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-124 What's the return type of CCM mappings of EJB finder and creator methods? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-125 How is CCMHome::get_home_def mapped to EJB operations? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-121 CCM Issue: How are standard EJB exceptions mapped into the CCM View CPP 1.1 CORBA 2.4.2 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-118 Components Issues - Interface Repository ptc/99-10-03 CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-122 CCM Issue: Is CCMObject::remove intended to be available to the CCM client? CPP 1.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-117 Components Issues - Chapter 61 ptc/99-10-04 CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-115 Policies not locality-constrained? CPP 1.0 CORBA 2.4 Resolved closed
CORBA24-116 implementing import for C++ CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-114 Locality-constrained objects CORBA 2.2 CORBA 2.4 Resolved closed
CORBA24-113 Locality constrained objects + externalization CORBA 2.2 CORBA 2.4 Closed; No Change closed
CORBA24-171 wchar alignment in GIOP 1.2 CORBA 2.4 CORBA 2.4.2 Resolved closed
CORBA24-170 Is padding necessary for empty Reply body? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-168 Small optimization for the GIOP header CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-169 GIOP _get_domain_managers ambiguous CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-167 interop issue: CodeSets service context in GIOP 1.0 request CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-166 Version and byte order changes when fragmenting messages (interop) CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-163 selected_profile_index origin CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-165 Issue 2 -- resulting from UK comment UK-5: CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-161 ORB throwing exception if it finds unknown service context CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-162 Absence of Wide Character Code Set CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-164 Issue 1 -- resulting from Japanese comment JPN-009E: CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-160 Wrong minor code specified in Chapter 13 CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-157 GIOP version and CloseConnection CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-156 Valuetype in anys. Unmarshaling problem? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-159 Nesting depth in valuetype end tags CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-158 Valuetype encoding grammar in 15.3.4.7 is wrong CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-154 IIOP 1.2 Early Reply message in presence of fragmented Request CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-155 Marshaling fixed-point decimal types CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-151 Indirection for value types CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-153 Transferring Java exception reason string across the wire CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-152 Preserving unencapsulated information CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-148 Should an ORB be allowed to drop non-standard profiles CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-149 An ORB should not accept an IOR with no usable profiles CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-145 Supporting TAG_MULTIPLE_COMPONENTS CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-146 CORBA 2.3.1 missing text describing the response_expected field CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-147 chunked value encoding: CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-150 Validity of object references CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-144 Table 13-1 needs update for valuetypes & abstract interfaces CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-142 CDR Encapsulation Issue 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-141 Minor code allocation inconsistency CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-140 GIOP encoding of nil Abstract Interface is unspecified CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-139 .Passing the interface repository ID of the method in IIOP CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-137 TAG_ENDPOINT_ID_POSITION and TAG_LOCATION_POLICY CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-138 Chunked GIOP marshalling for variable-length types CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-133 Compacting GIOP messages by using indirections CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-134 Compacting GIOP Messages by using templates CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-135 Compacting GIOP Requests by hashing down operation names CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-136 Optimization of LOCATION_FORWARD replies CORBA 2.2 CORBA 2.4.2 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-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-110 module IOP_N needs a real name 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-107 read_fixed() and write_fixed() methods missing 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-105 IDL: Clashes with inherited identifiers 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-104 Nested Recursive Structs Legal in 2.3.x? 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-97 AbstractBase not declared. 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-95 Non-escaped keywords in published IDL 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-94 servant_to_id versus servant_to_reference CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-91 Some problems CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-93 ORB::shutdown underspecified 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-90 ORB shutdown vs destroy 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-87 Incorrect use of negative fixed scale 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-85 ValueMemberDef section omitted from CORBA 2.3.1 spec 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-82 POA deactivate_object description is ambiguous 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-81 how are valid ORBids determined 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-76 response_flags in interop draft 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-75 symbolic constants for minor exception codes CORBA 2.3.1 CORBA 2.4 Closed; No Change closed
CORBA24-80 POA namespace and ORB ID CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-78 POA status during destruction is unclear CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-74 valuetype factory inheritence? 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-71 #pragma rules are too restrictive 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-70 Editorial mistake in IDL chapter CORBA 2.3.1 CORBA 2.4 Resolved 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-72 Minor glitch about forward declared things 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-67 Semantics for DynAny::equal underspecified 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-62 special-casing TypeCode is unnecessary 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-59 IDL scoping rules 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-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-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-53 Do valueboxes have factories? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-54 What is the TypeCode for ValueBase? 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-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-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-45 TypeCode issue 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-49 Use of Principal in GIOP Module erroneous 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-42 Section 7.6: IDL context housecleaning 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-41 Question about IDL \uxxxx escape format 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-38 Codeset conversions and unions 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-34 IDL and C++ relationship 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-30 Minor codes for Standard System Exceptions in Chapter 5 missing CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-35 Preprocessing of IDL 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-29 General Exception Question 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-28 Exception section issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-33 PIDL vs Local 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-23 Problem with text of POAManager::deactivate() CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-25 Component ids in 13.6.2.2 CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-24 (CORBA Core) Data streams missing arrays of long double CORBA 2.3 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-26 Editorial issue for CORBA 2.3, 1.3.8.20 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
CORBA24-19 creation of arguments to TypeCode creation ops 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-17 Use of incomplete recursive TypeCodes underspecified CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-18 DynFixed editorial issue CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-15 URLs interact poorly with code set selection CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-11 POA exception minor codes CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-16 Semantics of DynAny with alias TypeCodes CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-12 DataInputStream specification is inefficient for Java CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-13 What is the RepId of Object? 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-9 CORBA 2.3: minor editorial issue CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-10 Wchar as discriminator in union CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-8 chapter 3 and recursion CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-7 ambiguity in wstrings having a Unicode escape sequence CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-2 interop issue: what system exceptions may be raised on GIOP 1.0? CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-3 mixing giop versions CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-6 POA: false placement of paragraph CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-4 $issue.summary CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-5 OBV interface support inconsistencies CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-1 The syntax for stringified IORs in section 13.6.6 CORBA 2.3 CORBA 2.4 Resolved closed

Issues Descriptions

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

Transmission of type codes across 2.2/2.3 boundaries

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

    Summary: Suppose I am using a 2.3 ORB and receive a type code from a 2.2 ORB without
    a repository ID. What am I supposed to do if I want to send that type
    code somewhere else? (This could happen for an event channel, for example.)

  • Reported: CORBA 2.2 — Wed, 16 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    In this case, we need to add the case for empty repository ID string implies that a repositoryID is

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

LOCATE_FORWARD_PERM and hash()

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

    Summary: With GIOP 1.2, we added LOCATE_FORWARD_PERM to the protocol, which
    permanently replaces an IOR with a different one. I believe we shouldn"t
    have done this because it creates an internal inconsistency. The
    Object::hash() operation requires that the hash value for a reference
    must be immutable during its life time. (Unfortunately, "life time" isn"t
    well-defined.)

  • Reported: CORBA 2.2 — Wed, 3 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    resolved

  • 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

Changebars missing from POA chapter

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

    Summary: Many changes between CORBA 2.2 and CORBA 2.3 are not changebarred. Some
    examples from the POA chapter (docs/formal/99-07-15.pdf):

    • Page 11-20: added PortableServer::POAManager::get_state() method.
    • Page 11-28: change in the TRANSIENT lifespan policy"s semantics
      (from "cannot outlive the process" to "cannot outlive the POA instance")
    • Page 11-35: change in PortableServer::POA::set_servant_manager()
      semantics wrt multiple invocations

    I wonder which other tidbits I"ve overlooked so far. Is there a complete
    list of changes (such as a CVS log) anywhere?

  • Reported: CORBA 2.3 — Sun, 15 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 15:20 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

Expected behavior of POA configured with ServantLocator receiving LocateRe

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

    Summary: This is an issue with the Portable Object Adapter:

    If a POA configured with a ServantLocator receives a LocateRequest, what
    is the expected behavior? A ServantLocator expects to receive an operation
    name as a parameter to preinvoke() and postinvoke(), but there is no
    operation name in a LocateRequest.

    We could just return a true response to the LocateRequest and not involve
    the ServantLocator. That might mislead the sender though. If the sender
    received a true response and then sent a message they might get an
    OBJECT_NOT_EXIST exception back.

    We could pass an operation name like "_locate" to the manager. That would
    let the manager know that a location request was being processed, and the
    underscore would signify that it is an internal message since it"s not a
    _get or _set.

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

    Add a subsection to section 11.3.6 specifying "_locate" and its usage.

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

Section 3.3.8.16:deactivate_object() operation

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

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

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

    No Data Available

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

Definition of TRANSIENT minor code 1 confusing

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

    >From CORBA 2.4, Table 4-3: TRANSIENT minor code 1 is described as:

    "Request discarded due to resource exhaustion in POA."

    However, section 11.3.2.1 states that minor code 1 is used when the
    POAManager is in the DISCARDING state.

    I think it would be better to reword this description as:

    "Request discarded because POAManager is in DISCARDING state (e.g.
    server lacks resources to complete request.)"

  • Reported: CORBA 2.4.1 — Thu, 9 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Make it so

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

IDL format for RepositoryId

  • Legacy Issue Number: 4035
  • Status: closed  
  • Source: UBS ( Karsten Starr)
  • Summary:

    Following statement in CORBA V2.3 (06/1999),
    P10-39, Chapter 10.6.1, OMG IDL Format concerning
    the OMG IDL format for Repository IDs:

    >> The RepositoryId consists of three components, separated by
    colons, (":")

    The first component is the format name, "IDL."

    The second component is a list of identifiers, separated by
    "/" characters.

    These identifiers are arbitrarily long sequences of alpha-
    betic, digit, underscore ("_"), hyphen ("-"), and period (".")
    characters. Typically, the first identifier is a unique prefix,
    and the rest are OMG IDL Identifiers that make up the scoped
    name of the definition. <<

    There are two issues here:

    • Firstly I propose to change >>"IDL."<< into >>"IDL".<<
    • Furthermore, I propose be more specific on the definition
      of the Repository Id. The above definition does not
      exclude a RepositoryId in the following style (which
      in my opinion does not make sense and effects inter-
      operability between ORBs): "IDL:/A/B:1.0"
      A regular expression could clarifiy this issue:
  • Reported: CORBA 2.4.1 — Thu, 9 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Incorporate changes and close issue.

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

Valuetypes supporting local interfaces are local types?

  • Legacy Issue Number: 4031
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    The semantics for local interfaces states:

    A valuetype may support a local interface.

    This brings up two questions.
    1. Can it support multiple? In addition to a unconstrained non abstract
    interface?
    2. Does it then become a local type (I think not, I think it becomes a
    local type only when it contains state that is a local type)

  • Reported: CORBA 2.4.1 — Wed, 8 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    No Data Available

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

#pragma version issue

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

    In the CORBA 2.4 spec, chapter 10, the definition of #pragma ID has
    been modified so that later re-declarations of the same ID for a type
    are permitted. Before, it was explicitly an error to use #pragma ID
    for a type more than once, even if the same IDs were given.

    The section of #pragma version has not been updated. This means that
    handling of the two similar pragmas is now inconsistent:

    interface A {};
    #pragma ID A "LOCAL:foo"
    #pragma ID A "LOCAL:foo" // OK in 2.4, error in 2.3

    interface B {};
    #pragma version B 3.4
    #pragma version B 3.4 // Error in 2.4 and 2.3

    Should #pragma version be updated to be consistent with #pragma ID?

  • Reported: CORBA 2.4.1 — Fri, 3 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Incorporate changes and close issue

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

Servant deactivation callback?

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

    Consider a servant for a persistent object that sits in front of a database.
    Assume a simple implementation model, using RETAIN and
    USE_ACTIVE_OBJECT_MAP_ONLY.

    We have n CORBA objects with n servants, and each servant implements
    its operations by reading/writing through to the persistent store, possibly
    also caching some state and maintaining other resources, such as database
    connections or memory buffers.

    I want to implement a life cycle destroy() operation. In the body of
    destroy, I have to write something like:

    void
    Foo_impl::
    destroy() throw(CORBA::SystemException)

    { my_poa->deactivate_object(my_oid); // Cannot remove database record here or do any other // cleanup. }

    The problem is that the servant can't simply blow things away at that
    point because there may be other operations running concurrently in the
    same servant, and those operations would get awfully surprised if their
    state suddenly disappeared.

    So, I delay reclaiming resources and deleting the database record until
    the servant becomes idle. In C++, that's no problem. Eventually, the
    servant's AOM entry disappears and (at least if I use reference-counted
    servants) that triggers the destructor of the servant, and I can
    clean up in the destructor.

    However, it appears that this doesn't work for other languages because they
    may not have destructors or, like Java, make no guarantees about when
    the destructor will be called.

    The problem is that there is no way for me to find out at what
    point the servant becomes idle, so that I could clean up.

    I think we need a callback from the ORB to the server application code that
    notifies the server when a servant finally becomes idle. Otherwise, it is
    pretty much impossible to implement life cycle support in languages other
    than C++, especially for threaded servers.

  • Reported: CORBA 2.4.1 — Thu, 2 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close no change.

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

DynUnion incomplete

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

    given the a DynUnion value, I want to find out whether the discriminator
    currently indicates the default case. For example:

    union u switch (long)

    { case 0: long l; case 1: char c; case 2: double d; default: float f; }

    ;

    For this union, I want to know whether the default member is active, that is,
    whether the discriminator has a value other than 0, 1, or 2.

    Finding out whether the discriminator indicates the default case is currently
    rather difficult. I have to:

    1) get the union type code
    2) collect the values of all the explicit case labels from
    the type code
    3) check if the discriminator currently has a value that is not
    one of the explicit case labels values

    It would be much nicer to add the following to DynUnion:

    interface DynUnion : DynAny

    { boolean is_set_to_default_case(); // ... }

    ;

    The is_set_to_default_case operation returns true if a union has
    an explicit default label and the discriminator value does not
    match any of the union's other case labels.

  • Reported: CORBA 2.4 — Mon, 30 Oct 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Add the is_set_to_default_member function with the functionality as described for is_set_to_default_

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

Format of RMI Hashed Format repid

  • Legacy Issue Number: 3970
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    The format of the "hash code" element of an RMI Hashed Format repid
    needs to be clarified. Section 10.6.2 gives the algorithm for computing
    the 64-bit number to be used as the hash code, but does not specify the
    on-the-wire format for this number. In contrast, the spec explicitly
    states that the 64-bit number representing the SUID is transcribed as
    a 16-digit upper-case hex string.

  • Reported: CORBA 2.4 — Wed, 18 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Clarify as suggested below

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

Use of the type ComponentHome

  • Legacy Issue Number: 3645
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    1. In the document OMG ptc/99-10-04 p.69-329 there is in item 5 a use
    of the type ComponentHome, shouldn't it be CCMHome? If I do recall
    correctly, ComponentHome was used in the first versions of the
    specification proposal.

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    You are correct. ComponentHome should be CCMHome

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

USING Components::Enumeration

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

    It is probably not a good idea to mandate an implementation for
    Enumeration, since there may be different options for implementing.
    For example, it may be desirable for
    performance reasons to implement a form of lazy Enumeration that does
    not carry with it every element that it can contain, but requiring
    this kind of implementation can be overkill for some
    applications. Given this, Enumeration is defined as an abstract
    valuetype and at least one concrete specialization of it is
    required. In addition, FOR INTEROPERABILITY, at least one STANDARD
    implementation must also be provided so that client stubs and server
    skeletons know how to marshal and unmarshal Enumeration values.

  • Reported: CPP 1.1 — Tue, 14 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    resolution see above

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

destroy() for local objects

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

    every ORB I know of implements the various destroy() operations on
    local objects (such as policies or DynAny) as a no-op and destroys the local
    object on the final call to release() instead. Yet, the spec still requires
    programmers to call destroy(). The problem with this is that programmers
    can easily end up writing non-portable code without any visible problem.
    Then, when code is moved to another ORB, it is conceivable that it will
    leak objects.

    This isn't very pretty. I think we should get rid of the destroy() calls
    on local objects (possibly with the exception of the ORB object, although
    the entire shutdown issue for that is quite a mess anyway). It doesn't
    make sense to require the programmer to make a destroy() call for something
    that naturally can be reference counted.

  • Reported: CPP 1.1 — Wed, 19 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    When the interfaces identified in section 11.1.5 are updated to be local interfaces, any destroy() o

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

Implementation of get_component

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

    2. Implementation of get_component with separate ORB and component vendors
    Problem: A design goal of the components specification was to permit the component container to be provided by a different vendor than the ORB vendor. When this is true, how does the implementation of get_component work?

  • Reported: CPP 1.1 — Wed, 12 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    closed issue, resolved

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

New IDL keywords

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

    Problem: The new IDL keywords use mixed case, rather than the lower case style used by current keywords. Should the new keywords be changed to comply with the existing style?

  • Reported: CPP 1.1 — Wed, 12 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Yes, new IDL keywords should be changed to conform to existing style guide.

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

CORBA IR METAMODEL

  • Legacy Issue Number: 3207
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    1) The isBasic Attribute needs to be removed from HomeDef to synchronize
    with the regular CORBA IR.

  • Reported: CPP 1.1 — Tue, 11 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    resolved

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

Is the ccm_home method shown in Table 8-1 a typo?

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

    Table 8-1 shows a mapping for CCMObject::get_home. It looks like it should
    say CCMObject::get_ccm_home

    Proposal:

    Change "CCMObject::get_home" to "CCMObject::get_ccm_home" in Table 8-1.

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    No Data Available

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

Do EJB-mapped attributes go to the ComponentDefault interface?

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

    When mapping EJB set/get methods to a CCM view, it is not clear whether the
    resulting IDL attributes belong on the ComponentDefault interface or on the
    component definition itself

    Issue:
    Set/get method pairs on the EJB remote interface map to IDL attributes, but
    do these attributes end up in the XXXDefault interface or in the XXX
    component definition? Section 8.2.1.2 of the specification seems to imply
    they belong in the XXXDefault interface, but section 5.3.2 says the
    component definition for a basic CCM "shall only contain zero or more
    attribute declarations", which suggests that attributes of a CORBA
    Component belong in the component definition. Also, the mapping in the
    other direction (EJB view of a CCM), described in 8.3.1, suggests that CCM
    attributes are always found in the component definition itself. It appears
    that both versions will work, but this point is worth clarifying.

    Proposal:
    Change 8.2.1.2 to say that all EJB set/get method pairs are mapped to IDL
    attributes on the component definition itself.

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    resolved

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

What's the return type of CCM mappings of EJB finder and creator methods?

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

    Summary:

    8.2.1.2 of the CCM specification says that EJB finder and creator methods
    which return an RMI object reference are mapped to methods which return a
    Components::CCMObject reference. It is unclear whether the actual base
    class CCMObject is intended or whether the specific component subclass
    (e.g., Widget) is intended. The specific subclass seems more sensible,
    and is consistent with the equivalent IDL mappings shown in section 5.8.4.

    Proposal:

    Change 8.2.1.2 to make it clear that the specific subclass (e.g., Widget)
    is the return type.

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Change 8.2.1.2 to make it clear that the specific subclass (e.g., Widget) is the return type

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

How is CCMHome::get_home_def mapped to EJB operations?

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

    Chapter 8 omits to mention how the CCMHome::get_home_def call is mapped by
    the bridge at runtime to an EJB operation.

    Issue:
    The very similar call CCMHome::get_component_def is shown as mapped to the
    EJBHome.getEJBMetaData operation, but there is no mapping shown for
    CCMHome::get_home_def. It appears that get_home_def could be also be
    implemented using the EJBHome.getEJBMetaData operation, and if necessary,
    with the help of Java introspection.

    Proposal:
    Add a line in Table 8-1 to show CCMHome::get_home_def mapped at runtime to
    EJBHome.getEJBMetaData.

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Add a line in Table 8-1 to show CCMHome::get_home_def mapped at runtime to EJBHome.getEJBMetaData

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

CCM Issue: How are standard EJB exceptions mapped into the CCM View

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

    Chapter 8 of the spec specifies mappings between EJB operations and their
    equivalents in the CCM view, but it leaves the mappings of standard EJB
    exceptions unclear.

    Issue:
    Create methods on an EJB home interface all throw the standard
    javax.ejb.CreateException; finder methods on the EJB home interface all
    throw the javax.ejb.FinderException; and remove methods on both home and
    remote interfaces all throw the javax.ejb.RemoveException. In a few cases
    chapter 8 gives an implied mapping: for example, the FinderException on the
    findByPrimaryKey method seems to map to either the
    Components.UnknownKeyValue exception or to the Components.InvalidKey
    exception on the equivalent find_by_primary_key CCM method. Even in these
    cases the names are sometimes inappropriate. In the majority of cases,
    however, there is simply no CCM equivalent to the EJB exception, and bridge
    implementors are left to wonder whether they should attempt a non-standard
    mapping.

    Proposal:
    (a) Add the new CCM standard exceptions Components.CreationFailure,
    Components.NotFound, and Components.RemovalFailure
    (b) Add Components.CreationFailure to the raises clause of all create
    methods on implicit and explicit home interfaces
    (c) Add Components.NotFound to the raises clause of
    find_by_primary_key on implicit home interfaces, and to the raises clause
    of all finder methods on explicit home interfaces
    (d) Add Components.RemovalFailure to the raises clause on the remove
    operation on implicit home interfaces, to the CCMObject.remove operation,
    and to the CCMHome.remove_component operation
    (e) Specify in chapter 8 that the EJB Finder exception is always
    mapped to Components.CreationFailure; that the EJB CreateException is
    always mapped to Components.CreationFailure; and that the EJB
    RemoveException is always mapped to Components.RemovalFailure.
    (f) Make explicit in chapter 8 the already implied mapping bewteen the
    EJB DuplicateKeyException and the Components.DuplicateKeyValue exception

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    No Data Available

  • 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 ( 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

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

CCM Issue: Is CCMObject::remove intended to be available to the CCM client?

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

    Section 5.12.1 of the spec can be interpreted to mean that the
    CCMObject::remove call is not intended for use by CCM clients; but this is
    inconsistent with the EJB/CCM mapping given in chapter 8.

    Issue:
    The explanation given for the CCMObject::remove call in section 5.12.1 is:
    "This operation is called when a component is about to be destroyed.
    The component
    can perform any cleanup processing required (e.g. releasing resources)
    prior to its
    destruction."
    This explanation can be interpreted to mean that the call is a private call
    from a CCM container to one of its components; if it has this internal
    purpose then it might not be
    intended for use by CCM clients wanting delete the component. However,
    table 8-1 shows that the CCM view of an EJB maps this call to the
    EJBObject.remove()
    method. This implies that the method is intended for client use as the
    EJBObject.remove() is. If so, then it also makes more sense to implement
    the
    CCMHome::remove() method in terms of the EJBObject.remove() method, rather
    than the current mapping which requires an EJB Handle.

    Proposal: (a) Change the text for remove() in 5.12.1 to say: "This
    operation is used to delete a component".
    (b) Change the mapping in table 8-1 for CCMHome::remove to use
    EJBObject.remove

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Change the text for remove() in 5.12.1 to say: "This operation is used to delete a component".

  • 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 - 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

Policies not locality-constrained?

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

    Summary: the current spec doesn"t list policy objects as locality constrained.
    This seems rather strange. In particular, at the time I create policy objects,
    there is no POA that could be responsible for them, and I have no way
    to associate a policy object with a particular POA.
    Of course, this raises the question of whether references to policy objects
    are persistent or transient, whether I can pass them to another address
    space, whether requests on them are single-threaded or not, etc, etc.

  • Reported: CPP 1.0 — Fri, 16 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close, no change (for 2.4).

  • 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

Locality-constrained objects

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

    Summary: something about locality-constrained objects... The spec says that LC objects
    are local, so I cannot pass reference to another process or use
    object_to_string with them. There are no other restrictions so, by
    implication, LC objects can do everything a normal object can do. In paricular,
    I can invoke operations on LC objects via the DII, I get preinvoke and
    postinvoke calls from a servant locator, and the reference for an LC object
    and its servant have independent life cycles.

    This seems rather strange.

  • Reported: CORBA 2.2 — Sun, 10 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    close, no change

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

Locality constrained objects + externalization

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

    Summary: Here"s an interesting question. How do you prevent the externalization of
    an l-c object? The user can create a reference to the l-c object before
    the l-c object has been bound to the POA itself. This means that the
    reference can be externalized, and calls could presumably come into
    the POA for this l-c object. What should the result of this call be?
    OBJECT_NOT_EXIST?

  • Reported: CORBA 2.2 — Wed, 11 Nov 1998 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4
  • Disposition Summary:

    issue closed, no change

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

wchar alignment in GIOP 1.2

  • Legacy Issue Number: 4007
  • Status: closed  
  • Source: Borland Software Corporation ( Vishy Kasar)
  • Summary:

    I have a question on the octet alignment requirement for wchar as
    mentioned in Table 15-1 of CORBA 2.3. In 15.3.1.6 the spec states that

    "For GIOP version 1.2, wchar is encoded as an unsigned binary octet
    value followed by the octet sequence representing the encoded value of
    the wchar. The initial octet contains a count of the number of elements
    in the sequence and the elements of the sequence of octets represent the
    wchar, using the negotiated wide character encoding"

    If this is a variable length octet sequence anyway, specifying an octet
    alignment for this does not make sense. Our assumption is that alignment
    is specified only for GIOP 1.1 style wchars and is irrelevant for
    GIOP 1.2 style wchars. I am looking for confirmation of that assumption.

    If that is a valid assumption, shall we change the table 15.1 third row
    first column entry to state "wchar (in GIOP 1.1)" instead of "wchar"?

    If that is not a valid assumption, what are we aligning here? The length
    byte? The elements of octet sequence? What is the benefit of any
    aligning in this case?

  • Reported: CORBA 2.4 — Tue, 31 Oct 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close with revision

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

Is padding necessary for empty Reply body?

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

    The Interop RTF added text that explicitly states that padding for a
    Request body in GIOP 1.2 is not necessary if the body is empty. No
    equivalent text was added for empty GIOP 1.2 Reply bodies.

  • Reported: CPP 1.1 — Fri, 25 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Agree to add equivalent text for reply bodies.

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

Small optimization for the GIOP header

  • Legacy Issue Number: 3708
  • Status: closed  
  • Source: University of California, Irvine ( Carlos O'Ryan)
  • Summary:

    I think I found a possible (very minor) optimization for the
    GIOP 1.3 spec, but maybe I'm missing something in GIOP 1.2

    The new <target> field on the RequestHeader_1_2 structure is
    always aligned to a 4 byte boundary, the reserved[3] field ensures
    that. Consequently the discriminant for the TargetAddress union
    does not end on a 4 byte boundary, but will require 2 bytes of padding
    following it, since all the union values in this case start on 4 byte
    boundaries.

    IMHO, using just 1 byte for the reserved[] field, would have
    resulted in more natural alignments. Did I get something wrong here?
    Is this something likely to be fixed in GIOP 1.3?

  • Reported: CPP 1.1 — Fri, 16 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this issue as too much of a change for this RTF, and add it to the GIOP wish list for future p

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

GIOP _get_domain_managers ambiguous

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

    In GIOP, the _get_domain_managers operation name is used to indicate
    an invocation of the get_domain_managers pseudo operation. OTOH, it is
    also used if an attribute domain_managers is accessed, as it would
    appear in

    interface I

    { readonly attribute long domain_managers; }

    ;

  • Reported: CPP 1.1 — Fri, 18 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Changing the object reference operation on the wire to _domain_managers fixes the problem stated.

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

interop issue: CodeSets service context in GIOP 1.0 request

  • Legacy Issue Number: 3681
  • Status: closed  
  • Source: Xerox ( Bill Janssen)
  • Summary:

    Well, a new Java release is upon us, and with it comes a new CORBA
    implementation. I'm trying Java 2 SE 1.3 CORBA clients against an ILU
    2.0beta1 CosNaming server, and we find that the Java ORB cannot
    reliably connect to the server. Why not? First, we must analyze the
    IOR provided by the ILU service:

    IOR:000000000000002849444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F6E746578743A312E300000000002000000000000002F0001000000000016776174736F6E2E706172632E7865726F782E636F6D00270F0000000B4E616D6553657276696365000000000100000024000100000000000100000001000000140001001800010001000000000001010000000000

    If we look at this (those who've received it un-truncated) we find that it advertises the following:

    _IIOP_ParseCDR: byte order BigEndian, repository id <IDL:omg.org/CosNaming/NamingContext:1.0>, 2 profiles
    _IIOP_ParseCDR: profile 1 is 47 bytes, tag 0 (INTERNET), BigEndian byte order
    _IIOP_ParseCDR: profile 2 is 36 bytes, tag 1 (MULTIPLE COMPONENT), BigEndian byte order
    (iiop.c:parse_IIOP_Profile): bo=BigEndian, version=1.0, hostname=watson.parc.xerox.com, port=9999, object_key=<NameService>
    (iiop.c:parse_IIOP_Profile): encoded object key is <NameService>
    (iiop.c:parse_IIOP_Profile): non-native cinfo is <iiop_1_0_1_NameService@tcp_watson.parc.xerox.com_9999>
    (iiop.c:parse_MultiComponent_Profile): profile contains 1 component
    (iiop.c:parse_MultiComponent_Profile): component 1 of type 1, 20 bytes
    (iiop.c:parse_MultiComponent_Profile): native codeset for SHORT CHARACTER is 00010001, with 0 converters
    (iiop.c:parse_MultiComponent_Profile): native codeset for CHARACTER is 00010100, with 0 converters

    That is, there's a vanilla Internet profile (bo=BigEndian,
    version=1.0, hostname=watson.parc.xerox.com, port=9999,
    object_key=<NameService>), plus a Multicomponent profile, noting that
    the ILU ORB's native codesets are Latin-1 and UCS-2.

    OK, great. Now we get the first message from the Java ORB:

    0000 47 49 4f 50 01 00 00 00 00 00 01 00 GIOP........
    0000 00 00 00 02 00 00 00 01 00 00 00 0c 00 00 00 00 ................
    0010 00 01 00 20 00 01 01 00 00 00 00 06 00 00 00 90 ... ............
    0020 00 00 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e .......(IDL:omg.
    0030 6f 72 67 2f 53 65 6e 64 69 6e 67 43 6f 6e 74 65 org/SendingConte
    0040 78 74 2f 43 6f 64 65 42 61 73 65 3a 31 2e 30 00 xt/CodeBase:1.0.
    0050 00 00 00 01 00 00 00 00 00 00 00 54 00 01 01 00 ...........T....
    0060 00 00 00 0c 31 33 2e 31 2e 31 30 33 2e 36 38 00 ....13.1.103.68.
    0070 0e e9 00 00 00 00 00 18 af ab ca fe 00 00 00 02 ................
    0080 67 d5 93 95 00 00 00 08 00 00 00 00 00 00 00 00 g...............
    0090 00 00 00 01 00 00 00 01 00 00 00 14 00 00 00 00 ................
    00a0 00 01 00 20 00 00 00 00 00 01 01 00 00 00 00 00 ... ............
    00b0 00 00 00 05 01 00 00 00 00 00 00 07 53 79 6e 65 ............Syne
    00c0 72 67 79 00 00 00 00 06 5f 69 73 5f 61 00 00 00 rgy....._is_a...
    00d0 00 00 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e .......(IDL:omg.
    00e0 6f 72 67 2f 43 6f 73 4e 61 6d 69 6e 67 2f 4e 61 org/CosNaming/Na
    00f0 6d 69 6e 67 43 6f 6e 74 65 78 74 3a 31 2e 30 00 mingContext:1.0.

    Note that we are seeing a CodeSets service context, even though the
    request is GIOP 1.0. The service context specifies a TCS-C of ASCII,
    and a TCS-W of UCS-2.

    The question is, what should the server do with it?

    First of all, there seems to be no way in which the algorithm in
    section 13.2.7.6 can result in the TCS-C specified in the service
    context. So perhaps this bug should be detected and signalled back to
    the sending ORB. How? Using CODESET_INCOMPATIBLE might make sense,
    but that really doesn't flag the bug in the client-side implementation
    of the codesets determination algorithm. Perhaps a straight
    COMM_FAILURE would be better. Opinions?

    Secondly, since this is GIOP 1.0, the client could reasonably ignore
    the service context, and go ahead with using its default codeset
    (Latin-1). However, to do so risks comm failure down the line, as
    ASCII (the TCS-C assumed by the client) does not permit many Latin-1
    characters. It seems better to flag this situation up front.

  • Reported: CPP 1.1 — Wed, 5 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    close with revision. See below

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

Version and byte order changes when fragmenting messages (interop)

  • Legacy Issue Number: 3680
  • Status: closed  
  • Source: ICL ( Chris Wood)
  • Summary:

    It's occoured to me that according to the spec it's allowable for
    a message to be fragmented and have second and subsequent
    fragments change the version fields.

    Having the version change while in the middle of reading a
    wstring could cause problems, the CDR encoding of version 1.1
    strings is always two bytes longer than the corresponding 1.2
    encoding, if the version changed while in the middle of reading
    the wstring the length field would be out by two.

    Secondly if request IDs are per-protocol rather than
    per-connection (as aired in issue 3438) then the request ids of
    the fragments could interfere.

    I think an extra phrase should be added to the spec with regards
    to fragmentation, similar to the one regarding byte order:

    The version of fragments must match the version of the initial message that
    the fragment extends.

  • Reported: CPP 1.1 — Fri, 16 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close without revision since the spec was already clarified to state this.

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

selected_profile_index origin

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

    Since the index numbering of sequences is a language mapping specific issue, the origin of the selected_profile_index within the IORAddressingInfo must be specified. I assume a zero origin is meant.

    Proposed Resolution:
    Add the following sentence to the description of IORAddressingInfo (in section 15.4.2.1 of the 25 March CORBA 2.4 preliminary draft): "The first profile has an index of zero."

  • Reported: CPP 1.1 — Thu, 18 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Accept proposed solution.

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

Issue 2 -- resulting from UK comment UK-5:

  • Legacy Issue Number: 3624
  • Status: closed  
  • Source: Object Management Group ( Henry Lowe)
  • Summary:

    The UK believes the footnote to section 13.6.2, page 13-16, of CORBA
    2.3.1 (this is clause 5.6.2 with the footnote appearing on page 13 of
    DIS 19500-2) does not make sense, especially the phrase "... except
    ones that make such profiles...". The meaning of this footnote needs
    to be clarified with revised text.

  • Reported: CPP 1.1 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close without revision.

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

ORB throwing exception if it finds unknown service context

  • Legacy Issue Number: 3565
  • Status: closed  
  • Source: UBS ( Urs Kuenzler)
  • Summary:

    Why does it make sense at all to allow an ORB to throw an exception if it finds
    a service context it does not "understand"? This is not very helpful for
    interoperability. Would a sending ORB have to handle this exception and resend
    the same request without context to allow to interoperate with an ORB throwing
    BAD_PARAM in this case? If an unknown service context is sent with a reply, the
    receiving ORB would throw BAD_PARAM at the caller (even if it got a valid
    reply). The originator of the service context wouldn't even know.

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

    To close with Issue 3561 resolution to eliminate option of throwing exception

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

Absence of Wide Character Code Set

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

    CORBA is inconsistent on how to deal with the lack wide character code set
    information in an IOR and the codes set service context.

    When a server receives a service context without a wide character code set
    specified, then it is supposed to raise BAD_PARAM when it receives wide
    characters data from the client.

    However a client is supposed to raise INV_OBJREF if the IOR is missing
    from the server's native wchar code set . In CORBA 2.3, section13.7.2.6,
    "Code Set Negotiation", it says, "... a server that supports interfaces
    that
    use wide character data is required to specify its native wchar code set;
    if
    one is not specified, then the client-side ORB raises exception
    INV_OBJREF."

    This requires a client to know whether a server supports interfaces that
    use
    wide character data at the time the client receives an IOR. To determine
    this when the first IOR is received is a burdensome task. The client orb
    would be forced to apply an exhaustive examination, such scanning all of
    the
    server's IDL bindings or the contents of the IFR looking for wchar types.
    Additionally the client may need to determine if some Any might flow
    containing wchar data.

    I propose that the client's behavior be changed to match the server's. If
    any wide character data is encountered and the server's IOR was missing
    the native wchar code set, (which would cause the wide character
    transmission
    code set to not be negotiated), the client should raise BAD_PARAM.

    This will allow common marshal and demarshal code to be independent of
    whether it is running as a client or server. It also allows users to not
    configure
    wide character code sets if they know they aren't using them.

  • Reported: CPP 1.1 — Fri, 21 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    The check should be able to be done at invoke time by the client orb

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

Issue 1 -- resulting from Japanese comment JPN-009E:

  • Legacy Issue Number: 3623
  • Status: closed  
  • Source: Object Management Group ( Henry Lowe)
  • Summary:

    The Japanese would like to clarify the first sentence of the first
    paragraph of section 15.5.2, page 15-46, of CORBA 2.3.1 (this
    is clause 6.4.2 of DIS 19500-2, page 70) by adding the phrase
    "if Bi-Directional GIOP is not used" to the end of the sentence.
    The resulting sentence would read "Only the client (connection
    originator) may send Request, LocateRequest, and CancelRequest
    messages if Bi-Directional GIOP is not used."

    Is there any reason not to add this phrase now that Bi-Directional
    is in the OMG specification?

  • Reported: CPP 1.1 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Agree that this was an editorial oversight in corba 2.3.

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

Wrong minor code specified in Chapter 13

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

    In document ptc/00-03-02 on page 13-30 in the last bullet on that page it says: "If a system
    exception is raised , it shall be BAD_PARAM with an OMG standard minor code of 1".

    This cannot be right because the OMG standard minor code of 1 for BAD_PARAM is assigned to "failure
    to register, unregister or lookup value factory."

    I recommend that we change this minor code to a new one that is properly allocated with the
    associated text that reads something like: "Service context not understood". I am still wondering
    though why BAD_PARAM is the correct exception to raise. Wouldn't BAD_CONTEXT be more appropriate?

    In any case we have to change the minor code, even if we cannot make up our minds about which
    exception.

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

    resolved and closed

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

GIOP version and CloseConnection

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

    I believe that, at some point, we decided that it is legal to send
    request for different GIOP versions over the same connection. Could someone
    please confirm or deny? (My memory is a bit hazy on the details.)

    At any rate, careful scrutiny of the spec does not reveal any words that would
    either state that separate connections must be used for different GIOP versions
    or that they can share a single connection. A definite statement is required
    either way.

    Assuming that different GIOP versions can indeed coexist on the same
    connection, we get an interesting problem: for GIOP 1.0 and 1.1, the spec
    disallows a client to send a CloseConnection message; for GIOP 1.2, it
    requires the client to send a CloseConnection message. This begs the question:
    if different GIOP versions can coexist on the same connection, it becomes
    impossible to achieve orderly connection shutdown. Sending a CloseConnection
    message is illegal for GIOP 1.0 and 1.1, whereas it is required for
    GIOP 1.2... So, what's the client to do if multiple GIOP versions are used
    over the same connection?

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

    To close with revision

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

Valuetype in anys. Unmarshaling problem?

  • Legacy Issue Number: 3434
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    There seems to be a problem with valuetypes contained in anys.

    Consider the following:
    valuetype A

    { A a; }

    ;

    valuetype B : A

    { private long long x; }

    ;

    If an instance w/ the following structure:

    A { a = {B { x = {<value>}}}}

    is inserted into an any and the any is received by an event service. Given that
    the event service has no type information of the B encoded inside of A, the
    event service has no way of knowing how big A.a (an instance of B) is and how
    many bytes it needs to read (unless it contacts an IR)

    Am I missing something here?

  • Reported: CPP 1.1 — Mon, 20 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this issue and place it into the GIOP wish list for future enhancements to GIOP.

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

Nesting depth in valuetype end tags

  • Legacy Issue Number: 3526
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    Section 15.3.4.5 contains an inconsistency in the description of how end tags
    for valuetypes are written. Consider the case where an unchunked value (V)
    contains a chunked value (CV1). Should the end tag for CV1 contain a nesting
    depth of -2 or -1?

    The following sentence in the spec seems to imply that the correct value is -2:

    > The end tag is a negative long whose value is the negation of the absolute
    > nesting depth of the value type ending at this point in the CDR stream.

    However the spec also says:

    > The outermost value type will always be terminated by an end tag with a
    > value of -1.

    which is not true if the end tag for CV1 is written as -2, since no end tag
    with a -1 value will be written.

    Proposed resolution:

    Delete the second above sentence from the spec.

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

    Close with revision using alternative A above.

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

Valuetype encoding grammar in 15.3.4.7 is wrong

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

    The valuetype encoding "grammar" in 15.3.4.7 is wrong. The rule for
    <state> should be:

    <state> ::= <octets> |<value_data>* [ <end_tag> ]

    to allow for valuetypes with no state and therefore no value chunks.

    -

  • Reported: CPP 1.1 — Wed, 29 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    to close with revised text

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

IIOP 1.2 Early Reply message in presence of fragmented Request

  • Legacy Issue Number: 3409
  • Status: closed  
  • Source: ICL ( Chris Wood)
  • Summary:

    It is unclear in the spec when reply messages are allowed when a fragmented
    send message is sent.

    It is possible to know that a system exception will occour before the last
    fragment in a message is recieved, for example the request can be
    demultiplexed to discover the object does not exist, or the appropriate
    service contexts are not present.

    It should be legal to send a reply containing anything but a NO_EXCEPTION or
    USER_EXCEPTION before the last fragment is recieved.

  • Reported: CPP 1.1 — Wed, 8 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    close without revision

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

Marshaling fixed-point decimal types

  • Legacy Issue Number: 3431
  • Status: closed  
  • Source: Oracle ( Stefan Bauer)
  • Summary:

    Looking at formal/99-10-07, 15.3.2.8 which describes marshaling of fixed
    types I ran into a question. The section doesn't mention how to indicate
    the scale of the written decimal.

    My understanding is that the TypeCode of kind fixed, which gets written
    before the value, indicates the maximum number of digits and the maximum
    scale, not what is currently contained in the number. To describe the
    current scale I would expect that a decimal point gets written to the
    stream, just like the decimals into the half-octets as described in
    15.3.2.8.

  • Reported: CPP 1.1 — Thu, 16 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close with no Interop Revision

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

Indirection for value types

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

    Section 15.3.4, page 15-18:

    The encoding used for indirection is the same as that used for
    recursive TypeCodes (i.e., a 0xffffffff indirection marker
    followed by a long offset (in units of octets) from the beginning
    of the long offset).

    [...]

    Indirections may refer to any preceding location in the GIOP
    message, including previous fragments if fragmentation is used.
    This includes any previously marshaled parameters.

    The beginning of the section ("is the same as that used for recursive
    TypeCodes") is in conflict with what appears at the end ("refer to any
    preceding location in the GIOP message [...]. This includes any previously
    marshaled parameters.")

    This is incorrect because the indirection for type codes does not permit
    indirections that span type code boundaries (page 15-27):

    The indirection applies only to TypeCodes nested within
    some "top-level" TypeCode. Indirected TypeCodes are not
    "freestanding," but only exist inside some other encoded TypeCode.

    I would suggest to rephrase the first part of what is on page 15-18
    to avoid saying that the indirection is the same as for type codes
    because that's simply not the case.

  • Reported: CPP 1.1 — Fri, 11 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    close with revision

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

Transferring Java exception reason string across the wire

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

    Although this is a Java-specific issue, I suspect it will have to be
    decided in interop, therefore I'd like this to be an interop issue. I've
    cc'ed java-rtf since I'm sure they'll be interested.

    System exceptions only have: minor code, completion status. Java
    exceptions all have a reason string as well. This is a potentially
    significant bit of info that is not getting transferred across the wire in
    Java ORB implementations. Our rmi over iiop customers expect this
    information.

    Our suggested solution is to create another service context for a system
    exception reason string. When a system exception occurs, on a Java server,
    the ORB places the reason string into this service context on the reply
    message. On a Java client, the ORB checks for and extracts this string and
    uses it when creating the system exception instance which is propagated to
    the application code. If the service context doesn't exist, the Java ORB
    just does what it does today. Any other client bindings may ignore this
    service context.

    Java bindings do not need to change for this proposal.

    To be more precise (sorta), we need three things:
    1. A new service context ID

    const ServiceId SystemExceptionReason = TBD;

    2. The context data associated with this ID is a CDR encapsulation of a
    string.
    3. Some verbage somewhere describing this.

  • Reported: CPP 1.1 — Tue, 21 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed/resolved

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

Preserving unencapsulated information

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

    Page 15-50 of 2.3.1:

    ORBs that suport only version 1.1. or 1.2 IIOP profiles must
    ignore, but preserve, any data in the profile that occurs
    after the components member.

    A 1.2 ORB is obliged to ignore, but preserve, any information that follows
    the components member in 1_1 profile body. I think the cost of implementing
    this is quite high. What follows after the components member is not in
    a separate encapsulation. So, an ORB that receives an IOR that indeed has
    data after the components member doesn't understand anything about that data
    and therefore must treat it as a blob of bits.

    However, the IOR might be little-endian and the receiving ORB might be
    big-endian. When the receiving ORB wants to send the IOR back out, it
    can't send it as a big-endian IOR because it can't know how to byte-swap
    the data that follows the components member. That means that a big-endian
    ORB is obliged to remarshal the IOR back as a little-endian IOR.
    That's inconvenient, to say the least.

    I don't think it makes sense to require an ORB to preserve something that
    is not encapsulated, simply because the cost of doing this is high.
    (The ORB has to keep a copy of the marshaled profile around because of
    the trailing bit it doesn't understand.)

  • Reported: CPP 1.1 — Thu, 17 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close with revision

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

Should an ORB be allowed to drop non-standard profiles

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

    Part 2: Should an ORB be allowed to drop non-standard profiles (as it is allowed
    to, indeed almost encouraged to do in GIOP/IIOP 1.2) even though it is not faced
    with any resource contraints. Moreover, when it is faced with resource
    contraints should it be required to follow a specific sequence in determining
    what profiles to drop.

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

    The proposed resolution defines two possible IOR conformance classes for every ORB interoperability

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

An ORB should not accept an IOR with no usable profiles

  • Legacy Issue Number: 3303
  • Status: closed  
  • Source: Xerox ( Bill Janssen)
  • Summary:

    ORBs should be required to reject IORs that do not contain any profile that the ORB can use

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

    accomodated by proposed change from Issue 3234.

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

Supporting TAG_MULTIPLE_COMPONENTS

  • Legacy Issue Number: 3176
  • Status: closed  
  • Source: Borland Software Corporation ( Vishy Kasar)
  • Summary:

    I have a question on how can ORB vendor support profile with ID
    TAG_MULTIPLE_COMPONENTS? The spec 2.3/13.6.2 says single profile holds
    enough information to drive a complete invocation. Let us say we have an
    IOR with one profile and the ID is TAG_MULTIPLE_COMPONENTS. As per
    13.6.2.2, the profile body in this case contains a
    MultipleComponentProfile. Let us again assume that there is only one
    TaggedComponent with component id of TAG_CODE_SETS and its component
    data.

    What we have here is a legal profile with no end point information. What
    can a ORB do with such a profile? Is there any thing broken here or did
    I just misinterpret the spec completely?

  • Reported: CPP 1.1 — Tue, 4 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close with no revision

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

CORBA 2.3.1 missing text describing the response_expected field

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

    When the response_flags text was added for GIOP 1.2 Request processing,
    the old text for the GIOP 1.0 and 1.1 response_expected field was
    removed. Thus, the current documentation no longer completely describes
    the GIOP 1.0 and 1.1 protocols.

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

    to close with revision

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

chunked value encoding:

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

    a chunk can be followed by:

    1. a new chunk (starting with its size tag)
    (1 <= chunk_size_tag < 0x7fffff00
    2. a new value (value_tag | 0 | value_ref)
    (0x7fffff00 <= value_tag <= 0x7fffffff)
    (valueref = 0xffffffff)
    3. an end tag
    (0x80000000 <= end_tag <= 0xffffffff)

    A value indirection and a "top-level" end tag, both have the same tag (0xffffffff).
    Consequently, the 0xffffffff tag marks the end of the current value but it is not clear whether or not a new value (indirection) has started.

    An example where this situation occurs is a ring buffer that is chunked encoded.

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

    to close with revision

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

Validity of object references

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

    Section 15.4.5, page 15-39:

    LocateRequest messages may be sent from a client to a server to
    determine the following regarding a specified object reference:

    • whether the object reference is valid

    In the absence of a definition for how to judge a reference "valid", this
    is a meaningless statement.

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

    close with revision

  • 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

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

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

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

GIOP encoding of nil Abstract Interface is unspecified

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

    Summary: Section 15.3.7 of 98-12-04 discusses the encoding of abstract
    interfaces, but neglects to mention how to encode an abstract
    interface whose value is nil.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    see above

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

.Passing the interface repository ID of the method in IIOP

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

    Summary: If we had a repository ID on the wire with every request, such errors could
    > be caught. In addition, it would make it substantially easier to build
    > tools such as IIOP packet tracers – right now, it is next to impossible
    > to dump the parameter values of IIOP requests because the packet tracer
    > has no way of figuring out what the type of the target object is.

    This could be added to IIOP in a reasonably non-invasive way, too. We
    could add a service context to the request which would carry the
    repository ID of the interface in which the method was defined

  • Reported: CORBA 2.2 — Mon, 5 Oct 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

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

TAG_ENDPOINT_ID_POSITION and TAG_LOCATION_POLICY

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

    Summary: Is there any particular reason that we shouldn"t allow these two
    ComponentIds in IIOP IORs? They certainly can be useful using IIOP for
    optimization of client/server interactions, and can be safely ignored by
    clients that don"t implement/understand them.

    So could we add text to the spec that states that these components are
    allowed in IIOP IORs, but the clients are free to ignore them?

  • Reported: CORBA 2.2 — Mon, 4 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

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

Chunked GIOP marshalling for variable-length types

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

    Summary: Following the discussion of valuetype chunking in the OBV group, I"ve
    been thinking that the arguments advanced for it really apply to all
    the other variable-length types in CORBA (sequences and strings) as
    well as to OBV value types, and wonder if we might try a small change
    to the marshalling rules.

    Currently, we marshal a string (say) by sending the length of the
    string followed by the bytes of the string. If we don"t know the
    string"s length in advance, say because we are reading it from stdin
    or a subprocess, we need to buffer it in memory and send it as one big
    thing. That"s inefficient.

  • Reported: CORBA 2.2 — Tue, 14 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

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

Compacting GIOP messages by using indirections

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

    Summary: Repeated strings within an encapsulation can account
    for a large percentage of the size of the encapsulation.
    Indirections are already used in the marshaling of TypeCodes
    to allow compacting of messages. This can be extended
    to also allow indirection for strings. The current
    encoding of a string is the unsigned long number of characters
    in the string, followed by the null-terminated characters
    comprising the string. If we resolve the maximum value
    for unsigned long "0xffffffff" for indirections, the
    next byte can refer to a previously marshaled string.

  • Reported: CORBA 2.2 — Thu, 2 Apr 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close previously deferred issue as too much for RTF. Add to GIOP future version "wish list".

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

Compacting GIOP Messages by using templates

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

    Summary: A common server pattern is that of "factory". As a result
    of a request, a Factory returns an object reference.
    Frequently, these object references differ only by a
    small fraction of their full size. For example, object
    references may be exactly the same except for the object_key
    member of a GIOP profile and maybe the repository_id field
    of the IOR. Allowing the factory to return a more compact
    representation of the object reference would yield great
    savings in message size.
    If the server or client can establish a template for filling
    out object references (or possibly any type of data), a
    more compact on-the-wire form can be used for such object
    references once the template is established.

  • Reported: CORBA 2.2 — Thu, 2 Apr 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

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

Compacting GIOP Requests by hashing down operation names

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

    Summary: As of GIOP/IIOP 1.1, a Request identifies the operation to
    be invoked as a string. If this can be compacting to
    an integral value, savings would be possible on all
    subsequent requests. A simple solution would involve
    a service context containing "operation name to index"
    mappings.

  • Reported: CORBA 2.2 — Thu, 2 Apr 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" st

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

Optimization of LOCATION_FORWARD replies

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

    Summary: As of GIOP/IIOP 1.1, if a server wants to have a client
    use some locally hashed down object_key in future requests
    for an object, it must require one of the following:
    a) the client use a LocateRequest in order for the server
    to reply with a forwarded object reference that has
    a hashed down object key.
    b) respond with an OBJECT_FORWARD reply to the request,
    forcing the client to remarshal the request with the
    new target (the forwarded object reference"s key).
    With some already recommended changes to GIOP 1.1,
    such a reply will only require remarshaling the
    message header, but an extra roundtrip is still required.

    This could be avoided by addind a new service context
    to the reply that contains the forward IOR, or a new
    Reply type such as NO_EXCEPTION_AND_FORWARD that
    indicates the first request has succeeded and that
    subsequent requests can use the supplied forward IOR.

  • Reported: CORBA 2.2 — Thu, 2 Apr 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

  • 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

"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

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

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

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

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

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

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

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

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

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

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

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

Pragma version 2.3

  • Key: CORBA24-96
  • Legacy Issue Number: 3694
  • Status: closed  
  • Source: Objective Interface Systems ( 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

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

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 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

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

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

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

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

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

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

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 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

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

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

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

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

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

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

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

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

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

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

#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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Component ids in 13.6.2.2

  • Key: CORBA24-25
  • Legacy Issue Number: 2913
  • 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 — Tue, 28 Sep 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

(CORBA Core) Data streams missing arrays of long double

  • Key: CORBA24-24
  • Legacy Issue Number: 2912
  • Status: closed  
  • Source: Oracle ( Dan Frantz)
  • Summary:

    DataInputStream and DataOutputStream (CORBA 2.3, Section 5.5.2) has
    definitions for reading and writing individual items and arrays of
    primitive data types except long double. This seems to be an
    oversight.

  • Reported: CORBA 2.3 — Wed, 22 Sep 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 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

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

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

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

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

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

DynFixed editorial issue

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

    In the CORBA 2.3 spec for DynFixed::set_value (page 9-14) it says, "If val
    contains a value whose scale exceeds that of the DynFixed or is not
    initialized, the operation raises InvalidValue."

    Later in the same paragraph it says, "If val has more fractional digits
    than can be represented in the DynFixed, fractional digits are truncated
    and the return value is false."

    Given that the term "scale" is used with the fixed-point type to describe
    the number of fractional digits, these two quoted sentences are confusing
    and appear to contradict one another.

    I propose changing the first quoted sentence to: "If val contains a value
    whose number of digits exceeds the maximum number of digits specified by
    the TypeCode of the DynFixed, or if val is not initialized, the operation
    raises InvalidValue."

  • Reported: CORBA 2.3 — Wed, 29 Sep 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

POA exception minor codes

  • Key: CORBA24-11
  • Legacy Issue Number: 2861
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are several cases in the POA specification where the POA is required to
    raise system exceptions. We should assign OMG minor exception codes to
    each of these cases so that applications can diagnose these conditions
    better.

    Examples:

    1. POA has the USE_DEFAULT_SERVANT policy but no servant is assigned, the
    POA raises OBJ_ADAPTER.

    2. If no adapter activator is available (or the available one refuses to
    create a POA), the OBJECT_NOT_EXIST exception is raised.

  • Reported: CORBA 2.3 — Tue, 31 Aug 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

DataInputStream specification is inefficient for Java

  • Key: CORBA24-12
  • Legacy Issue Number: 2892
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This issue is for the Core RTF. Although it shows up in the context of Java,
    fixing it requires a change to an API defined in the CORBA core.

    The CORBA::DataInputStream type (part of the CORBA core) is specified in
    a way that makes it extremely inefficient to implement in Java. A small
    change to this IDL definition would reduce the number of Java classes needed
    to implement it from 27 to 1. (Really!)

  • Reported: CORBA 2.3 — Fri, 17 Sep 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

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

CORBA 2.3: minor editorial issue

  • Key: CORBA24-9
  • Legacy Issue Number: 2849
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 4-5 of CORBA 2.3 the deprecated create_recursive_sequence_tc
    operation is missing its open parenthesis for its parameter list.

  • Reported: CORBA 2.3 — Fri, 13 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Wchar as discriminator in union

  • Key: CORBA24-10
  • Legacy Issue Number: 2859
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Just got a question from our IDL compiler folks - I think they"ve
    found a bug in the 2.3 IDL chapter..... (actually the bug has been there
    for a while)..

    Looking at the new CORBA2.3 book,

    The syntax for discriminated unions are described on two pages (3-16 and
    3-36).
    On both pages the <wchar_type> isn"t included in the grammar for
    <switch_type_spec>. Therefore my conclusion was that it shouldn"t be
    allowed. The problem is that further down on page 3-36 there is a table
    for "case label matching" and in that table wchar is listed as a
    discriminator type.

    So, was the wchar type forgotten from the grammar for switch type spec,
    or
    was wchar mistakenly added to the table?

  • Reported: CORBA 2.3 — Thu, 26 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

chapter 3 and recursion

  • Key: CORBA24-8
  • Legacy Issue Number: 2848
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA 2.3, chapter 3, section 3.10.2, page 3-35 says: "Although the IDL
    syntax allows the generation of recursive constructed type specifications,
    the only recursion permitted for constructed types is through the use of
    the sequence template type." With the introduction of valuetypes, this is
    no longer true. A valuetype is allowed to have a member of its own type,
    either directly or indirectly.

  • Reported: CORBA 2.3 — Fri, 13 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

ambiguity in wstrings having a Unicode escape sequence

  • Key: CORBA24-7
  • Legacy Issue Number: 2847
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: According to the spec, a wide string may contain one or
    more Unicode escape sequences of the form \uxxxx, where
    the x"s are hex digits. It also says that such an
    escape sequence may not have the value 0, and that
    leading 0s are optional in the hex digits.
    Taking all this into account, how does a parser
    tell the difference between (imaginary parentheses
    inserted to show the writer"s intent)

  • Reported: CORBA 2.3 — Fri, 13 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

interop issue: what system exceptions may be raised on GIOP 1.0?

  • Key: CORBA24-2
  • Legacy Issue Number: 2819
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: An issue we"ve run across is enumerating the set of system exceptions
    that are valid to be passed via GIOP 1.0 (and similarly for 1.1, and
    1.2). This is important for implementations of GIOP, which are, for
    instance, attempting to map wire exceptions to C++ exceptions, and is
    also important for packet-sniffing implementations.

    Since many conforming GIOP 1.0 implementations were built (and bought)
    and incorporated into products before various CORBA system exceptions
    were added to the Core, it seems that servers should not raise `newer"
    exceptions back to older clients – that is, clients speaking GIOP 1.0.
    Instead, they should map those `newer" exceptions to UNKNOWN, I"d guess.

  • Reported: CORBA 2.3 — Wed, 21 Jul 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

mixing giop versions

  • Key: CORBA24-3
  • Legacy Issue Number: 2822
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The spec is currently unclear on when and how messages with different
    giop versions may share a single connection.

    This has already been discussed, with different RTF members holding
    positions running the range from: "all messages on a connection must
    have the same giop version" to "messages with differing giop versions
    must be permitted on the same connection". So clearly there is an issue.

    The resolution of this issue should address at least the following
    unclear points:

    1) suppose a client orb supporting giop 1.2 initiates an invocation on
    an IOR with iiop version 1.1. As a result, it establishes a new
    connection and sends the request using giop 1.1. Later, the same client
    obtains another IOR referencing the same transport address, but
    specifying iiop version 1.0.

    • may the same connection be used to send a request to the new IOR?
    • if so, what giop version should be used to send the request?

    2) Later, the same client obtains another IOR referencing the same
    transport address, but specifying iiop version 1.2.

    • may the same connection be used to send a request to the new IOR?
    • if so, what giop version should be used to send the request
    • if so, what giop version should be used to send subsequent requests
      to the IORs mentioned in (1).

    3) Imagine a day in the not too distant future, when giop 1.3 has been
    approved and implemented. A client that supports giop 1.3 obtains an IOR
    with iiop version 1.2, establishes a new connection, and then sends a
    request using giop 1.2. A service context offering bidirectional giop is
    sent with this request, and accepted by the server. The client provides
    the server (that supports giop 1.3) with a callback IOR that has iiop
    version 1.3, and the server attempts to call back on it.

    • may the callback use the incoming connection?
    • if so, what giop version should the request use?
    • if so using v1.2, what if the callback request requires a feature
      only available in giop 1.3?
  • Reported: CORBA 2.3 — Mon, 26 Jul 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

POA: false placement of paragraph

  • Key: CORBA24-6
  • Legacy Issue Number: 2846
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In CORBA 2.3, chapter 11.3.8.11 (docs/formal/99-07-15.pdf, p. 11-35):
    seems to me as if the paragraph that was added to the description of
    get_servant_manager() is really intended for set_servant_manager().

  • Reported: CORBA 2.3 — Sun, 15 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

${issue.summary}

  • Key: CORBA24-4
  • Legacy Issue Number: 2828
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: CORBA 2.3 — Mon, 2 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    resolved in interop RTF

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

OBV interface support inconsistencies

  • Key: CORBA24-5
  • Legacy Issue Number: 2844
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA 2.3 chapter 3.8.5 (docs/formal/99-07-07.pdf, p. 3-27) claims that
    a stateful value can only support a single interface.

    CORBA 2.3 chapter 5.2 (docs/formal/99-07-09.pdf, p. 5-2) claims that
    a concrete (stateful) value can support multiple interfaces.

    The latter is obviously wrong.

  • Reported: CORBA 2.3 — Sun, 15 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

The syntax for stringified IORs in section 13.6.6

  • Key: CORBA24-1
  • Legacy Issue Number: 2796
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The syntax for stringified IORs in section 13.6.6 shows: =
    "IOR:" The problem is that URL scheme names are supposed to be case
    insensitive. So, "Ior:"
    or "ioR:" should be allowed to. I would suggest to add a footnote to
    state that case for the scheme name is ignored.

  • Reported: CORBA 2.3 — Fri, 9 Jul 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