Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — All Issues

  • Acronym: CORBA
  • Issues Count: 271
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA34-428 Section 5.5 Interface repository (01) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-429 Can value type inherit from Value Box type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-415 Section 5.6.2 Repository Id CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-413 Repository Id (03) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-412 Section 5.6.3 Hashing Algorythm CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-414 Repository Id (02) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-411 Semantics of computing the hash code.. CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-416 Clarify the hash code algorithm CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-417 Type code issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-423 New lexical type - Keyword Identifie CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-424 Can Value type inherit from Value Box type? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-419 describe_value() operation issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-418 Missing member_kind and member_tc CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-425 "Safe" keyword identifier issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-426 Which TypeCode operations apply to Value and ValueBox? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-422 Section 5.3.3: can value inherit from a boxed value? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-420 Value type ansd Value Box"s single data member name CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-421 p.6.68 boxed values of complex types map to same type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-427 Section 5.5 Interface repository (02) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-407 Section 7 C++ Language mapping CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-409 Section 7.3.5 ValueBase and Reference Counting CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-408 Section 7.3.6 Reference Counting Mix-in Classes CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-410 Concrete value class CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-393 Keyword Identifiers(03) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-394 Keyword identifiers (02) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-395 Keyword identifiers (01) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-397 Can public modifier be applied to value operations? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-396 Reconcile RMI/IIOP upcall and helper class CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-402 Editorial page 8-107 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-399 Editorial: p 5-50 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-400 Suggested changes (to section 5.4.1 of orbos/98-01-18) are CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-401 p 5-24, first paragraph of 5.3.1.3 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-398 p 5-50 2nd paragraph of 5.6.2.1 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-403 Can an instance of C be passed by value to an operation that expects an A? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-404 Why is ValueBase a value and not a native type? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-406 Java mapping example and C++ mapping example CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-405 Section 7.3.10 Value Factories CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-376 TypeCodes for values CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-378 Some explicit semantics seem to be missing in section5.8.6 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-379 OBV spec inefficient for dending large number of small objects CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-381 ValueMemberSeq: What is to be done with the RepositoryID parameter? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-377 Forward declaration of value boxes CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-380 OBV C++ problem with "supports" CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-382 TypeCodes defined in section 5.8.2 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-384 OBV "chunking" CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-383 CDR Streams CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-385 Can "public" mofifier be applied to value operations? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-386 Typo on page 8-107 of OBV specification CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-390 Marshaling engine issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-388 Narrowing from abstract interfaces CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-387 "in". "out", and "inout" modifiers on value operation parameters CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-389 Sections 5.3.1.2 vs. 6.3.1: Mapping of non-public state to java private CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-391 No portable way to obtain list of type safe repository IDs CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-392 Keyword identifiers (04) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-355 passthrough connection CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-354 issue with TCPfirewallMechanism CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-353 Issue for Firewall RTF - HTTP tunnelling. CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-356 Issue for Firewall RTF - Chapter 5 needs clarification CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-357 The values of these tags need to be assigned CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-365 CodeBase interface uses undefined type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-366 Memory Management for Value Factories Unspecified CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-369 Abstract Interface issue (write_Abstract/read_Abstract)(01) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-370 P 5-44: use of base type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-367 TypeCode complexity for value types CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-368 No typecodes for abstract interfaces CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-374 Default constructor for Java values CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-371 OBV TypeCode parameters wrong CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-375 Boxed values need extension to write_Value call CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-372 C++ boxed value member clashes CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-373 Custom marshalling support for IDL fixed type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-362 "Tool" issue for IDL compilers too complex CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-363 Status of hashed repository IDs CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-361 ValueHelper Interface issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-364 OBV init CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-248 Circular References in CosStream and CosCompoundExternalization CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-223 TypedConsumerAdmin interface (4.9.2)) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-215 COM/CORBA keywords CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-218 ObjectCreationError and Nofactory exceptions in Externilazition CORBA 2.2 CORBA 3.4 Deferred closed
CORBA23-247 question re BiDir IIOP CORBA 2.2 CORBA 2.3.1 Resolved closed
CORBA23-246 New OBV "supports" keyword conflicts with CosLifeCycle CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-245 Abstract Interface issue (02) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA25-57 CORBAservices IDL CORBA 2.2 CORBA 2.5 Resolved closed
CORBA23-243 OBV TypeCode problems CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-242 Module separator within repository IDs CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-241 DynAny::get_value collision CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-240 Problem with C++ language mapping for OBV CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-239 public static org.omg.CORBA.ValueDef get_value_def(); CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-238 Clarify semantics CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-236 Grammar rule issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-237 Which exceptions should be raised? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-235 "Syntax" for grammar rule [value_inheritance_spec] ::= ":" [ safe_token ] CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-230 OBV chunk boundaries CORBA 2.2 CORBA 2.3 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
CORBA23-229 Clarification requested on GIOP 1.1 and wstring CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-228 TypeCode constants for bounded strings? CORBA 2.2 CORBA 2.3.1 Resolved closed
CORBA23-227 DynValue::get_members/set_members CORBA 2.2 CORBA 2.3.1 Resolved closed
CORBA23-226 Type code parameter ordering CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-224 OBV, value-reference substitution, Multiple Inheritance CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-223 WRONG_TRANSACTION CORBA 2.2 CORBA 2.3 Duplicate or Merged closed
CORBA23-222 Proposal on floating point fixes CORBA 2.2 CORBA 2.3 Duplicate or Merged closed
CORBA23-215 Destruction of ORB CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-214 OMG VMCID CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-213 New proposal for recursive TypeCode creation CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-212 deactivate_object page no: 9-35 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-211 Typo on pages 10-53, 10-55, and 10-70 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-210 Proposal for creating recursive TypeCodes CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-208 Missing orb.idl CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-209 Types defined in the CORBA module? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-207 Incorrect LifeCycle IDL? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-206 Size of IDL char CORBA 2.2 CORBA 2.3 Closed; No Change closed
CORBA23-205 Proposed change to IDL in section 3.10.2, page 3-32 "Parameter Declaration CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-204 CosObjectIdentity::ObjectIdentifiers can"t be UUIDs? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-203 Illegal IDL in CosTime module CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-202 TypeCode comparison proposal (02) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-200 Description of Wide String type CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-201 TypeCode comparison proposal (01) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-199 name scoping issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-198 IDL struct issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-197 Type codes cannot describe all unions CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-196 Type code operations under-specified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-195 Type code typos (as only one issue) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-194 Typo in chapter 8 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-193 Does the DII support the standard object operations? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-191 Typos in IR IDL in Specification (04) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-192 Typos in IR IDL in Specification (050 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-190 Typos in IR IDL in Specification (03) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-189 Typos in IR IDL in Specification (02) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-188 Typos in IR IDL in spec (01) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-187 / in prefix pragma? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-186 Versioning by the back door? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-185 GIOP typo, section 4.2 (page 4.4) of CORBA 2.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-184 Domain Manager related specification shortcomings (03) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-183 Semantics and standard exceptions CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-182 Forward declarations and inheritance CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-181 Indentation on page 4-4 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-180 Editorial issue, chapter 8 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-179 ORB_init CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-178 IDl "module" construct - IDL files CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-177 How to deal with object identity CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-176 Typo in type code section (13.3.4) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-174 Fixed point constants issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-173 Wide character and wide string literals CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-175 Type of fixed point quotients CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-172 Fixed point constant typo in 2.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-171 Marshalling is_equivalent CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-170 #pragma prefix issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-169 CORBA 2.2 - "native" and the interface repository CORBA 2.2 CORBA 2.3 Resolved closed
CORBA26-11 Versioning needed for CORBA Core CORBA 2.2 CORBA 2.6.1 Resolved closed
CORBA3-2 No way to detect that ORB has outstanding deferred synchronous requests CORBA 2.2 CORBA 3.0.2 Resolved closed
CORBA3-3 issue with ForwardRequest exception in POA CORBA 2.2 CORBA 3.0.2 Resolved closed
CORBA3-1 constant decls broken CORBA 2.2 CORBA 3.0.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-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
CORBA23-166 LocateRequest and LocateReply messages CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-165 CDR encoding for fixed CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-95 New "opaque" data type CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-94 DynAny::equal operator issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-93 sharing valuetypes across Anys CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-92 UNIQUE_ID and ServantActivator issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-90 deactivate_object asymmetry CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-89 ORB::shutdown again CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-86 DynAny.insert_valuetype shoud be insert_val CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-85 confusing rules for operations on Object CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-88 activate_object_with_id and exceptions CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-83 RMI style repository ID hash code CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-91 Clarification on IdUniquenessPolicy CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-84 Incorrect IDL is section 5.5.3 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-87 Repository ID for Object CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-82 forward declaration in ptc/98-10-04 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-81 LocateReply body alignment issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-80 POA issue, section 11.3.8.10 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-77 omg.org prefix not well specified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-78 Can an any with a tk_null or tk_void TypeCode be encoded with CDR? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-75 Need to specify exception for abstract interface error CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-79 POA that has IdAssignmentPolicy=SYSTEM--portability problem CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-76 Scope of SendingContextRunTime service context CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-74 Error in IRObject definition in 98-12-04 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-73 What use is CORBA::exception_type? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-71 CORBA::Object::ping ? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-72 Inconsistent Definition of Flags type CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-65 POA Construction Policy. CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-70 Inconsistent spellings of "policy" related identifiers: CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-67 Inheritance of value types CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-69 IR Changes in 2.3 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-68 What value type does ValueDef"s base_value() return? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-66 Problems in Chapter 5 IDL CORBA 2.2 CORBA 2.3 Closed; No Change closed
CORBA23-64 another problem with IDL specification section 3.9.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-63 Interceptors broken CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-61 Try to define obligatory and optional parts of the CORBA specification. CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-58 Issue - no PIDL, just language bindings CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-62 clarification and bug in InterfaceDef::FullInterfaceDescription CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-56 Calling get_response twice? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-60 Application Interface issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-59 Use UNICODE Character set CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-57 Grammar section 3.9.2 missing "float" rules, and other problems CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-55 Forward-Declared Interfaces CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-54 Value base and the IFR CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-53 Clarifications needed in section 5.2.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-50 RMI Repository ID missing from section 10.6 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-52 Clarify text in section 15.3.7 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-49 Text was inserted in wrong place CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-46 is_a description is wrong CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-47 No description for ValueBoxDef CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-51 Error in text describing TypeCode interface CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-48 Error in ValueDef IDL CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-45 No description for NativeDef CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-44 Errors in figure 10-2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-43 Signature of unmarshal method is wrong CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-37 Custom Marshaling clarification CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-40 Codebases with multiple URLs CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-42 Clarify meaning of no IDL initializers CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-38 Names of Data*Stream methods CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-39 Supporting multiple abstract interfaces CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-41 Misleading text in section 3.2.5.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-36 Missing minor code CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-34 POA threading policies CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-35 POA SINGLE_THREAD_MODEL description ambiguous CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-33 Custom marshalling & AbstractBase CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-30 is_a underspecified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-29 Local operations on CORBA::Object CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-32 Sequences of recursive structs/unions CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-31 uses of recursive_tc CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-28 Core uses both "standard" and "system" exception terminology CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-26 Need namespace for Policy Type CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-27 create_policy specification needs to be completed CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-25 Scoping resolution for member names CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-24 Typo in POA CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-23 void * in DII Chapter CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-20 Recursive exceptions? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-19 InconsistentTypeCode exception in CORBA 2.3 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-22 Exception for abstract interface inheritance CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-21 long double problem? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-16 Which OBV initialiser to run is under-specified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-18 Recursive IDL types CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-17 What does interface substitutability mean in CORBA? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-14 Missing equality for DynAny CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-15 DynUnion::member() CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-13 set_servant_manager CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-9 Multiple paths to a recursive sequence typecode CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-12 Handling of minor codes for standard exceptions underspecified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-10 Nested scopes CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-11 page 3-47: Identifiers CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-7 DynStruct::get_members needs exception CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-8 Change to IDL for anonymous types CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-6 Lifetime of ORB and validity of ORB pointe CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-5 Semantics of system exception completion_status CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-4 resolve_initial_references under-specified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-3 Domain Manager related specification shortcoming (02)-ConstructionPolicy CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-2 Domain manager related specification shortcoming(s) (01) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-1 Operation to add to CORBA::ORB pseudo-object CORBA 2.2 CORBA 2.3 Resolved closed
CPP11-136 Unknown parts of an IOR and interoperability CORBA 2.2 CPP 1.1 Resolved closed
CPP11-134 Clarification of OBV GIOP encoding rules CORBA 2.2 CPP 1.0 Resolved closed
CPP11-135 Potential interop. problem in CORBA 2.3: pseudo-operation marshalling CORBA 2.2 CPP 1.0 Resolved closed
CPP11-133 Move recently added text to correct place CORBA 2.2 CPP 1.0 Resolved closed
CPP11-131 Tagged Component interactions CORBA 2.2 CPP 1.0 Resolved closed
CPP11-132 OBV GIOP clarification needed CORBA 2.2 CPP 1.0 Resolved closed
CPP11-128 COMM_FAILURE and completion_status CORBA 2.2 CPP 1.0 Resolved closed
CPP11-129 GIOP fragment alignment issue for CORBA 2.3 CORBA 2.2 CPP 1.0 Resolved closed
CPP11-127 Typo in page 15-44 CORBA 2.2 CPP 1.0 Resolved closed
CPP11-130 Obsolete text in ptc/98-08-13.pdf CORBA 2.2 CPP 1.0 Resolved closed
CPP11-125 How to handle unexpected exceptions? CORBA 2.2 CPP 1.0 Resolved closed
CPP11-126 CloseConnection CORBA 2.2 CPP 1.0 Resolved closed

Issues Descriptions

Section 5.5 Interface repository (01)

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

    Summary: 1) ValueDefSeq is used in a couple of places but is never defined. A typedef
    for it is missing.

  • Reported: CORBA 2.2 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Can value type inherit from Value Box type

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

    Summary: 1) Can a Value type inherit from a Value Box type (the Value Box is
    described as been syntactic sugar for a Value type)? If so, what is the
    implicit name of the Value Box"s single data member?

  • Reported: CORBA 2.2 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Section 5.6.2 Repository Id

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

    Summary: It is not clear whether the #pragma prefix is still part
    of the repository Id. I think it should be.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Repository Id (03)

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

    Summary: 2) How does one find out a RepositoryID for registering a factory or a streaming
    policy?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Section 5.6.3 Hashing Algorythm

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

    Summary: Section 5.6.3 Hashing Algorithm (and 5.6.2)

    • It is not clear whether the hash value is translated
      into ascii or not.
    • I assume the result is a long long:

    long long hash = sha[1] << 32 + sha[0]

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Repository Id (02)

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

    Summary: Why is the 64 bit hash code at the end of the string and
    not at the beginning ? This can speed up the comparison
    when two repository Ids are different.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Semantics of computing the hash code..

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

    Summary: Clarify the exact semantics of computing the hash code and comparison semantics for type equivlanece. (lost email, paraphrase of issue)

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Clarify the hash code algorithm

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

    Summary: Clarify the hash code algorithm

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Type code issue

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

    Summary: TypeCodes:

    • It is not clear whether the IDL compiler has to generate
      a TypeCode object for each Value type.
  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

New lexical type - Keyword Identifie

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

    Summary: Section 5.4.2 "New lexical type - Keyword Identifier" the statement is made that
    "new keyword identifiers should only be added such that the resulting grammar is
    still easily parsable, e.g. is LALR(1).". It seems to me that is not true even for
    the newly introduced keyword identifiers in many cases.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Can Value type inherit from Value Box type?

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

    Summary: Can a Value type inherit from a Value Box type (the Value Box is described
    as been syntactic sugar for a Value type)?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

describe_value() operation issue

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

    Summary: Also, the OBV spec defines a describe_value() operation in interface ValueDef
    which returns a FullValueDescription structure. Is there supposed to be another
    operation which returns the shorter ValueDescription structure?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Missing member_kind and member_tc

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

    Summary: Missing member_kind and member_tc

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

"Safe" keyword identifier issue

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

    Summary: Above rules seem to imply that the
    "safe" keyword identifier can only occur before the first scoped name in the
    <value_parent_spec>, whereas I think the actual intent is that it can only
    occur before a non-abstract value type, of which there is at most one in the
    list, although it need not be the first. Since this can"t be expressed in the
    rules exactly, I would simply amend the rule to be:

    <value_parent_spec> ::= ":" [ <safe_token> ] <scoped_name>

    { "," [ <safe_token> ] <scoped_name> }

    *

    and simply express the semantic restriction in the text. There already is a
    brief mention of the semantics of the "safe" keyword in section 5.3.2.5
    "Substitutability Issues". Perhaps another sentence or two would help clarify
    the intended usage.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Which TypeCode operations apply to Value and ValueBox?

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

    Summary: The OBV spec (orbos/98-01-18) does not specify which TypeCode operations apply
    to Value and ValueBox types. For example, are id(), name(), member_name(),
    member_count(), member_type(), etc. valid for Value and ValueBox or should they
    raise BadKind exception?

    I don"t see why they should not be valid. Normative text should be added in
    CORBA 2.2 section 8.7.1 TypeCode Interface to reflect this and the comments in
    the IDL should also be updated.

  • Reported: CORBA 2.2 — Thu, 9 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Section 5.3.3: can value inherit from a boxed value?

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

    Summary: 5.3.3: Is it possible to have a value inherit from (ie, support) a
    boxed value ? If yes, the Java mapping of boxed values of type
    string, sequence and arrays should be changed because String
    and arrays can"t be extended in Java.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Value type ansd Value Box"s single data member name

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

    Summary: If a value type can inherit from a Boxed Value then what is the implicit name of
    the Value Box"s single data member?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

p.6.68 boxed values of complex types map to same type

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

    Summary: p.6.68: It is a bit awkward that boxed values of "complex" types map
    all to the same type (i.e., as for typedefs, the value"s name appears
    only in holder/helper classes), and that each boxed value of "basic" type
    maps to its individual class. Instead, boxed values of basic types
    could map to the corresponding java.lang.* class, e.g.
    java.lang.Integer, java.lang.Short, etc. An issue with this approach
    is that java.lang.Short and java.lang.Byte are not defined in JDK
    1.0.2. I doubt however this JDK is still much in use; for its users,
    short and octet could optionally map to e.g. CORBA.ShortValue and
    CORBA.ByteValue (inspired from CORBA::StringValue).

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Section 5.5 Interface repository (02)

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

    Summary: 2) Attribute "name" in interface ValueMemberDef clashes with attribute "name"
    inherited from Contained. A different name should be used, something like
    "value_member_name"

  • Reported: CORBA 2.2 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Section 7 C++ Language mapping

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

    Summary: According to the object-by-value C++ mapping, the value type that is
    not boxed results in an abstract C++ class. Basically, the reference
    counting methods are not provided (abstract). It is the responsibility of
    application developer to define/implement a concrete class. Althought
    this can be done, there are some issues:

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Section 7.3.5 ValueBase and Reference Counting

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

    Summary: - What is the return type of "_add_ref" and "_remove_ref"
    (defaults to "int", but what is the semantic of the result value)
    => propose to change to "void"

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Section 7.3.6 Reference Counting Mix-in Classes

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

    Summary: The default ref-counting classes are said to be "fully concrete".
    Is this really necessary?
    What is the semantic of "_copy_value" for the ref-counting class?
    => suggest that "_copy_value" MUST NOT be implemented
    (It is implemented by "_copy_value" of the real value type)

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Concrete value class

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

    Summary: I have an important issue concerning the C++ mapping and the fact
    that application developers need to define/implement the concrete
    value class.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Keyword Identifiers(03)

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

    Summary: The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
    the concept of "keyword identifiers" in an effort to avoid breaking
    existing IDL specifications. It specifies that a keyword identifier
    is a word that is treated as a keyword only when used in a keyword
    context, and is otherwise treated as a regular identifier.
    3) It allows IDL specifications that, while not unparseable, are
    highly ambiguous, especially to a human reader. For example, Jeff
    recently posted answers on how the following is to be parsed, but
    there is no way that someone reading the OBV spec would be able to
    figure out the rules he gave:

    interface public

    { ... };
    interface custom { ... }

    ;
    value safe

    { ... };

    value foo : safe { ... }

    ; // Is this legal or an error?
    value foo2 : safe safe

    { ... }

    ; // What about this?
    value foo3

    { public x; // Is this legal or an error? public public y; // What about this? custom value(); // Is this a valid operation or a syntax error? }

    ;

    While all of these constructs can all be parsed using the appropriate
    number of look-ahead tokens (by the way, the grammar is not LALR(1)
    as the OBV Spec suggests), it is hard to read and even harder to
    parse correctly. Many IDL compilers still fail to properly implement
    the name lookup rules in the existing CORBA specification, and adding
    keyword identifiers will only make that situation much worse.

  • Reported: CORBA 2.2 — Fri, 8 May 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Keyword identifiers (02)

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

    Summary:
    The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
    the concept of "keyword identifiers" in an effort to avoid breaking
    existing IDL specifications.It allows IDL specifications that are simply unparseable. For example:

    interface ValueBase {};
    struct S

    { ValueBase v; }

    ;

    This is ambiguous because the compiler cannot know whether the type
    of struct member "v" refers to the ValueBase interface or the
    ValueBase keyword identifier.

  • Reported: CORBA 2.2 — Fri, 8 May 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Keyword identifiers (01)

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

    Summary:
    The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
    the concept of "keyword identifiers" in an effort to avoid breaking
    existing IDL specifications.
    1) First and foremost, the addition of keyword identifiers changes
    the IDL grammar into a context-sensitive grammar, which are known to
    be notoriously difficult to parse.

  • Reported: CORBA 2.2 — Fri, 8 May 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Can public modifier be applied to value operations?

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

    Summary: 1) Can the "public" modifier be applied to value operations? What is the default?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Reconcile RMI/IIOP upcall and helper class

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

    Summary: Reconcile RMI/IIOP upcall and helper class

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Editorial page 8-107

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

    Summary: A typo: on page 8-107, interface Account should inherit ":" from Describable and
    value Currency should support Describable.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Editorial: p 5-50

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

    Summary: typo p 5-50, first paragraph of 5.6.2.1: *s*IDL compilerS keep on spitting...

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Suggested changes (to section 5.4.1 of orbos/98-01-18) are

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

    Summary: Suggested changes (to section 5.4.1 of orbos/98-01-18) are:

    1. Remove the ``;"" from the end of the definition of <value>. (It"s
    in the modified <definition>.)

    2. Remove [ <supports_token> <scoped_name>

    { ``,"" <scoped_name> }

    * ]
    from the <value_inheritance_spec> non-terminal move it to a new
    non-terminal, <value_supports_spec>.

    3. Change the definitions of <value_abs_dcl> and <value_header>,
    replacing [ <value_inheritance_spec> ] by [ <value_inheritance
    _spec ] [ <value_supports_spec> ].

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

p 5-24, first paragraph of 5.3.1.3

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

    Summary: p 5-24, first paragraph of 5.3.1.3:
    The implementation of operations may be remote if the value also
    supports CORBA.Object.
    typo p 5-30, last line of 5.3.2.6: may BE defined

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

p 5-50 2nd paragraph of 5.6.2.1

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

    Summary: p 5-50, 2nd paragraph of 5.6.2.1: it seems to me that in existing
    ORBs, version inconsistencies between, eg, structs, may already corrupt
    memory. The difference now is that preservation of values sharing
    could make matters worse. It would be great to have this issue better
    explained.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Can an instance of C be passed by value to an operation that expects an A?

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

    Summary: Given:

    abstract interface A {};
    interface B : A {};
    value C : supports B {};

    Can an instance of C be passed by value to an operation that expects an A?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Why is ValueBase a value and not a native type?

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

    Summary: What is the rationale for making ValueBase a value and not a native type?
    It seems strange to me that a ValueBase "value" maps to java.io.serializable
    in Java. Isn"t that what native was invented for?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Java mapping example and C++ mapping example

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

    Summary: In the Java mapping example on page 6-64 the operations are mapped to
    public operations of the Java class. However in the C++ mapping example on page
    7-95, the operations are mapped to protected pure virtual functions of the
    generated C++ class.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Section 7.3.10 Value Factories

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

    Summary: Semantic of register_value_factory is not clear
    What do applications should expect if a factory is already
    registered for a given repositoryId?

    The operation returns the previous factory. But it is not
    clear whether it is overriden or not.

    • When should register_factory be called ?
      I assume that this is after the ORB is initialized (since we
      need a pointer to the ORB). This means that initialization
      of "Component Libraries" is not trivial.
  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

TypeCodes for values

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

    Summary: The spec does not contain a clear definition of how TypeCodes for
    values and value boxes are constructed. There is something about
    this in section 5.6.3, but this seems to describe a variant of the
    algorithm rather than the algorithm itself. Section 5.9.7 needs to
    be expanded to describe this in at least as much detail as the
    description of the encoding of recursive sequence TypeCodes in the
    current CORBA spec.

  • Reported: CORBA 2.2 — Wed, 1 Jul 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Some explicit semantics seem to be missing in section5.8.6

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

    Summary: Section 5.8.6 gives the BNF for the GIOP encoding of values but does not
    describe the semantics behind them. Some of the semantics are referred
    to in earlier section and intuitive for an outsider with a little CORBA
    experience. Some of the the explicit semantics seem to be missing
    altogether (e.g. the "" in <end_tag>). It would be useful if the
    descriptions explicitly used the names within the BNF grammar or
    explicit specifications for each name in the grammar was given.

  • Reported: CORBA 2.2 — Tue, 30 Jun 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

OBV spec inefficient for dending large number of small objects

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

    Summary: One of the common patterns used in IDL specifications is to pass a
    sequence of a data type in order to cut down on network round trips.
    The current OBV spec (orbos/98-01-01) even suggests sending a graph of
    objects and optimizing for the case where the same object occurs
    multiple times in the graph (which I assume will normally be a small
    number of the total objects). The spec seems to be inefficient for
    sending a large number of small objects though. I have looked at the
    errata before and don"t recall any relavent changes but know the RTF are
    considering some now.

  • Reported: CORBA 2.2 — Tue, 30 Jun 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

ValueMemberSeq: What is to be done with the RepositoryID parameter?

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

    Summary: 2) In addition to the ValueMemberSeq, the input parameters to
    fill_in_recursive_sequence_tc include the target TypeCode
    pointer, and the RepositoryId.

    What is to be done with the RepositoryId parameter ?
    Is the method supposed to update the Id as well ?
    If that is the case, is it an optional/required parameter ?

  • Reported: CORBA 2.2 — Thu, 18 Jun 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Forward declaration of value boxes

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

    Summary: It is not clear from the spec whether or not value boxes can be
    forward declared, and used recursively. For example,

    value v;
    struct s

    { long s0; v next; }

    ;
    value v s;

    If value boxes are indeed syntactic sugar, the answer should be yes.
    That brings the next question: Does this mean that one can call
    create_box_value_tc(), supplying NULL for the original_type, and
    then later on fill in the member typecode via fill_in_recursive_tc,
    supplying a ValueMemberSeq of length 1?

  • Reported: CORBA 2.2 — Wed, 1 Jul 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

OBV C++ problem with "supports"

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

    Summary: The OBV spec allows a value to support multiple interfaces. In C++, such
    values
    are specified to derive from the POA skeletons generated from those
    interfaces.
    This presents a potentially intractable problem: skeletons are not designed to
    be inherited together with skeletons for other interfaces because servants do
    not support multiple interfaces. (The Multiple Interface RFP isn"t finished
    yet, right?) The top of page 20-104 of the latest C++ mapping (orbos/98-05-08)
    explicitly says

  • Reported: CORBA 2.2 — Tue, 23 Jun 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

TypeCodes defined in section 5.8.2

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

    Summary: 1) The fill_in_recursive_sequence_tc method is intended to act
    upon an existing "tk_value" TypeCode. The signature indicates
    that it should return a TypeCode pointer.

    What TypeCode is supposed to be returned ?
    If the signature is in error, the specification should
    be corrected – if not, the specification requires
    some additional explanation as to which TypeCode
    needs to be returned.

  • Reported: CORBA 2.2 — Thu, 18 Jun 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

OBV "chunking"

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

    Summary: The OBV spec adds the notion of "chunking" because it claims that "it is
    anticipated that value types may be rather large, particularly when a graph
    is being transmitted. Hence the encoding supports the breaking up of the
    serialization into an arbitrary number of "chunks" in order to facilitate
    incremental processing." (orbos/98-01-18, page 5-55)

    This "feature" should be removed from the spec, since it is the job of the
    underlying transport to handle this issue. GIOP already provides
    fragmentation, allowing transports to handle large parameters efficiently
    – why should we build yet another fragmentation solution on top of it?

  • Reported: CORBA 2.2 — Thu, 11 Jun 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

CDR Streams

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

    Summary: The OBV spec defines CDROutputStream and CDRInputStream types values for
    custom marshaling. The names of these types should not contain "CDR" since
    there is nothing that prevents them from being implemented to use a data
    representation other than CDR.

  • Reported: CORBA 2.2 — Thu, 11 Jun 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Can "public" mofifier be applied to value operations?

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

    Summary: Can the "public" modifier be applied to value operations? What is the default?
    In the Java mapping example on page 6-64 the operations are mapped to
    public operations of the Java class. However in the C++ mapping example on page
    7-95, the operations are mapped to protected pure virtual functions of the generated
    C++ class.

  • Reported: CORBA 2.2 — Tue, 2 Jun 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Typo on page 8-107 of OBV specification

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

    Summary: A typo: on page 8-107 of the OBV spec., interface Account should inherit ":" from
    Describable and value Currency should support Describable.

  • Reported: CORBA 2.2 — Tue, 2 Jun 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Marshaling engine issue

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

    Summary: Using the idl defined in Issue # 1352, we have the send() method, in interface Foo, which takes a Base value type as it"s formal parameter. Now supposet we wish to pass a Derived value type. When marshaling the list of repository id"s, the marshaling engine has no notion of the formal type of the parameter , thus it
    does not know how many safe repository id"s it needs to marshal.

  • Reported: CORBA 2.2 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Narrowing from abstract interfaces

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

    Summary: It has been pointed out to me that we have no way of narrowing
    from abstract interfaces to non-abstract interfaces and value
    classes. In Java, the helper"s narrow method has a signature of
    org.omg.CORBA.Object, so it cannot take an abstract interface
    type. In C++, the generated classes for abstract interfaces
    have an _narrow method with the right signature (taking an
    AbstractBase_ptr), but generated classes for values and regular
    interfaces don"t have such a method. It seems like we would
    need to add overloaded narrow methods in all these places to
    make this work as envisaged in (for example) numbered paragraph
    3 of section 8.3.

  • Reported: CORBA 2.2 — Mon, 18 May 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

"in". "out", and "inout" modifiers on value operation parameters

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

    Summary: The "in", "out", and "inout" modifiers on value operation parameters are
    effectively comments. This is the case as a value maps to a language
    pointer or reference. When it is passed in a local interface
    there is no way to guarantee "in" or "out" semantics; it is passed by
    reference which essentially has "inout" semantics.

    These semantics should be explicitly stated.

  • Reported: CORBA 2.2 — Tue, 2 Jun 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Sections 5.3.1.2 vs. 6.3.1: Mapping of non-public state to java private

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

    Summary: Section 5.3.1.2 says that non-public data members should be mapped
    so that "the private part of the state is only accessible to the
    implementation code and the marshaling routines."

    Section 6.3.1 says that non-public data members are mapped to
    private instance variables.

    The problem is that the Java marshaling routines are in the Helper
    class, which cannot see private instance variables in the value class.

    The proposed solution is to modify the Java mapping to map the default
    IDL state to the default (package visibility) Java state instead of
    private.

  • Reported: CORBA 2.2 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

No portable way to obtain list of type safe repository IDs

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

    Summary: In Section 5.9.1 on p. 5-55 of orbos/98-01-18, the spec says "the sending context is responsible for listing the repository ID"s for all the base types to which it is safe to truncate the real
    type, going up (the derivation hierarchy) to, and including if appropriate the formal type". Currently, there is no portable way to obtain the list of type safe repository ID"s
    from within the marshaling engine in order to be marshaled on-the-wire properly.

  • Reported: CORBA 2.2 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Keyword identifiers (04)

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

    Summary: The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
    the concept of "keyword identifiers" in an effort to avoid breaking
    existing IDL specifications. It specifies that a keyword identifier
    is a word that is treated as a keyword only when used in a keyword
    context, and is otherwise treated as a regular identifier.
    4) Finally, the keyword identifier approach gives the impression that
    IDL extensions can be made at no cost, which is simply not true.

  • Reported: CORBA 2.2 — Fri, 8 May 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

passthrough connection

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

    Summary:
    I would like to get some clarification on the PASSTHROUGH/Untrusted Proxy
    issue.

    In page 4-45, the spec says "It is possible to support pass-through through
    multiple proxies. For example if in the above example there was another
    proxy B2 between B and C, during processing the new_target operation from A,
    B can try to establish a pass-through connection to C via a call to
    new_target on B2. If this fails, due to NO_PERMISSION for example, B should
    fall back to try to connect through B2 using the NORMAL mode.".

    If the connection (B - B2) is NORMAL, the whole connection is not a
    PASSTHROUGH since the client will see the B2"s identity in the SSL session.
    Should B throw back the NO_PERMISSION to the client if B get NO_PERMISSION
    from B2 for PASSTHROUGH connection? If the answer is no (seems to me that is
    what spec says), does this mean that it is possible that the client request
    a PASSTHROUGH connection but actually get a NORMAL connection?

  • Reported: CORBA 2.2 — Wed, 16 Dec 1998 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

issue with TCPfirewallMechanism

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

    Summary: The issue comes from the following configuration:

    Client - Tcp Firewall - Giop Proxy Server - Server

    The server"s IOR will contains a FirewallComponent, which includes two
    FirewallMechanisms - a TcpFirewallMechanism and a GIOPProxy. The issue
    comes when the GIOP Proxy has multiple profiles, which may have different
    host/port, and the TcpFirewallMechanism can only have one host/port. Does
    that mean for any host/port specified in one of the GIOP Proxy "s profiles,
    you always to connect to the host/port specified in the
    TcpFirewallMechanism? This seems unrealistic since the Tcp firewall usually
    provide a one-to-one mapping.

  • Reported: CORBA 2.2 — Wed, 13 Jan 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Issue for Firewall RTF - HTTP tunnelling.

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

    Summary: The submission makes no mention of HTTP tunnelling. There are many
    firewalls which filter HTTP, FTP and email related traffic. Is the
    omission based on the assumption that such firewalls will comprise
    a CORBA conformant GIOP proxy on a well-known IIOP port? The Bi-
    directional GIOP specification suggests not (section 5-1,
    paragraph 2).

    Is tunnelling regarded as an implementation matter? If so there
    will be important issues such as relaxing GIOP/HTTP mapping and
    security which the specification should clarify.

  • Reported: CORBA 2.2 — Wed, 17 Feb 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Issue for Firewall RTF - Chapter 5 needs clarification

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

    Summary: Chapter 5 - Bi-directional GIOP misled me in a number of points, even after
    numerous readings and a discussion with an author. I believe the chapter
    contains all the pertinent information; it just has to be a bit more
    carefully presented.

  • Reported: CORBA 2.2 — Mon, 7 Dec 1998 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

The values of these tags need to be assigned

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

    Summary: The firewall spec defines a number of tag values from OMG managed spaces.
    The values of these tags need to be assigned.

  • Reported: CORBA 2.2 — Thu, 24 Sep 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

CodeBase interface uses undefined type

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

    Summary: The definition for interface CodeBase in module SendingContext
    has a method
    CORBA::InterfaceRepository get_ir();

    There is no type CORBA::InterfaceRepository. I believe this was
    intended to say
    CORBA::Repository get_ir();

  • Reported: CORBA 2.2 — Tue, 4 Aug 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Memory Management for Value Factories Unspecified

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

    Summary: There are no rules governing how to free value factories in C++.
    Specifically, the ORB does not know what to do with the value factory at
    shutdown, and applications do not know what to do with the factory
    returned by register_value_factory. Directly deleting the factories may
    be hazardous (e.g. if they are shared across multiple valuetypes or even
    multiple ORBs), and leaving them around may introduce memory leaks.

  • Reported: CORBA 2.2 — Tue, 28 Jul 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Abstract Interface issue (write_Abstract/read_Abstract)(01)

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

    Summary: 1. There are no write_Abstract and read_Abstract methods on
    DataInputCtream and DataInputStream. This looks like an oversight
    to me.

  • Reported: CORBA 2.2 — Mon, 20 Jul 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

P 5-44: use of base type

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

    Summary: On page 5-44, a new production has been added to the grammar to allow the use of ValueBase to be used as a base type. (<base_type_spec> ::= ... | <value_type_spec). My concern is that all other types of base type specifiers have a PrimitiveKind. However, either you guys forgot or didn"t want to have, that a value or ValueBase does not have a corresponding PrimitiveKind enum value. This becomes essential later on when we want to go into the InterfaceRepository, and find that some type is a ValueBase, we will need to know this. The easiest way to do this could be through a PrimitiveDef, where it"s def_kind attribute is a dk_Primitive, and to satisfy the IDLType interface for they type attribute, we could return a TCKind of tk_value or tk_ValueBase. An alternate could be to not go the PrimitiveDef route and use a different approach. Perhaps we could have a method in the Container or Repository interfaces called create_ValueBase. This would be much like creating an unnamed type such as a sequence, a string, primitive, or array (i.e. get_primitive(), create_string(), etc. in the Repository interface). This is less likely though because create_ValueBase would need to return a type. We could return a ValueDef, but create_ValueBase wouldn"t have enough information passed to it to create on and besides, a ValueDef is named. We could have a whole new definition interface called ValueBaseDef, but this way is a pain if you ask me.

  • Reported: CORBA 2.2 — Mon, 20 Jul 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

TypeCode complexity for value types

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

    Summary: The OBV design for the "CORBA::tk_value" TypeCode defines a
    potentially recursive constructed type that involves ValueMembers.
    The "tk_value" TypeCode defines the entire complexity of the types
    within the Value.

    It is our understanding that when the ORB code that handles "Anys" for
    C++ detects a tk_value TypeCode and needs to encode/decode the associated
    Value object – (e.g., for Any::replace(TypeCode, void *) – it will
    need to invoke a method on that object that understands the object
    instance data and the associated state information. Further
    examination of the TypeCode complexity will not be necessary by the
    Any implementation, since this code would not have knowledge of or
    ability to set the state information within the Value object itself.

    The reason why the layout of the state information within a value
    cannot be known by external code is that virtual inheritance of
    abstract values and/or abstract interfaces makes it impossible to
    calculate the offsets of the data members in a compiler
    independent manner.

  • Reported: CORBA 2.2 — Thu, 23 Jul 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

No typecodes for abstract interfaces

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

    Summary: There are no typecodes for abstract interfaces. Does this mean
    that abstract interfaces cannot be members of structs, unions,
    or values? If so, I think this is a problem and we should add
    typecodes for abstract interfaces.

  • Reported: CORBA 2.2 — Wed, 22 Jul 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Default constructor for Java values

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

    Summary: The OBV spec is not very clear about whether the Java class
    generated for an IDL value has a default (no-argument) constructor.

    A no-argument constructor is needed so that the Helper class
    can construct a value when demarshalling. However, it should be
    package-private in order to limit its visbility to the Helper
    class and not expose it to client code. This is also true for
    state fields declared as private in the IDL value type (which the
    spec currently states are mapped to private in Java).

  • Reported: CORBA 2.2 — Thu, 9 Jul 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

OBV TypeCode parameters wrong

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

    Summary: Section 5.9.7 of orbos/98-01-18 says that the TypeCode parameters for both
    tk_value and tk_value_box start with a string which is the type"s
    repository ID. Why? For everything except tk_interface, the repository ID
    is not visible as a parameter. I believe these parameter lists should not
    include repository IDs to make them consistent with the others.

    I assume that the

    {member_name, TypeCode}

    pairs in the tk_value parameter
    list should appear in the order of declaration of the members in the
    valuetype. This is not stated anywhere.

    The visibility of each member should be added to the tk_value parameter
    list. Each entry in the list should contain

    {member_name, TypeCode, short}

    where the short refers to the Visibility of the member.

    The parameter list for tk_value should probably have an additional
    parameter which is the TypeCode of the concrete valuetype base, if any.

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

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Boxed values need extension to write_Value call

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

    Summary: There"s a problem with the mapping to Java for boxed IDL values
    for non-primitive Java types, for example, a boxed string or a
    boxed sequence. The currently specified write_Value call doesn"t
    allow these to be marshalled correctly.

  • Reported: CORBA 2.2 — Wed, 8 Jul 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

C++ boxed value member clashes

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

    Summary: For boxed values that are structs, unions, or other constructed types with
    member accessor and modifier functions, their member functions such as
    value(), boxed_in(), boxed_inout(), etc. may potentially clash with the
    names of those accessor and modifier functions.

    Solution: make the names of such special member functions start with an
    underscore, e.g., _value(), _boxed_in().

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

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Custom marshalling support for IDL fixed type

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

    Summary: The custom marshalling streams CDRInputStream and CDROutputStream
    don"t support the IDL fixed type. I propose adding the following
    type definition and methods:

    typedef sequence<fixed> FixedSeq;

    abstract value CDROutputStream

    { ... void write_fixed (in fixed value); void write_fixed_array (in FixedSeq seq, in unsigned long offset, in unsigned long length); }

    ;

    abstract value CDRInputStream

    { ... fixed read_fixed (); void read_fixed_array (inout FixedSeq seq, in unsigned long offset, in unsigned long length); }

    ;

  • Reported: CORBA 2.2 — Mon, 13 Jul 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

"Tool" issue for IDL compilers too complex

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

    Summary: 2. The current language mapping mixes both generated code with user
    written code in the same source file. This poses a very complex "tool"
    issue for IDL compilers which is unnecessarily complex.

  • Reported: CORBA 2.2 — Tue, 1 Sep 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Status of hashed repository IDs

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

    Summary: The OBV spec orbos/98-01-18 introduces a new repository ID
    mechanism. It says in 5.6.2.1

    >> We don"t recommand the classic id format "IDL:" <scoped name> ":"
    >> <major> "." <minor> because it is not "foolproof" enough. (It is of
    >> course allowable to use this format, since the CORE specification
    >> does not mandate any particular form.)

    The last sentence is not entirely correct, as 8.6.4 of formal/98-02-33
    specifies

    >> A definition is globally identified by an OMG IDL - format
    >> RepositoryId if no ID pragma is encountered for it.

    The issue is whether the OBV specification changes this default for
    values or not

  • Reported: CORBA 2.2 — Fri, 14 Aug 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

ValueHelper Interface issue

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

    Summary: 5. The ValueHelper interface contains the method get_safe_base_ids, which is
    inconsistent with current OBV terminology.

  • Reported: CORBA 2.2 — Tue, 1 Sep 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

OBV init

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

    Summary: The OBV spec introduces the concept of initializers, which maps
    cleanly only to languages that support overloaded constructors.

    Other languages, such as C, would typically offer functions to provide
    inialization of values. Since initializers are not named, an intuitive
    mapping is hard to find.

  • Reported: CORBA 2.2 — Fri, 14 Aug 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Circular References in CosStream and CosCompoundExternalization

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

    Summary: Circular refrences to CosStream and CosCompoundExternalization,
    i have not been able to find an idl compiler that can compile
    these modules.

    as aside, i have foud many syntax errors in the IDL you provide
    as CORBAServices98-03-02.idl, in many of its interfaces, there are
    typos, and it is not correct with the specifications.

  • Reported: CORBA 2.2 — Mon, 1 Jun 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

TypedConsumerAdmin interface (4.9.2))

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

    Summary: in section 4.9.2 last paragraph:

    "Such a ProxyPushSupplier is guaranteed only to invoke operations defined in
    interface I. Any event on the channel that does not correspond to an
    operation defined in interface I is NOT passed on to the consumer. Such a
    ProxyPushSupplier is therefore an event filter based on type".

    My question is: if we have this proxy to block generic calls (push() in this
    case) why does TypedPushConsumer inherit CosEventComm::PushConsumer, whish does
    support push() ? Why should the generic calls like push() be blocked anyway
    if (according to 4.7.1) TypedPushConsumer should support both typed and generic
    models ?

    Is there something I am misunderstanding ?

  • Reported: CORBA 2.2 — Thu, 5 Feb 1998 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

COM/CORBA keywords

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

    Summary: I can"t find in the COM/CORBA spec parts A and B any mention of how to
    deal with IDL identifiers that are keywords to the Microsoft "mktyplib" tool.
    This tool mangles the following identifier (not necessarily a complete list) by
    prepending them with "_":

    "BSTR", "CALLCONV", "coclass", "CY",
    "CURRENCY", "DATE", "DECIMAL", "DISPID", "DISPPARAMS",
    "dual", "EXCEPINFO", "guid", "GUID",
    "HRESULT", "importlib", "IDispatch",
    "INTERFACEDATA", "IUnknown", "LCID",
    "METHODDATA", "odl", "oleautomation",
    "PARAMDATA", "properties", "propget", "propput", "retval",
    "SAFEARRAY", "SAFEARRAYBOUND", "SCODE",
    "VARIANT", "VARIANTARG", "VARIANT_BOOL",
    "VARTYPE", "VARENUM"

    As far as I can tell, the output of the "mktyplib" tool makes use
    (directly or indirectly) of the regular C++ bindings, whose identifiers
    are not mangled the same way. This makes it impossible to emit COM bindings
    for IDL files that contain the above keywords.

    The problem that I"m running into is in CosTrading IDL, where the identifier
    "properties" is used.

  • Reported: CORBA 2.2 — Tue, 29 Sep 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

ObjectCreationError and Nofactory exceptions in Externilazition

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

    Summary: There is a bit of confusion in the specification concerning the
    exceptions that are possible during the internalization process.

    The internalize operation can raise CosLifeCycle::NoFactory and
    StreamDataFormatError exceptions. This operation calls the
    internalize_from_stream operation of the Streamable interface that can
    raise the CosLifeCycle::NoFactory, StreamDataFormatError, and
    ObjectCreationError exceptions.The last paragraph on page 8-20 (August
    1997 release) states that the ObjectCreationError and
    StreamDataFormatError exceptions of the internalize_from_stream
    operation originate from the read_object amd read_<type> operations on
    the StreamIO interface. However, the ObjectCreationError is not raised
    by any of these, according to the IDL in figure 8-6.

  • Reported: CORBA 2.2 — Thu, 30 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

  • Updated: Mon, 30 Mar 2020 19:47 GMT

question re BiDir IIOP

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

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

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

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

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

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

New OBV "supports" keyword conflicts with CosLifeCycle

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

    Summary: The new OBV keyword "supports" collides with the operation "supports"
    defined in CosLifeCycle::GenericFactory.

  • Reported: CORBA 2.2 — Fri, 7 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    :GenericFactory.

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

Abstract Interface issue (02)

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

    Summary: If we accept 2 above, we may want to revisit the following:
    – 8.8.2, page 8-104, bullet 4:
    "Inserting an abstract interface reference into a CORBA::Any
    operates polymorphically. Either the object reference or value to
    which the abstract interface reference refers is what actually gets
    inserted into the Any. This is because there is no TypeCode for
    abstract interfaces. Since abstract interfaces can not be inserted into
    an Any, there is no need for abstract interface extraction operators."

  • Reported: CORBA 2.2 — Wed, 22 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Wed, 11 Mar 2015 04:24 GMT

CORBAservices IDL

  • Key: CORBA25-57
  • Legacy Issue Number: 959
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In CosStream Module the CompoundExternaliztion.idl is included
    > (needed for CosCompoundExternalization::Node), and in the
    > CosCompoundExternalization Module the Stream.idl is included (needed
    > for CosStream::Streamable and CosStream::StreamIO). Now correct me
    > if I am wrong but isn"t this self-referential loop going to cause
    > problems with the IDL compiler, in that either CosStream will not
    > know about CosCompoundExternalization or vice-versa causing a
    > compiler error.

  • Reported: CORBA 2.2 — Tue, 24 Feb 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    refer to formal/98-12-16

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

OBV TypeCode problems

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

    Summary: For valuetypes that inherit from concrete valuetypes, the
    ORB::create_value_tc operation is insufficient. In particular, it does not
    allow the TypeCode for the base valuetype to be supplied. This means that
    if a valuetype with a concrete base valuetype is passed in an Any to a
    process that has no compile-time information concerning that valuetype, the
    receiving process will be unable to marshal it. Having the RepositoryId of
    the concrete base in the TypeCode does not solve the problem because the
    two processes might not have an Interface Repository (IFR) in common, or
    the concrete base RepositoryId may not be in the IFR known to the receiving
    process. Also, never in CORBA should unmarshaling require lookups in the
    IFR (this in fact should be an absolute ORB Core rule).

    Proposal: change create_value_tc to

    TypeCode create_value_tc(
    in RepositoryId id,
    in Identifier name,
    in boolean is_custom,
    in TypeCode concrete_base,
    in ValueMembersSeq members
    );

    If the valuetype has no concrete valuetype base, the concrete_base argument
    shall be a nil TypeCode reference.

  • Reported: CORBA 2.2 — Wed, 15 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    :create_value_tc operation is insufficient. In particular, it does not

  • Updated: Sun, 8 Mar 2015 21:52 GMT

Module separator within repository IDs

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

    Summary: The module separator within "IDL: style" repository IDs is a "/".
    The module separator within "H: style" repository IDs is a "::".
    Was this difference intentional? If so, why? It seems confusing
    to treat scoped names differently in the two kinds of IDs.

  • Reported: CORBA 2.2 — Thu, 23 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    style" repository IDs is a "::".

  • Updated: Sun, 8 Mar 2015 21:43 GMT

DynAny::get_value collision

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

    Summary: OBV specifies a DynAny::get_value operation to retrieve a value from a
    DynAny, but this operation breaks the existing DynFixed::get_value
    operation. I suggest renaming the DynAny::get_value to avoid the collision
    (gee, if we didn"t use "value" as one of those funny keyword identifiers,
    this wouldn"t be a problem).

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

    :get_value

  • Updated: Sun, 8 Mar 2015 21:42 GMT

Problem with C++ language mapping for OBV

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

    Summary: 1. The following IDL cannot be translated into C++ code by an IDL
    compiler for a C++ environment that does not support namespaces:

    // IDL
    module M {
    struct S

    { boolean b; }

    ;

    interface I

    { void op(in S arg); }

    ;

    value V supports A {
    };
    };

    The reason for this is that module M maps to a C++ class when namespaces
    are not available, and you end up with the following definition loop:

    POA_M::I must be defined before M::V, since M::V inherits from it
    M must be defined before POA_M, because POA_M::I depends on M::S
    but defining M also defines M::V

  • Reported: CORBA 2.2 — Tue, 16 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 21:42 GMT

public static org.omg.CORBA.ValueDef get_value_def();

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

    Summary: On p. 6-63 of orbos/98-01-18, the get_value_def() method is defined in
    the helper class as:

    public static org.omg.CORBA.ValueDef get_value_def();

    Currently, there is no portable way to implement this method for all
    vendor ORB"s. One suggestion is to pass an ORB implementation instance
    as parameter:

    get_value_def(org.omg.CORBA.ORB orb);

    and then add a method to the ORB class such as:

    get_value_def(String idl_name);

    Thus a portable implementation could be

    public static org.omg.CORBA.ValueDef get_value_def(org.omg.CORBA.ORB
    orb)

    { return orb.get_value_def(id()); }
  • Reported: CORBA 2.2 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 21:42 GMT

Clarify semantics

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

    Summary:

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    issue was missing information, no action

  • Updated: Sun, 8 Mar 2015 21:42 GMT

Grammar rule issue

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

    Summary: The new grammar rule:
    <state_member> ::= <public_token> <type_spec> <declarators> ";"

    <type_spec> <declarators> ";"
    seems to open up another large hole for making the grammar non-LALR(1), which may
    or may not have been intentional. This becomes clear as you work your way back
    through the set of grammar rules. For example, according to the way I read the rules,
    the following is legal "new" IDL:
  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    := <public_token> <type_spec> <declarators> ";"

  • Updated: Sun, 8 Mar 2015 21:42 GMT

Which exceptions should be raised?

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

    Summary: Clarify which exception should be raised when no local class is
    available to support an incoming value:
    p 5-29, item 3 says it should be NO_IMPLEMENT
    p 5-34, 3rd paragraph says it should be MARSHAL
    p 5-34, last paragraph says it should be BAD_PARAM
    p 6-67, last item says it should be MARSHAL
    p 7-93, first paragraph of 7.3.10.2 says it should be MARSHAL

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 21:42 GMT

"Syntax" for grammar rule [value_inheritance_spec] ::= ":" [ safe_token ]

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

    Summary: I"ve come across another small glitch in the orbos/98-01-18
    "Objects by Value" spec. This is in section 5.4.1 "Syntax", for the grammar rule:

    <value_inheritance_spec> ::= ":" [ <safe_token ] <scoped_name>

    { "," <scoped_name> }*

    [ <supports_token> <scoped_name> { "," <scoped_name> }

    * ]

    As the rule (and the rules referring to this rule) are written now, a value
    inheritance spec is either optional, or if specified, MUST begin with an
    inheritance relation to another value type (e.g. : value foo2: foo1

    { ... }

    ).

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 21:42 GMT

OBV chunk boundaries

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

    Summary: Section 15.3.4.4. of ptc/98-10-11 includes the following statement wrt to
    ObV chunking:

    "The data may be split into multiple chunks at arbitrary points except
    within primitive CDR types, arrays of primitive types, strings, and
    wstrings."

    Unfortunately, this provides only dubious benfits, but introduces
    significant problems. Traditionally, CDR has been designed so that encoding
    engines are only responsible for marshalling CDR primitives, and remain
    independent of the actual constructed IDL type being marshalled. The above
    clause violates this rule: the CDR stream must know that the primitives
    being marshalled are part of an array, understand the size of the array,
    distinguish sequences from arrays, etc.

    In addition, this is impossible to implement using the Java portable
    streams.

  • Reported: CORBA 2.2 — Fri, 30 Oct 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • 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

Clarification requested on GIOP 1.1 and wstring

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

    Summary: Document interop/98-08-02 states:

    For GIOP versions prior to 1.2, interoperability for Wstring is limited
    to the use of two octet fixed length encodings.

    Does this mean simply that only fixed length character encodings that
    are use 2 byte characters are allowed for GIOP versions prior to 1.2?

    The statement is slightly ambiguous, in that it can be parsed as: "(two
    octet) fixed length encodings" or "two (octet fixed length encodings)".

  • Reported: CORBA 2.2 — Mon, 14 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close issue without change

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

TypeCode constants for bounded strings?

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

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

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

    CORBA 2.3 is missing these sentences.

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

DynValue::get_members/set_members

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

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


    struct NameValueAccess

    { FieldName id; Visibility access; any value }

    ;

    typedef sequence<NameValueAccess> NameValueAccessSeq

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

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

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

    :get_members/set_members as:

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

Type code parameter ordering

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

    Summary:
    the TypeCode pseudo interface makes no mention about the order of parameters
    for structured types. For example, given the IDL struct

    struct MyStruct

    { char c_mem; string s_mem; }

    ;

    it is legal for member_name(0) to return "s_mem" and member_name(1) to
    return "c_mem" (provided member_type(0) returns a char type code and
    member_type(1) returns a string type code).

    The same comments apply to unions, exceptions, and enums, where the order
    in which members are presented is not necessarily the same order as in the IDL
    definition.

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

    No Data Available

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

OBV, value-reference substitution, Multiple Inheritance

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

    Summary: Hi, is it possible to pass a supporting value type by value when used as
    a interface? It looks like this is droped from the OBV spec
    (ptc/98-10-06.pdf says when a supporting value type is used as a
    interface then an object reference will be used).

  • Reported: CORBA 2.2 — Tue, 15 Dec 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

WRONG_TRANSACTION

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

    Summary: WRONG_TRANSACTION Exception

    The CosTransactions module adds the WRONG_TRANSACTION exception
    that can be raised by the ORB when returning the response to a
    deferred synchronous request. This exception is defined in Chapter 4
    of the Common Object Request Broker: Architecture and Specification.
    This para doesn"t state what module is to be used for
    WRONG_TRANSACTION. I assume what is meant is that it should be
    a system exception?

    • I can"t find this exception in either chapter 4 or chapter 3
      of the 2.3 spec. Looks like it needs to be added. I don"t know
      why the above para refers to chapter 4 though – it seems that
      this exception should be added to the list of system exceptions
      in chapter 3?
  • Reported: CORBA 2.2 — Tue, 17 Nov 1998 05:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.3
  • Disposition Summary:

    issue merged with issue1963

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

Proposal on floating point fixes

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

    Summary: I"m preparing a proposal to "fix" fixed point types, but I"d like to
    outline what I am thinking before I have it completed, in order to give
    people a chance to comment.
    Michi has pointed out a few issues with the fixed point constant
    grammar, but I think I can resolve those pretty easily by making changes
    so that fixed point constants are only allowed to be defined using the
    syntax:

    const fixed FOO = 1.2D;

    Some people have expressed the idea that the fixed point type
    specification is lacking sufficient semantic content, and they are
    afraid that since different languages or even implementations of
    languages might do the math differently that portability or
    interoperability is affected. Frankly, I don"t see the problem as
    serious for the CORE RTF. In most cases, the fixed point type is mapped
    to the native fixed point facility of the language. If that isn"t
    sufficiently robust to support stuff like banking applications, the CORE
    RTF can"t do much to fix it anyway.

    For the C++ RTF:

    For the C++ binding, of course, things are broken. However, I think I
    may have a solution to the problem:

    First, define a new class CORBA::FixedValue which is used as the results
    of all of the Fixed arithmetic operations, as well as for the type for
    fixed point constants. FixedValue would store the digits and scale
    information dynamically. All of the defined fixed point types would be
    convertable from/to the FixedValue type, with the DATA_CONVERSION
    exception available to signal overflow.

    Second, get rid of the explicit reference to a template type. Since the
    grammar will be changed to no longer allow anonymous fixed point
    declarations (as parameter types), there is no longer a specific need to
    define the exact type name for the Fixed types, and in fact,
    implementations no longer must implement fixed as a template type.

  • Reported: CORBA 2.2 — Mon, 13 Jul 1998 04:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Destruction of ORB

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

    Summary: how is the ORB object destroyed? There is no ORB::destroy() operation,
    like for the POA. (With "destroy", I mean to remove it from memory
    (C++), or to allow it to be garbage collected (Java).)

    Is shutdown to be meant to destroy the ORB? If so, then this must be
    clarified in the specification. For example, if shutdown() destroys the
    ORB, all subsequent calls to ORB operations (via ORB references) must
    raise OBJECT_NOT_EXIST, just as it is with any other (locality
    constrained) object.

    If shutdown() does not destroy the ORB, but just shuts down
    communications and stops handling of further requests, then some other
    operation is needed to destroy the ORB.

  • Reported: CORBA 2.2 — Mon, 14 Dec 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

OMG VMCID

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

    Summary: Well, it looks like I get to choose what OMG"s VMCID is going to be. My
    > current thoughts are to allocate 65613 as OMG"s VMCID. This will make
    > the minor code value unsigned long appear on the wire as \x00, "M",
    > \x0<e>, <E>; where <e> is the high four bits of the minor code and <E>
    > is the lower 8 bits of the minor code.

  • Reported: CORBA 2.2 — Tue, 29 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

New proposal for recursive TypeCode creation

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

    Summary: The basic problem of creating recursive TypeCodes has become more
    complex with the addition of valuetypes. The current mechanism for
    creating TypeCodes (as adopted by the last RTF) cannot create
    TypeCodes for a large number of cases, and can be quite confusing.
    The new proposal solves the problem of creating recursive TypeCodes in
    general and would deprecate all existing mechanisms for creating
    recursive TypeCodes.

  • Reported: CORBA 2.2 — Thu, 17 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

deactivate_object page no: 9-35

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

    Summary: deactivate_object page no: 9-35

    void deactivate_object(in Objectid oid)
    raises (ObjectNotActive,WrongPolicy)

    If a servant manager is associated with the poa, ServantLocator:: etherealize will be invoked with the oid and the servant.
    It should be ServantActivator::etherealize instead of ServantLocator:: etherealize.

    The Note of deactivate object it should be ServantActivator::etherealize instead of ServantLocator:: etherealize

  • Reported: CORBA 2.2 — Tue, 15 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Typo on pages 10-53, 10-55, and 10-70

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

    Summary: The create_value_tc() api and C++ example use ValueMembersSeq, but the name
    should match the ValueMemberSeq ( no "s" after Member) definition given on page
    10-33 & 10-65

  • Reported: CORBA 2.2 — Fri, 11 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Proposal for creating recursive TypeCodes

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

    Summary: We have spent some time pondering the various issues surrounding
    recursive TypeCodes and OBV, and have come up with a proposed
    solution. This is not a formal proposal (it does not include actual
    changes to the CORBA spec) and is intended mostly to promote
    discussion.

    For this discussion a recursive TypeCode is defined as a TypeCode
    which contains data members which refer to the containing type or any
    type containing the containg type.

    The basic problem of creating recursive TypeCodes has become more
    complex with the addition of valuetypes. The current mechanism for
    creating TypeCodes (as adopted by the last RTF) cannot create
    TypeCodes for a large number of cases, and can be quite confusing.
    The new proposal solves the problem of creating recursive TypeCodes in
    general and would deprecate all existing mechanisms for creating
    recursive TypeCodes.

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

    No Data Available

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

Missing orb.idl

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

    Summary: It appears that during the editing for the POA changes for 2.2, Appendix A
    of the old BOA chapter was dropped without a trace. As a result, it looks
    like the definition for the orb.idl include file has disappeared.

  • Reported: CORBA 2.2 — Tue, 11 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Types defined in the CORBA module?

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

    Summary: Where am I supposed to pick up the types defined in the CORBA module,
    such as CORBA::Identifier, if I want to use them in my IDL?

    The (now apparently missing) orb.idl file gave me access to the
    TypeCode interface and the IFR interfaces, but mentioned nothing about
    other types defined in the CORBA module.

  • Reported: CORBA 2.2 — Tue, 11 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    :Identifier, if I want to use them in my IDL?

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

Incorrect LifeCycle IDL?

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

    Summary: Section 6.2 of formal/98-07-05 mentions

    typedef Naming::Name Key;

    I believe it should be CosNaming::Name instead.

  • Reported: CORBA 2.2 — Tue, 4 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Size of IDL char

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

    Summary: The IDL chapter says on page 3-24:

    OMG IDL defines a char data type that is an 8-bit quantity which...

    This seems to imply that chars must map to an 8-bit type in the target
    language. Not all CPUs can do this. For example, on a Cray, chars are a
    32-bit type.

    I would suggest to remove the size requirement.

  • Reported: CORBA 2.2 — Thu, 30 Jul 1998 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Proposed change to IDL in section 3.10.2, page 3-32 "Parameter Declaration

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

    Summary: Firstly, in Section 3.10.2, "Parameter Declarations" on
    page 3-32, the last paragraph states:

    When an unbounded string or sequence is passed as an
    inout parameter, the returned value cannot be longer
    than the input value.

    This seems like an undesirable and unnecessary restriction to me.
    Is there any chance that you could remove this restriction in a
    future version of the specification? Alternatively, if there is
    a good reason for this restriction then perhaps you could document
    it in a future revision of the specification.

  • Reported: CORBA 2.2 — Thu, 23 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 21:36 GMT

CosObjectIdentity::ObjectIdentifiers can"t be UUIDs?

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

    Summary: Does anyone know why the CosObjectIdentity::ObjectIdentifier was changed
    from "typedef sequence<octet,16>" to "typedef unsigned long"? This
    happened some time ago between the 3/94 and 3/95 versions of the
    CosRelationships specification.

    It seems odd since the earlier version could support the 128 bit UUIDs
    used in DCE and the 128 bit GUIDs found in Microsoft but the current
    version is only one quarter the size. Also, all available literature I
    can find on the topic indicates that the 128 bit version is necessary
    for uniqueness "across space and time". In large distributed object
    environments, I don"t think the 32 bit version will cut it.

  • Reported: CORBA 2.2 — Thu, 23 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Illegal IDL in CosTime module

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

    Summary: The IDL in module CosTime for the compare_time and
    time_to_interval operations is illegal. Reference
    http://www.omg.org/archives/experts/msg00890.html
    for further information.

  • Reported: CORBA 2.2 — Thu, 16 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

TypeCode comparison proposal (02)

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

    Summary: 10. Define two new operations on TypeCodes:

    pseudo interface TypeCode

    { ... TypeCode get_compact_typecode(); TypeCode get_canonical_typecode(); ... }

    ;

    TypeCode::get_compact_typecode() strips out all optional name & member
    name fields. TypeCode::get_canonical_typecode() looks up the TypeCode
    in the Interface Repository and returns the fully fleshed-out TypeCode.
    If the top level TypeCode does not contain a RepositoryId, (such as
    array and sequence TypeCodes, or TypeCodes from older ORBs), then a new
    TypeCode is constructed by calling TypeCode::get_canonical_typecode() on
    each member TypeCode of the original TypeCode. If the Interface
    Repository is unavailable, or does not contain the information needed,
    the call raises the INTF_REPOS system exception.

  • Reported: CORBA 2.2 — Wed, 1 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Description of Wide String type

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

    Summary: Null termination is a marshalling and language mapping issue and should not
    appear as part of the semantic description of the IDL type. It should be
    completely valid for a language with a native wide string type to handle the
    varying length nature of the wide string with or without use of null
    termination and certainly without exposing it to the user. Therefore, the
    description of the wide string type in 3.8.3 should not mention null
    termination.

    Also the syntax should be included.

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

    No Data Available

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

TypeCode comparison proposal (01)

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

    Summary: Points 1 through 9 need to be considered as one unit. Point 10 can be
    voted on independently, but does provide a useful capability for
    controlling the size and content of TypeCodes.

    Proposal:

    1. Make RepositoryIds mandatory for all TypeCodes that have them. [This
    was done by the previous core RTF. I am just reiterating it here for
    completeness.]

    2. All TypeCode constants generated by the IDL compiler, as well as all
    TypeCodes returned by the Interface Repository must include alias
    TypeCodes wherever a typedef declaration appears in the original IDL
    source.

    3. Each IDL programming language mapping must provide a mechanism for
    the programmer to ensure that values of the IDL any type contain the
    exact typecode desired by the programmer.

    4. The name() and member_name() fields of the TypeCode are for
    documentary purposes only, and are never considered significant when
    comparing TypeCodes.

    5. Define a new equivalent operation for TypeCodes:

    pseudo interface TypeCode

    { ... boolean equivalent(in TypeCode other); ... }

    ;

    with the following semantics:

    a) If the two TypeCodes are the same primitive type (null, void, short,
    long, ushort, ulong, float, double, boolean, char, octet, any, TypeCode,
    longlong, ulonglong, longdouble, wchar) then equivalent() returns true.

    b) If the two TypeCodes are string, wstring or fixed with the same
    parameters (bounds, digits or scale) then equivalent() returns true.

    c) If the two TypeCodes are both arrays or both sequences, with the
    same bounds and their component types are equivalent(), then
    equivalent() returns true.

    d) If the two TypeCodes are both object references, return true if the
    their RepositoryIds are the same.

    e) If the two TypeCodes are both structs, exceptions, unions, enums or
    aliases, and they have the same RepositoryId, then equivalent() returns
    true. Note in this case that member TypeCodes are not compared.

    f) If either or both of the TypeCodes have an empty RepositoryId, then
    equivalent() falls back to a structural comparison, and returns true if
    all members of the two TypeCodes also are equivalent(). This case will
    only occur when interoperating with an older ORB that does not yet
    require RepositoryIds as mandatory for these TypeCodes. Note that the
    name() and member_name() fields are not used in this comparison.

    g) Otherwise, equivalent() returns false.

    6. The ORB uses TypeCode::equivalent for all internal TypeCode
    comparisons, such as for supporting any (and thus DII and DSI) and
    DynAny.

    7. If the programmer needs to distinguish between a type and/or
    different aliases of that type, he can call TypeCode::id() and compare
    the RepositoryIds.

    8. All DynAny insert & get operations do not consider aliases as
    significant. The type() operation however, will return the TypeCode
    with all of the aliases intact, including type() from any DynAny member
    components. DynAny::assign() and DynAny::from_any compare the internal
    TypeCode of the DynAny with the TypeCode of its argument using
    TypeCode::equivalent() and raise Invalid if equivalent() returns false.

    9. The TypeCode::equal() operation is not used internally by the ORB
    and is deprecated.

  • Reported: CORBA 2.2 — Wed, 1 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

name scoping issue

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

    Summary: In the course of a discussion Philippe Gautron pointed out to me that in
    ISO-C++, the scope of a class begins with its declaration, and hence a
    member or type declaration in the class may not introduce the same name
    as that of the class, exception being constructors of the class.
    Analogous rules apply to struct and namespace. When this principle is
    extended to the case insensitivity of IDL a consequence is that

    interface I

    { void i(); }

    ;

    is illegal as is:

    module M {
    interface m

    {....}

    ;
    };

    The basic rule is that the name of the scope, if it has one is
    implicitly inserted into the scope and hence cannot be reused for other
    purposes in that scope. Given that IDL has to be mapped to C++ this
    seems like an eminently reasonable restriction. However, I could not
    find this explicitly stated anywhere. Do y"all feel this is reasonable?
    If so, and if it is indeed not mentioned then I think we should add a
    line or two in 3.13 clarifying this?

  • Reported: CORBA 2.2 — Fri, 26 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

IDL struct issue

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

    Summary: IDL structs are specified to have "one or more" members rather than
    "zero or more".

    Whilst it might be argued from a stylistic point of view that an empty
    struct is of limited use, of should be avoided, there are places where
    it may be desirable to specify a placeholder struct for later expansion,
    or for machine generated code where there happens to be nothing to fill
    the struct with.

    I can see no compelling technical reasons for requiring that a struct
    contain at least one member, so I propose that the grammar be revised to
    alow for a struct with zero members.

    Such a change would not break any existing IDL.

  • Reported: CORBA 2.2 — Fri, 26 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Type codes cannot describe all unions

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

    Summary: Fix this by stating that member_label returns an Any containing
    a sequence of labels if a single member has more than label.

    Add a typedef to the TypeCode pseudo-IDL:

    typedef sequence<any> LabelSeq;

    A sequence of this type would be contained in the Any returned by
    member_label() if a member has multiple labels (this avoids changing the
    signature of member_label()).

    For the above union, the member_count() operation would return 2, not 5.

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

    No Data Available

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

Type code operations under-specified

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

    Summary: On page 8-38:

    Member_count [sic] returns the number of members
    constituting the type.

    This is a little ambiguous and easily confused with the number of parameters.
    For clarity, I would suggest to add a sentence to make this clearer, e.g.
    "For example, the member count of a structure with three members is three."

    This would help to avoid confusion with parameters (if I am not careful,
    I might think the number is six, because a the three members of a structure
    are described by six parameters, or I might think that the number is nine,
    because a three-member structure has a total of nine parameters).

    The origin for the index to the member_name operation is never defined.
    Presumably, indexes start at zero? If so, this must be stated.

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

    No Data Available

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

Type code typos (as only one issue)

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

    Summary: There are a few typos in the spec for type codes.

    Page 8-40:

    A structure with N members results in a tk_struct TypeCode with
    2N+1 parameters.

    This is no longer correct. Because of the Repository ID parameter that
    was added, this is now 2N+2.

    Similar fixes need to be applied to the text for unions (3N+3 parameters,
    not 3N+2), enumerations (N+2 parameters instead of N+1 as implied by
    the text), and aliases (they have three parameters, not two).

    The text for tk_objref also needs updating, because it states that
    it has one parameter instead of two.

    Also, Table 7-1 for tk_objref should be updated because it is internally
    inconsistent.

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

    No Data Available

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

Typo in chapter 8

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

    Summary: Table 8-1 on page 3-39 of the CORBA spec contains a typo.
    "tx_fixed" should be "tk_fixed".

  • Reported: CORBA 2.2 — Tue, 23 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Does the DII support the standard object operations?

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

    Summary: There are two types of standard operations: ones that are transmitted
    over the wire, and ones that are not. Now it seems reasonable to
    support the over-the-wire operations via the DII, such as "is_a",
    "non_existent", "get_interface" and "get_implementation" (obsolete), but
    what about the ones that don"t go over the wire:

    hash
    is_equivalent
    get_policy
    get_domain_managers

    I would guess that the DII should not support these operations, but the
    spec does not explicitly say that. So, should we add a statement to the
    DII part of the spec that an attempt to invoke these non-over-the-wire
    operations should raise BAD_OPERATION?

  • Reported: CORBA 2.2 — Tue, 2 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Typos in IR IDL in Specification (04)

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

    Summary: - Section 8.8 page 8-53: add "," after "tk_except" in definition of TCKind.

  • Reported: CORBA 2.2 — Wed, 20 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Typos in IR IDL in Specification (050

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

    Summary: - Section 8.8 page 8-55: change "element type" to "element_type" in
    operation create_sequence_tc.

  • Reported: CORBA 2.2 — Wed, 20 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Typos in IR IDL in Specification (03)

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

    Summary: - Section 8.8 page 8-48: remove incorrect "};" between "create_array" and
    "create_fixed".

  • Reported: CORBA 2.2 — Wed, 20 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Typos in IR IDL in Specification (02)

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

    Summary: - Section 8.8 page 8-47: need forward declarations of WstringDef and
    FixedDef before use on page 8-48. Again, it would seem that they were
    left out of the list of forward declarations on 8-47.

  • Reported: CORBA 2.2 — Wed, 20 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Typos in IR IDL in spec (01)

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

    Summary: The following problems appear in the 2.2 spec (98-02-23) and the IDL
    summary extracted from it (98-03-01.idl).

    • Section 8.8 page 8-45: need forward declaration of ExceptionDef, i.e.,
      "interface ExceptionDef" before use on page 8-47. There are a number of
      forward declarations in the middle of 8-45 that would seem to be the
      logical place for it.
  • Reported: CORBA 2.2 — Wed, 20 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

/ in prefix pragma?

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

    Summary: currently, #pragma prefix is completely unconstrained and can contain
    any character. This includes potentially troublesome things such as space
    and "/", or non-printing characters.

    I would suggest to define a syntax for #pragma prefix. In particular, I think
    that "/" should be forbidden in a prefix. This is because otherwise, given
    a repository ID, I cannot work out where the prefix ends and the scoped
    name starts. In addition, things that cannot normally be part of file names
    or identifiers should probably be forbidden as well, otherwise we could
    get problems with things like the class path in Java.

  • Reported: CORBA 2.2 — Mon, 27 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Versioning by the back door?

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

    Summary: I"ve always been under the impression that CORBA does not have versioning.
    it looks like we
    actually do have versioning. Could someone please let me know what
    the correct interpretation should be? Has this versioning stuff sort
    of quietly snuck in via the back door?

    I find this section of the spec particularly stunning because a few pages
    earlier, it says about #pragma directives:

    An IDL compiler must eithe rinterpret these annotations
    as specified, or ignore them completely.

    So, on the one hand, we can happily ignore #pragma, and a few pages
    later, we go and add semantics to the version pragma?!

  • Reported: CORBA 2.2 — Wed, 22 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

GIOP typo, section 4.2 (page 4.4) of CORBA 2.2

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

    Summary: Section 4.2 (page 4.4) of the corba 2.2 spec defines a "non_existent" operation
    on CORBA::Object. In Section 13.4.1 (page 13-23) it sates that the operation
    name for such a request is encoded as the string "_not_existent". This latter
    string looks like a typo, and we propose to change this (on page 13.23) to
    "_non_existent".

  • Reported: CORBA 2.2 — Mon, 20 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    :Object. In Section 13.4.1 (page 13-23) it sates that the operation

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

Domain Manager related specification shortcomings (03)

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

    Summary: 3) There is no way at present to implement the
    Object:get_domain_managers operation in an interoperable fashion. To fix
    this it seems a new GIOP message needs to be defined to carry the
    implicit get_domain_managers operation. There of course may be other
    ways to fix this. Some of the submitters of the original security spec
    saw domain managers as replicated objects such that a replica of it was
    present in each ORB instance where there was an object belonging to that
    domain manager was instantiated, thus relegating the problem of getting
    the domain manager information to the replication mechanism. Well, the
    hoped for replication facility has not happened yet and there is no
    other way to implement this interoperably. This needs to be fixed.

  • Reported: CORBA 2.2 — Fri, 17 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    get_domain_managers operation in an interoperable fashion. To fix

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

Semantics and standard exceptions

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

    Summary: The spec lists the standard exceptions in section 3.15.1.

    However, for many of these, there are no semantics specified anywhere.
    Instead, for the majority of standard exceptions, the only "semantics"
    are what is in the comments in section 3.15.1.
    We badly need an explanation of which standard exception indicates what
    error condition in the spec, otherwise we"ll never get agreement on which
    exception means what...

  • Reported: CORBA 2.2 — Thu, 16 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Forward declarations and inheritance

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

    Summary: The IDL spec explains forward declarations at the end of section 3.5.2.
    However, it does not make the following illegal:

    interface base; // Forward declaration

    interface derived: base

    { // Should be illegal // ... }

    ;

    interface base

    { // ... }

    ;

    The problem here is that a forward-declared interface is used as a base
    interface before the definition for that interface has been seen.
    In the absence of further words in the spec, this is legal, but clearly,
    it should be illegal (otherwise, I can"t use a single-pass compiler).

  • Reported: CORBA 2.2 — Thu, 16 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 21:35 GMT

Indentation on page 4-4

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

    Summary: interface Object on page 4-4 shows:

    interface Object

    { ImplementationDef get_implementation(); InterfaceDef get_interface(); boolean is_nil(); Object duplicate(); void release(); boolean is_a(...); boolean non_existent(); boolean is_equivalent(...); unsigned long hash(...); <====== // ... }

    ;

    The first four declarations use no indentation, the fifth declaration
    uses one indentation level, and the final four declarations use a different
    indentation level. This could be tidied up a bit.

  • Reported: CORBA 2.2 — Sun, 22 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Editorial issue, chapter 8

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

    Summary: In the recap IDL at the end of chapter 8, there is a missing comma after
    the tk_except enumerator in the definition of TCKind.

  • Reported: CORBA 2.2 — Sat, 21 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

ORB_init

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

    Summary: Page 4-9 of CORBA 2.2:

    ORBid strings other than the empty string are intended to be used
    to uniquely identify each ORB used within the same address space
    in a multi-ORB application.

    I don"t believe this is possible, mainly because the language mappings
    do not permit multiple ORB run-time libraries to be linked into the same
    address space.

  • Reported: CORBA 2.2 — Fri, 20 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

IDl "module" construct - IDL files

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

    Summary: It appears that the IDL concept of a module is tightly bound to
    the storage of IDL statements in files. In other words, it does not
    seem to be possible to distribute IDL statements in the same logical
    module across multiple files. Consequently, few people use the
    concept, and name collisions occur sooner or later when trying to
    integrate systems that have not been developed by only one group.

  • Reported: CORBA 2.2 — Fri, 20 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

How to deal with object identity

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

    Summary: I"m not quite sure where this should go, but there should be an explicit
    statement somewhere in the CORBA descriptions that states how to deal
    with object identity with respect to subscribe/unsubscribe schemes.

    The (language/CORBA/etc independent) pattern
    interface SomeSender

    { void addSomeListener( in SomeListener theListener ); void removeSomeListener( in SomeListener theListener ); ... }

    is very commonly found, and as far as I understand it (I might be wrong,
    but if so, it needs to be documented that this would be incorrect),
    SomeListener actually needs to implement a "is_identical( Object )"
    operation that would be called by the removeSomeListener() operation
    in order to find out which of the registered listeners should be removed.

  • Reported: CORBA 2.2 — Fri, 20 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Typo in type code section (13.3.4)

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

    Summary: On page 13-13, CORBA 2.2:

    A "simple" parameter list has a fixed number of fixed length entries,
    or a single parameter which is has its length encoded first.

    This should probably be

    ... single parameter which has is length encoded first.

  • Reported: CORBA 2.2 — Thu, 19 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Fixed point constants issue

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

    Summary: Page 3-20 of CORBA 2.2:

    A fixed-point literal has the apparent number of total and
    fractional digits, except that leading an 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.00 is fixed<1,-3>.

    Apart from the fact that 3000.00 is not a fixed point constant literal,
    I"m confused about something else...

    If 3000.00d is fixed<1,-3>, then 3000.0000d is also fixed<1,-3>.

    These rules result in

    3000.00d being fixed<1,-3>
    BUT
    3000.01d being fixed<6,2>

    This doesn"t seem to make sense. If I bother to write the trailing zeros,
    surely I have a reason, namely, that I mean to use that scale. In other words,
    I think that

    3000.00d should be fixed<6,2>
    and
    3000.0000d should be fixed<8,4>

    Why are fractional trailing zeros thrown away but fractional trailing
    non-zeros retained?

  • Reported: CORBA 2.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Wide character and wide string literals

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

    Summary: Section 3.2.5 on page 3-9, 2nd para says:

    Wide character and wide string literals are specified exactly
    like character and string literals. All character and string
    literals, both wide and non-wide, may only be specified
    (portably) using the characters found in the ISO 8859-1 character
    set, that is interface, names, operation names, type names, etc., will
    continue to be limited to the ISO 8859-1 character set.

    • The first part says that wide character literals and wide string literals
      are to be specified exactly like character and string literals.

    This seems to be impossible - if they were exactly the same, there would
    be no point in having them... At any rate, the sentence seems to
    imply that I must restrict myself to ISO Latin-1 characters in
    wide literals.

    • The second part then says that wide literals are restricted to 8859-1,
      but that interface names (etc.) will continue to be limited to 8859-1.

    Now what is that supposed to mean? Interface names have always (and
    incorrectly) been limited to 8859-1. Nothing has changed. Am I to
    imply then that the sentence was meant to suggest that wide literals
    can actually contain wide characters other than 8859-1?

    This paragraph simply doesn"t make sense as it stands.

  • Reported: CORBA 2.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Type of fixed point quotients

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

    Summary: the 2.2 spec on page 3-20 defines the type of a fixed point division as:

    fixed<(d1-s1+s2) + Sinf, Sinf>

    I"m having a problem with this: The type of the result cannot be known
    at compile-time because it depends on the actual values.

    This differs from the add, subtract, and multiplication operators,
    where the result type can be determined statically.

    There is a C++ mapping problem too. The C++ mapping uses a template
    type for fixed point, where the digits and the scale are template parameters
    (i.e. must be compile-time constants).

  • Reported: CORBA 2.2 — Thu, 19 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Fixed point constant typo in 2.2

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

    Summary: Section 3.7.2 of CORBA 2.2 contains an error on page 3-20, last para:

    For example, 0123.450d is considered to be fixed<5.2> and
    3000.00 is fixed<1,-3>.

    This is in conflict with section 3.2.5 on page 3-9, last para:

    A fixed-point decimal literal consists of an integer part, a
    decimal point, a fraction part and d or D. [ ... ]
    Either the integer part of the fraction part (but not both)
    may be missing; the decimal point (but not the letter d (or D))
    may by missing.

    So, it seems that the "3000.00" on page 3-20 really should be
    "3000.00d" or "3000.00D".

  • Reported: CORBA 2.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Marshalling is_equivalent

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

    Summary: CORBA 2.2 GIOP does not define a way to invoke is_equivalent on an object remotely

  • Reported: CORBA 2.2 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    close no change with above explanation

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

#pragma prefix issue

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

    Summary: How does the scope of #pragma prefix interact with #include? Find details in the corresponding archive

  • Reported: CORBA 2.2 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

CORBA 2.2 - "native" and the interface repository

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

    Summary: Whilst implementing the POA I noticed that there were no extensions to
    the Interface Repository or TypeCodes to handle native types.

    The nett result appears to be that there is no way to express some of
    the POA interfaces in the Interface Repository. Obviously the native
    interfaces themselvse can"t be expressed, but nor can some of the IDL
    specified interfaces.

    e.g. ServantLocator has two operations (preinvoke and postinvoke) both
    of which have a Cookie listed as a parameter. There appears to be no way
    to generate a TypeCode for the Cookie (native) paramter and therefore no
    way to perform an InterfaceDef.create_operation to desribe either of
    preinvoke or postinvoke.

  • Reported: CORBA 2.2 — Thu, 5 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Versioning needed for CORBA Core

  • Key: CORBA26-11
  • Legacy Issue Number: 2227
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: At present there is no formal mechanism or process for versioning the
    CORBA Core. Indeed, it is somewhat hard to figure out what is part of
    the CORBA Core. In Rev 2.3 we tried to at least bring all the IDL for
    the Core together in pieces at logical places, e.g. ORB interface,
    Object interface, IR Interfaces etc. In addition we also have the
    PortableServer module and the GIOP and related modules, the versions of
    all of which have to match for the resulting system to have any hope of
    working as advertized. I guess the basis of the current state of
    affairs is that - the vendor delivers the core, and therefore one can
    trust the vendor to deliver the right things. This model tends to break
    down in situations where people can download bits and pieces of a Java
    ORB at different times and then try to make the whole thing work
    together.

  • Reported: CORBA 2.2 — Mon, 23 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected, see above

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

No way to detect that ORB has outstanding deferred synchronous requests

  • Key: CORBA3-2
  • Legacy Issue Number: 2299
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue: There is currently no way to detect that an ORB has outstanding
    deferred synchronous requests. In the DII, this was possible via
    the blocking ORB::get_next_response operation. A mechanism is needed so
    that applications can (for example) shutdown gracefully
    only after all outstanding deferred synchronous operations have
    returned results.

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

    see above

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

issue with ForwardRequest exception in POA

  • Key: CORBA3-3
  • Legacy Issue Number: 2431
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The ForwardRequest exception in the POA specification doesn"t allow the
    servant manager to specify whether the status of the GIOP reply is
    LOCATION_FORWARD or LOCATION_FORWARD_PERM. If an application is designed
    to use ForwardRequest exceptions, then it should be able to state whether
    the new object reference is transient or permanent.

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

constant decls broken

  • Key: CORBA3-1
  • Legacy Issue Number: 1139
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    Summary: When the extended IDL types were added to CORBA, the semantics of IDL
    constant declarations seems to have been broken. In CORBA 2.0 (July
    1995) the third paragraph of section 3.7.2 page 3-18 states:

    "An integer constant expression is evaluated as unsigned long unless
    it contains a negated integer literal or the name of an integer
    constant with a negative value. In the latter case, the constant
    expression is evaluated as signed long. The computed value is coerced
    back to the target type in constant initializers. It is an error if
    the computed value exceeds the precision of the target type. It is an
    error if any intermediate value exceeds the range of the evaluated-as
    type (long or unsigned long)."

    The paragraph following the one quoted above explains the same for
    floating-point constants.

    Unfortunately, CORBA 2.2 has broken this. Section 3.7.2, page 3-20,
    of formal/98-02-01 tells us what to do if types are long, unsigned
    long, long long, unsigned long long, double, and long double, but the
    old text stating how general integer constants and floating point
    constants were evaluated has been completely removed! How should the
    following be evaluated?

    const short S = 1 + 2;

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

    see above

  • 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

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

LocateRequest and LocateReply messages

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

    Summary: GIOP 1.1 only allows Request and Reply headers to be fragmented. But
    GIOP 1.2 increases the size of LocateRequest messages, and large
    LocateReply messages are also likely. I see no reason why GIOP 1.2
    should not allow LocateRequest and LocateReply messages to be
    fragmented. If noone objects, I"d like to see the following put to a
    vote in the next ORB 2.4 Interoperability RTF for inclusion in CORBA
    2.3:

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

    see above

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

CDR encoding for fixed

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

    Summary: The CDR encoding rules for fixed-point types are incomplete.

    In particular, it is not stated which value encodes what digit in each
    nibble of an octet. It seems sensible to use 0x0 -> "0", 0x1 -> "1", ...,
    0x9 -> "9". However, this isn"t stated (but should be).

    The same comment applies to page 7-10 for DynFixed. I would suggest that
    rather than repeat the same explanations in the CDR section and the DynFixed
    section, the spec should use a cross-reference in the DynFixed section that
    points at the CDR rules.

  • Reported: CORBA 2.2 — Thu, 9 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Interop RTF has recommended adoption of this resolution.

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

New "opaque" data type

  • Key: CORBA23-95
  • Legacy Issue Number: 2674
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I propose the addition of the new basic data type "opaque."

    Many applications require the sending or retrieving of opaque data,
    like graphical data or file contents. Currently, such data is packaged
    as sequence<octet>.
    In the past, the performance of passing sequence<octet> parameters
    was not satisfactory because of the generic mapping of sequences. In
    the recent C++ mapping, the dubious get_buffer() is introduced for
    the mapping of sequences.
    I feel that this matter is best resolved by adding a new data type
    which can then be mapped efficiently into target languages without
    the side effect of complicating the mapping of other sequences.
    After all, a "string," too, is nothing but a sequence of char.

  • Reported: CORBA 2.2 — Sun, 30 May 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

DynAny::equal operator issue

  • Key: CORBA23-94
  • Legacy Issue Number: 2616
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The DynAny::equal operator does not mention how to compare object
    references or TypeCodes. It should be specified to require is_equivalent()
    to be called for object reference comparison and equivalent() to be called
    for TypeCode comparison.

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

    No Data Available

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

sharing valuetypes across Anys

  • Key: CORBA23-93
  • Legacy Issue Number: 2577
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should valuetype identity be preserved across arguments when those
    valuetypes reside within Anys?

  • Reported: CORBA 2.2 — Mon, 5 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

UNIQUE_ID and ServantActivator issue

  • Key: CORBA23-92
  • Legacy Issue Number: 2576
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What should happen if the servant returned from a
    ServantActivator::incarnate call is already registered for another
    object id, and the POA has the UNIQUE_ID policy?

    Since this is clearly an error, I suggest raising the OBJ_ADAPTER
    exception (which will be returned to the client whose request prompted
    the call to incarnate). I also suggest requiring the POA to call
    ServantActivator::etherealize for that object id. The latter is
    necessary to allow the application to dispose of any resources
    associated with that object, and to ensure that an application will
    never recieve two calls to ServantActivator::incarnate for a particular
    object id without an intervening call to ServantActivator::etherealize.

  • Reported: CORBA 2.2 — Fri, 2 Apr 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate change and close issue

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

deactivate_object asymmetry

  • Key: CORBA23-90
  • Legacy Issue Number: 2559
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the POA, we have

    ObjectId activate_object(in Servant s) raises(...);
    void activate_object_with_id(in ObjectId id, in Servant s) raises(...);

    However, for deactivation, we have only one function:

    void deactivate_object(in ObjectId id) raises(...);

    This lacks symmetry. If I can use implicit activation of a servant,
    why can"t I use implicit deactivation? For symmetry, I would have expected:

    void deactivate_object() raises(...);
    void deactivate_object_with_id(in ObjectId id) raises(...);

  • Reported: CORBA 2.2 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

ORB::shutdown again

  • Key: CORBA23-89
  • Legacy Issue Number: 2553
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"m sorry to reopen this can of worms, but I believe that the shutdown()
    issue we voted on (1665) still only offers a partial solution. The problem
    appears to be that terminating the event loop and ORB destruction must be
    separate steps.

    Consider a very simple application that uses RETAIN, NO_IMPLICIT_ACTIVATION,
    and USER_ID. No servant manager is used.

  • Reported: CORBA 2.2 — Tue, 23 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    This issue should be closed no change.

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

DynAny.insert_valuetype shoud be insert_val

  • Key: CORBA23-86
  • Legacy Issue Number: 2547
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The IDL in section 9.2 of ptc/98-12-04 is incorrect. The OBV RTF adopted
    method names insert_val and get_val instead of the original insert_value
    and get_value which conflicted with the get_value method in the DynFixed
    subclass. The IDL incorectly shows these methods as insert_valuetype
    and get_valuetype.

    Proposed Resolution:

    Change insert_valuetype to insert_val and get_valuetype to get_val.

  • Reported: CORBA 2.2 — Tue, 16 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    fix the names in section 9.2

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

confusing rules for operations on Object

  • Key: CORBA23-85
  • Legacy Issue Number: 2543
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 4.3 of ptc/98-10-05 documents Object Reference Operations. These
    are described as "not operations in the normal sense, in that they are
    implemented directly by the ORB, not passed on to the object
    implementation".

    This includes a variety of operations, requiring varying contexts to be
    used successfully:

    • Some require remote communication to the orb of the server
      or (contrary to the quote above) may actually be passed on
      to the object implementation, or something similar like a
      servant manager (e.g. is_a, non_existent)
    • some may require remote communication to an interface repository
      (e.g. get_interface)
    • some require the local orb to be operational
      (e.g. create_request)
    • some can function even without a local orb
      (e.g. is_nil, duplicate, release)
  • Reported: CORBA 2.2 — Tue, 16 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

activate_object_with_id and exceptions

  • Key: CORBA23-88
  • Legacy Issue Number: 2549
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If I use activate_object_with_id and the object ID is already in the AOM,
    the operation raises ObjectAlreadyActive.

    If I use activate_object_with_id and the servant is already in the AOM, and
    the POA has UNIQUE_ID, the operation raises ServantAlreadyActive.

    What happens if I have UNIQUE_ID, and I run the following code?

    poa->activate_object_with_id(my_id, my_servant);
    poa->activate_object_with_id(my_id, my_servant); // ???

    Which exception is raised on the second call, ObjectAlreadyActive or
    ServantAlreadyActive?

  • Reported: CORBA 2.2 — Thu, 18 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

RMI style repository ID hash code

  • Key: CORBA23-83
  • Legacy Issue Number: 2529
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is a problem with the currently defined algorithm for computing
    the hash code component of the RMI Hashed Format repository ID as
    defined in section 10.6.2. Because it is based only on the structural
    information in the most derived Java class and does not take into
    acoount any superclass information, it can give a "false positive"
    result when the state of a superclass changes but the state of the
    most derived class does not.

    This is a core RTF issue since the affected text is in chapter 10.

  • Reported: CORBA 2.2 — Fri, 12 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Replace the currently defined algorithm with one that fixes the problem as described below

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

Clarification on IdUniquenessPolicy

  • Key: CORBA23-91
  • Legacy Issue Number: 2574
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The description of IdUniquenessPolicy in section 11.3.7.3 fails to
    mention how this policy interacts with the ServantRetentionPolicy.

    My interpretation is that the IdUniquenessPolicy is irrelevant when the
    ServantRetentionPolicy is NON_RETAIN. If this is the case it should be
    explicitly stated. Alternatively, one specific value might be required
    when NON_RETAIN is in effect. (If so, it ought to be MULTIPLE_ID.)

    Without some statement clarifying this there could be portability
    problems with some orbs allowing either value while others require a
    particular value.

  • Reported: CORBA 2.2 — Wed, 31 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Incorrect IDL is section 5.5.3

  • Key: CORBA23-84
  • Legacy Issue Number: 2539
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The IDL in section 5.5.3 is incorrect. It refers to
    CORBA::FullValueDescription
    but the correct name for this type according to chapter 10 is
    CORBA::ValueDef::FullValueDescription

    Proposed Resolution:

    Change chapter 5 to match up with chapter 10.

  • Reported: CORBA 2.2 — Mon, 15 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    make it so.

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

Repository ID for Object

  • Key: CORBA23-87
  • Legacy Issue Number: 2548
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Latest 2.3, draft (98-10-10), page 13-17:

    "A Null TypeID is the only mechanism that can be used to represent
    the type CORBA::Object."

    I am aware of more than one ORB that uses "IDL:omg.org/CORBA/Object:1.0".

    I don"t understand why:

    • a null ID should mean Object
    • why a perfectly good repository ID for Object should be disallowed

    Related to this is the fact that we made repository IDs mandatory in
    reference TypeCodes with the 2.3 revision. Unless an implementation is
    very careful, this could mean that, if it gets a reference that doesn"t
    have the repository ID, it could present an illegal TypeCode (with an
    empty ID) for that reference to the application.

  • Reported: CORBA 2.2 — Wed, 17 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    closed in interop/2000-01-01

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

forward declaration in ptc/98-10-04

  • Key: CORBA23-82
  • Legacy Issue Number: 2522
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Pages 3-18 and 3-19 of the CORBA 2.3a spec state that a forward declaration consists of the following:
    [abstract] "interface" <identifier>
    I believe that this should be:
    [abstract] "interface" <scoped_name>

    Otherwise, the following would be illegal:
    module A
    {
    interface B::d; //forward decl of d
    interface c

    { B::d f(); }

    ;
    };
    module B
    {
    interface d

    { A::c f(); }

    ;
    };

  • Reported: CORBA 2.2 — Tue, 9 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close no change in 2.4

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

LocateReply body alignment issue

  • Key: CORBA23-81
  • Legacy Issue Number: 2521
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Hi folks, I know this is a bit late but I was going through some GIOP
    1.2 issues with Bob and I only just noticed another required
    clarification for LocateReply messages. Bascially the text added under
    Request/Reply which states "In GIOP 1.2, the Request[/Reply] Body is
    always aligned on an 8 octet boundary" was not also added to the
    description for LocateReply"s (15.4.2.2). I presume the requirement
    was intended for the body data of all message types. If so, perhaps it
    would make sense to move this text to the start of 15.4 and reworded
    to indicate the requirement for all message body data in general.

    If the LocateReply body alignment issue will not be clarified in the
    GIOP 1.2 specification then I wish to submit this as a new interop
    issue.

  • Reported: CORBA 2.2 — Mon, 8 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    closed in interop/2000-01-01

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

POA issue, section 11.3.8.10

  • Key: CORBA23-80
  • Legacy Issue Number: 2513
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 11.3.8.10 of the Core draft 2.3a says that the application is
    free to assign its own servant manager to the root POA, but the next
    section says that the
    set_servant_manager() operation requires that the POA in question must
    support the request processing policy of USE_SERVANT_MANAGER. But as
    the root
    POA has a req. proc. policy of USE_ACTIVE_OBJECT_MAP_ONLY, surely the
    user CANNOT assign a servant manager to the root POA.

    The text is a mistake, isn"t it? The application cannot "assign its own
    servant manager to the root POA". Unless there is some subtlety to the
    meaning of the word "assign" which make it different from "set". I
    thought the root POA was something the user could not tamper with in any
    way.

  • Reported: CORBA 2.2 — Fri, 5 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

omg.org prefix not well specified

  • Key: CORBA23-77
  • Legacy Issue Number: 2508
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The core spec says in section 10.6.7 that:

    Unless pragma directives establishing RepositoryIds for all definitions
    are present in an IDL definition officially published by the OMG, the
    following directive is implicitly present at file scope preceding all
    such definitions:
    #pragma prefix “omg.org”

    What does an IDL compiler need to do to be compliant with this? How
    is it supposed to recognize IDL definitions officially published by the
    OMG so that it can insert the required implicit pragma?

  • Reported: CORBA 2.2 — Wed, 3 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate change in 2.4 and close issue

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

Can an any with a tk_null or tk_void TypeCode be encoded with CDR?

  • Key: CORBA23-78
  • Legacy Issue Number: 2509
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The spec is silent about whether an any with a TypeCode of tk_null or
    tk_void can be marshalled and unmarshalled with CDR.

  • Reported: CORBA 2.2 — Wed, 3 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    closed in interop/2000-01-01

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

Need to specify exception for abstract interface error

  • Key: CORBA23-75
  • Legacy Issue Number: 2502
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: An abstract interface type in an operation signature indicates that
    at runtime the value passed will either be an object reference or a
    valuetype. However, it is possible for user code invoking this
    operation to supply (incorrectly) a runtime programming language object
    that is neither of these. For example, an IDL abstract interface type
    maps into a Java interface, and the object passed at runtime could be
    any Java type that implements this interface.

    The spec does not currently define an exception to be used in this
    error case. The Java to IDL mapping needs a defined exception so that
    it can detect this error and return a NotSerializableException to the
    application.

  • Reported: CORBA 2.2 — Wed, 3 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Add a new minor code to the BAD_PARAM system exception:

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

POA that has IdAssignmentPolicy=SYSTEM--portability problem

  • Key: CORBA23-79
  • Legacy Issue Number: 2511
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: For a POA that has IdAssignmentPolicy=SYSTEM, there is a portability
    problem in the combination of the POA generation of an ObjectId and
    the language functions that convert between ObjectId and string.

    The C++ functions PortableServer::ObjectId_to_string (and wstring)
    state that

    If conversion of an ObjectId to a string would
    result in illegal characters in the string (such
    as a NUL), the [...] functions throw the
    CORBA::BAD_PARAM exception.

    This apparently assumes that the conversion does nothing but take the
    sequence of octet and recast it as a char*. Thus, an embedded null
    would cause the string to be interpreted as shorter than the sequence,
    so it"s an error.

  • Reported: CORBA 2.2 — Thu, 4 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close no change in 2.4

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

Scope of SendingContextRunTime service context

  • Key: CORBA23-76
  • Legacy Issue Number: 2507
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It is not clear what is the scope of the SendingContextRunTime service
    context defined in section 13.6.7.

    Since the content of this service context will remain constant through
    the lifetime of a connection, it needs to be sent only once per
    connection. This is much more efficient than requiring it to be sent
    on a per-request basis.

    This seems to parallel the current usage of the CodeSets service context.
    Section 13.7.2.6 says:
    Code set negotiation is not performed on a per-request basis, but only
    when a client initially connects to a server. All text data communicated
    on a connection are encoded as defined by the TCSs selected when the
    connection is established.

  • Reported: CORBA 2.2 — Wed, 3 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    closed in interop/2000-01-01

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

Error in IRObject definition in 98-12-04

  • Key: CORBA23-74
  • Legacy Issue Number: 2492
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The definition of IRObject in 10.5.2 somehow got an additional attribute
    that makes no sense: "readonly attribute InterfaceName type_name".
    This is probably an editorial mistake.

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

    They have been fixed in ptc/98-12-04.

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

What use is CORBA::exception_type?

  • Key: CORBA23-73
  • Legacy Issue Number: 2490
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This enumeration type is defined in 3.17.1, but used no where else. Why
    is it even there?

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

    incorporate changes in 2.4 and close issue.

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

CORBA::Object::ping ?

  • Key: CORBA23-71
  • Legacy Issue Number: 2456
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"d like to float the idea of adding a ping operation to CORBA::Object:

    module CORBA {
    interface Object

    { void ping(); // ... }

    ;
    // ...
    };

    The reason for suggesting this is that developers have a frequent need
    for this functionality. (How to determine object reachability (as opposed
    to object existence) is a FAQ).

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

    No Data Available

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

Inconsistent Definition of Flags type

  • Key: CORBA23-72
  • Legacy Issue Number: 2487
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In Section 4.3 of V2.3a specification, the typedef of Flags is "long". In
    Section 7.1.1, it is "unsigned long".

  • Reported: CORBA 2.2 — Wed, 24 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Make it uniformly unsigned long

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

POA Construction Policy.

  • Key: CORBA23-65
  • Legacy Issue Number: 2442
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: >From what I understand of the POA document is that
    the POA or POAs are process resident, and that the servants they register
    are within their own process space, i.e. the Server.

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

    No Data Available

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

Inconsistent spellings of "policy" related identifiers:

  • Key: CORBA23-70
  • Legacy Issue Number: 2454
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I have found inconsistent spellings of "policy" related identifiers:

    "DomainManagersList" is used on pages 4-4 and 4-8

    "DomainManagerList" is used on pages 4-17,20-87,20-88,20-110

    Also, the operation identifer

    "set_policy_override" is used on pages 20-87, 20-88, 20-110

    However, this same operation identifier is consistently spelled as

    "set_policy_overrides" on pages 15-52,15-61,15-65,15-66,15-103,
    15-104,15-105,15-106,15-108,15-109,15-111,15-199,15-218,
    and 15-219

    in 98-12-03.pdf (Security Service Specification - Security Service
    v1.5 15 December 1998 [FINAL]

    So what is the "correct" spelling of these identifiers?

  • Reported: CORBA 2.2 — Wed, 17 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close no change in 2.4

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

Inheritance of value types

  • Key: CORBA23-67
  • Legacy Issue Number: 2446
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is a need for clarification regarding inheritance
    for value types. Must a value type that inherits from
    abstract bases always inherit from a "concrete"
    value? This seems to be enforced by the IDL
    grammar and the introduction of the ValueBase
    primitive type (as a concrete base in case no
    other concrete base is inherited).

    This seems somewhat ambiguous.

  • Reported: CORBA 2.2 — Tue, 9 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    close this issue with the note that it is resolved as part of 2490 in 2.4

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

IR Changes in 2.3

  • Key: CORBA23-69
  • Legacy Issue Number: 2450
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Jishnu has pointed out (very pointedly i might add that a whole slew of
    upwardly incompatible changes have been made to the IR.

    E.g. old structs that have been modified (e.g. full interface description),
    new structs have been added, operations added to container, changed
    tckind, etc., etc.

    The question before us is how, if at all, to reflect this change.

    We came up with several options (listed in no particular order and
    with no particular recommendation.)

    1. Do nothing. This is the traditional approach but probably becoming
    less and less appropriate as we mature

    2. Add a #pragma version name_of versioned_thingy major.minor
    for every definition. (Jishnu thinks that in
    principle all the #pragma version statements could go in one place,
    say at the end of the CORBA module. [We leave it as exercise to the
    reader to work out why they have to go at the end] )

    3. Change the name of the enclosing module. say CORBA -> CORBA_2_3, gulp!!

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

    incorporate changes in 2.4 and close issue.

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

What value type does ValueDef"s base_value() return?

  • Key: CORBA23-68
  • Legacy Issue Number: 2447
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: full_desc: What does a ValueDef"s base_value() operation
    return for a value type that does not inherit from
    any concrete value?

    I see two possible resolutions: (1) make base_value()
    return ValueDef::_nil() in this case, or (2) add a
    pk_ValueBase primitive type to PrimitiveDef and
    return that.

  • Reported: CORBA 2.2 — Tue, 9 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Problems in Chapter 5 IDL

  • Key: CORBA23-66
  • Legacy Issue Number: 2444
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In ptc/98-12-04 Chapter 5, page 5-14, a DataInputStream operation
    has the signature "long long long read_long()". It should be
    "long long read_longlong()"

    Also, the spelling of W[Cc]harSeq is inconsistent between its
    declaration and its usage on pages 5-12 to 5-14.

  • Reported: CORBA 2.2 — Tue, 9 Feb 1999 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.3
  • Disposition Summary:

    Close no change in 2.4

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

another problem with IDL specification section 3.9.2

  • Key: CORBA23-64
  • Legacy Issue Number: 2436
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The spec doesn"t say how octal and hex integral constants are treated.
    For instance, is the following line legal IDL or not:

    const short s = 0xFFFF; // Valid???

    If the interpretation of "0xFFFF" in this context is "65535", then
    this is illegal, since the value is out of range. If the interpretation
    is "-32768", then this assignment is valid. The wording in this section specifies that
    each operand is converted immediately to the size of the eventual
    storage location, but fails to specify how that conversion is to be
    performed for hexadecimal and octal literals.

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

    closed issue

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

Interceptors broken

  • Key: CORBA23-63
  • Legacy Issue Number: 2435
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There seems to be general consensus that the interceptor spec is
    unimplementable fantasy material. Given this, it would seem advisable to
    remove interceptors from the core.

    Also, there is some doubt as to whether P&P rules were followed when
    interceptors were added. My understanding is that an RTF cannot add
    new features to a spec, yet interceptors definitely seem to fall into
    that category.

    Given that no RFP was ever issues and that the feature is obviously broken,
    I suggest to remove the interceptor section until the outcome of the
    Portable Interceptors RFP can be added.

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

    Close in 2.4 with no change.

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

Try to define obligatory and optional parts of the CORBA specification.

  • Key: CORBA23-61
  • Legacy Issue Number: 2378
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This comment uses examples from the chapter 3, but its idea concernes style of the all specification, as a general rule.
    6) In the version CORBA 2.2, there were introduced new features and new simple data type. I understand, that such types like long long and/or long double may be key parts for some application. On the other hand, majority of applications need not such data types, and I see no reason to introduce them as obligatory to all CORBA implementations. For this reason, try to difference various features as obligatory for any CORBA compliant implementation and other ones as optional.
    In general, it is good idea to specify advanced features of this system to unify various its implementators, but, on the other hand, why those features are made obligatory? For this reason, try to define obligatory and optional parts of the CORBA specification.

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close in 2.4 with no change.

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

Issue - no PIDL, just language bindings

  • Key: CORBA23-58
  • Legacy Issue Number: 2371
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In section 7.3.2 of CORBA 2.3a (ptc/98-10-07 pg 7-9) the description of
    send_multiple_requests gives the C, C++, and SmallTalk bindings for the
    operation but does not describe it in PIDL. This is inconsistent with
    the description style for other operations. It is unnecessarily biased
    towards these particular languages, and complicates the process of
    maintaining the specifications of the individual language bindings.

    The same comment applies to section 7.3.4 regarding get_next_response.
    In this case the language binding is in fact inconsistent with that
    published in the C++ language binding.

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue and raise new issue in C++ RTF

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

clarification and bug in InterfaceDef::FullInterfaceDescription

  • Key: CORBA23-62
  • Legacy Issue Number: 2432
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The text in the interface repository specification that describes FullInterfaceDescription is ambiguous. CORBA v2.3a draft, section 10.5.23.1, page 10-22 reads:

    The describe_interface operation returns a FullInterfaceDescription
    describing the interface, including its operations and attributes. The
    inherited describe operation for an InterfaceDef returns an
    InterfaceDescription.

    It does not specify whether the elements of the FullInterfaceDescription should describe only items (e.g., operations, attributes) that where defined in the interface being described, or whether they should describe items inherited from base interfaces as well. My naive, assumed rationale is that the full description is intended to improve efficiency. It should allow a dynamic client to obtain all of the information it needs to invoke any operation supported by the interface in a single request, avoiding the need to traverse the graph of base interfaces. If this is the case, then the full description should include inherited items as well, and the spec should say so. I checked our implementation (VisiBroker) and this is what it does.

    My suggested remedy is to add the following words to the paragraph cited above:

    "The operations and attributes fields of the FullInterfaceDescription structure include descriptions of all of the operations and attributes in the transitive closure of the inheritance graph of the interface being described."

    The bug (I think) is that the FullInterfaceDescription description doesn"t include the boolean is_abstract member. The abbreviated InterfaceDescription struct has been extended with this member, and the FullInterfaceDescription should be a superset of the InterfaceDescription.

    The suggested fix is to add the the following member to the InterfaceDef::FullInterfaceDescription struct:

    boolean is_abstract;

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue

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

Calling get_response twice?

  • Key: CORBA23-56
  • Legacy Issue Number: 2341
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What if I call get_response on a request a second time, after I"ve already
    retrieved the response previously? It seems that an exception should
    be raised but the spec doesn"t say which one.

    Also, the spec could be interpreted right now to say that it"s OK to
    call get_response twice for the same request (because the spec says nothing
    about that). However, to me, permitting this would be silly because it would
    oblige the ORB to keep the reply around until the request object is destroyed
    or is used to initiate another request.

  • Reported: CORBA 2.2 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Application Interface issue

  • Key: CORBA23-60
  • Legacy Issue Number: 2377
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: During study of the ORBIX software, I analyzed structure of internal stubs generated by IDL compiler on the both client and server side of the CORBA connection. I appreciated, that for creation of the both sides are used the same constructions like Request object, not different objects Request on the client side and ServerRequest on the server side. Naturally, there was also possibility to use CORBA compliant ServerRequest object when requested, but generated stubs used "old" IONA logic. May be, there are some sophisticated reasons why OMG specification use various objects on both client and server sides which I do not know, but in general, I prefer more simple approach of IONA. Please, let application interface as simple as possible.

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    This issue is adequately dealt with in the POA specification.

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

Use UNICODE Character set

  • Key: CORBA23-59
  • Legacy Issue Number: 2372
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I am member of the nation using another set of accented Latin letters than is LATIN-1 standard (ISO 8859.1), namely LATIN-2. For this reason, I must comment your preference of one particular character set as an unfortunate case. I would understand, that if you would limit character set to basic Latin characters of the basic ASCII code, but preference of one national enhancements of this code brings my doubts.
    In fact, the problem is not so hot, as it may seem on the first view. I know at present no classical compiler allowing use of the national character set e.g. for the language identifiers, and the limitation of the character sets to pure Latin characters is considered by Czech (and other nation"s) programmers as no significant limitation, with exception of the comments. The same concerns CORBA identifiers used in the OMG IDL language.

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close issue in 2.4 with no change.

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

Grammar section 3.9.2 missing "float" rules, and other problems

  • Key: CORBA23-57
  • Legacy Issue Number: 2343
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 3.9.2 has the following problems:

    No rules for combining floats are given, although double and long double types are mentioned.

    The rules for sizing intermediate forms of constant expressions that must result in an octet type
    are unspecified.

    The size a positive integer constant is required to have is not specified; I imagine it should be
    restricted to (at most) an "unsigned long" size, as larger sizes would not make valid array indices
    in several languages.

  • Reported: CORBA 2.2 — Mon, 25 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Sumsume this issue in 1139, and close this issue with that annotation in 2.4.

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

Forward-Declared Interfaces

  • Key: CORBA23-55
  • Legacy Issue Number: 2340
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: there just has been raging discussion on the OB list about forward-declared
    interfaces. The words we have right now are inadequate. You could argue that the
    interface is defined in the same "specification" here. However,
    current IDL compilers (if they implmement the check at all) require
    the interface to be defined in the same compilation unit as the
    forward declaration.

    Now, we could allow a forward-declared interface to not be defined in
    the same compilation unit, but then, I think, we would have to very
    carefully specify what sort of things I can do with the forward-declared
    interface. (If we don"t do that, we"ll make separate compilation impossible
    because the compiler doesn"t know the size of a forward-declared interface
    nor its base interfaces.)

    What"s the general feeling here? I think we could simple change "specification"
    to "IDL source file" and be done with it. That"s the simple way out.

  • Reported: CORBA 2.2 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Value base and the IFR

  • Key: CORBA23-54
  • Legacy Issue Number: 2334
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Consider the following IDL:

    // IDL
    interface I

    { void op(in ValueBase vb); }

    ;

    How is this represented in the IFR? What is the IDLType of the vb
    parameter?

    I think it should be a PrimitiveDef, just as it would be the case if I
    would pass "Object" instead of "ValueBase". However, there is no
    pk_ValueBase defined. Shouldn"t this be added?

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

    Add value base to primitive defs.

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

Clarifications needed in section 5.2.2

  • Key: CORBA23-53
  • Legacy Issue Number: 2332
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In section 5.2.2 it states in the second paragraph that instances of
    valuetypes passed into valuetype methods are passed by reference (in a
    programming language sense). That"s fine, but:

    1. This paragraph should also state that returned results are passed
    by reference. This is necessary to ensure consistent IDL
    valuetype semantics across different implementation languages.

    2. The last sentence of the following paragraph is confusing because
    it appears to contradict the statement in the second paragraph
    about reference semantics. It says that "normal semantics for the
    programming language in question apply". So if I have a language
    that only does pass-by-value, pass-by-value semantics would apply
    (so this says). This cannot be correct, since it would prevent
    valuetypes from having well-defined semantics at the IDL level.

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

    Fix it.

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

RMI Repository ID missing from section 10.6

  • Key: CORBA23-50
  • Legacy Issue Number: 2329
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 10.6 needs to be updated to reflect the addition of RMI
    Hashed Format RepositoryIds.

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

    change introductory sentence to fix this problem in section 10.6

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

Clarify text in section 15.3.7

  • Key: CORBA23-52
  • Legacy Issue Number: 2331
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 15-26, last sentence of section 15.3.7, the phrase "The abstract
    encoding of value type" is not very clear. This refers to abstract
    interfaces, but a reader might think it refers to abstract valuetypes.

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

    Incorporate change in 2.4 and close issue

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

Text was inserted in wrong place

  • Key: CORBA23-49
  • Legacy Issue Number: 2328
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 10-9, the recently added second paragraph should be moved to the
    bottom of the section. The parapgraph preceding it and the two paragraphs
    following it refer back to numbered points 1, 2 and 3 at the bottom of
    page 10-8, so this block of text should not be broken up.

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

    Make it so

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

is_a description is wrong

  • Key: CORBA23-46
  • Legacy Issue Number: 2323
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 10-36, the "is_a" description is wrong. "interface_id" should
    be "value_id" for consistency with the IDL.

    Actually, it would be more correct to name this "value_or_interface_id"
    or just "id" since both values and interfaces can be passed to the is_a
    method of ValueDef. This requires changing the IDL on pages 10-34 and
    10-65.

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

    Incorporate changes in 2.4 and close issue.

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

No description for ValueBoxDef

  • Key: CORBA23-47
  • Legacy Issue Number: 2325
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 10.5.25, ValueBoxDef, has no description of its read and write
    interfaces. This is inconsistent with other sections.

    Proposed resolution:

    Add copies of sections 10.5.13.1 and 10.5.13.2 here.

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

    Provide description

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

Error in text describing TypeCode interface

  • Key: CORBA23-51
  • Legacy Issue Number: 2330
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The IDL on page 10-47 describing the TypeCode interface says that
    the member_count, member_name, and member_type operations apply to
    tk_except TypeCodes. However, the text on page 10-49 says that
    these do not apply to exception TypeCodes.

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

    Fix it.

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

Error in ValueDef IDL

  • Key: CORBA23-48
  • Legacy Issue Number: 2327
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 10-35, the first line should be "RepositoryId supported_interface;".

    Also, on page 10-65, the eleventh member of FullValueDescription should be
    "RepositoryId supported_interface;" (same change).

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

    The resolution of this is tied to the resolution of issue 2314. So this issue is attached to and sub

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

No description for NativeDef

  • Key: CORBA23-45
  • Legacy Issue Number: 2322
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 10.5.26, NativeDef, has no description of its read and write
    interfaces. This is inconsistent with other sections.

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

    Provide description

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

Errors in figure 10-2

  • Key: CORBA23-44
  • Legacy Issue Number: 2321
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 10-8, the section of figure 10-2 describing the module object
    has become wrongly ordered when the green text was inserted. It says:

    InterfaceDef
    ValueDef
    ValueBoxDef
    ModuleDef

    It should say:

    ModuleDef
    ValueBoxDef
    InterfaceDef

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

    fix the order and indentation

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

Signature of unmarshal method is wrong

  • Key: CORBA23-43
  • Legacy Issue Number: 2320
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 5-11, section 5.5.1, the signature of the unmarshal method is
    wrong. It should return void, not ValueBase.

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

    Fix it

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

Custom Marshaling clarification

  • Key: CORBA23-37
  • Legacy Issue Number: 2311
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the core 2.3a chapters, page 5-11, section 5.5.1, last paragraph needs
    to be clarified or deleted. This paragraph originally referred to the
    "streaming policy" registration APIs that used to be specified here but
    have since been deleted.

    Do we still intend to allow language mappings to provide alternative
    mechanisms for custom marshaling as well as the standard mechanism of
    having the valuetype implementation provide the CustomMarshal methods
    marshal and unmarshal? If not, this paragraph should be deleted. If so,
    the last part of the paragraph should be reworded, for example "... to
    support other ways for value types to implement custom marshaling".

  • Reported: CORBA 2.2 — Wed, 20 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate change in 2.4 and close issue

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

Codebases with multiple URLs

  • Key: CORBA23-40
  • Legacy Issue Number: 2316
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: To support JDK 1.2 correctly, the codebase support for Objects By Value
    needs to support multiple URLs rather than a single URL as at present.

    This affects page 5-16 in the core 2.3a chapters. Either the signatures
    of the implementation and implementations methods need to change to:
    URLSeq implementation(in CORBA::RepositoryId x);
    URLSeqSeq implementations(in CORBA::RepositoryIdSeq x);

    or we need to say that the URL string can be a blank-separated
    sequence of URLs. This also affects the OBV grammar on page 15-19.

  • Reported: CORBA 2.2 — Wed, 20 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue

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

Clarify meaning of no IDL initializers

  • Key: CORBA23-42
  • Legacy Issue Number: 2319
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 3.8.1.5 on page 24 does not make it clear what it means to
    have no initializers for an IDL valuetype. The decision of the OBV
    designers, which is reflected in the C++ and Java language mappings,
    was that this means there is no portable way to create an instance
    of the value type. This should be clearly stated in the definition of
    IDL semantics for valuetypes, not deduced from the language mappings.

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

    Fix it

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

Names of Data*Stream methods

  • Key: CORBA23-38
  • Legacy Issue Number: 2312
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The method names in DataInputStream and DataOutputStream have been
    chosen to match the method names in the Java portability streams.
    There is a proposal before the Java RTF to change some of the latter
    names. If this is accepted, we should change the corresponding names
    in Data*Stream as well.

    This affects page 5-12 in the core 2.3a chapters. write_Value should
    change to write_value and write_Abstract to write_abstract_interface.
    The corresponding read_* methods on page 5-14 should also be changed.

  • Reported: CORBA 2.2 — Wed, 20 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Supporting multiple abstract interfaces

  • Key: CORBA23-39
  • Legacy Issue Number: 2314
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Valuetypes should be able to support multiple abstract interfaces but
    only a single regular interface. See also comments number 28 and 31
    in the list of core 2.3a errata I just sent out.

  • Reported: CORBA 2.2 — Wed, 20 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue.

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

Misleading text in section 3.2.5.2

  • Key: CORBA23-41
  • Legacy Issue Number: 2318
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The second last paragraph in section 3.2.5.2 is confusing. The
    second last sentence says (modulo typos) that since a string is a
    sequence of character literals, a sequence of \u literals can be
    used to define a wide string literal.

    This seems to me to be a non sequitur. The conclusion does not
    follow from the premise. I think this sentence was supposed to say
    that since a wide string is a sequence of wide character literals,
    a sequence of \u literals can be used to define a wide string literal.

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

    Fix it

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

Missing minor code

  • Key: CORBA23-36
  • Legacy Issue Number: 2310
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the 2.3a core chapters, there is a minor code missing from page 3-58,
    table 3-13. BAD_PARAM minor code 1 should also be raised for errors
    trying to lookup and unregister a value factory. Alternatively we could
    add new minor codes for these.

  • Reported: CORBA 2.2 — Wed, 20 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Let minor code one be used for all value factory related exceptions.

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

POA threading policies

  • Key: CORBA23-34
  • Legacy Issue Number: 2303
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The POA offers the SINGLE_THREAD_MODEL policy. It guarantees that, for
    a POA with this policy, all invocations are serialized. (The only other
    threading policy, ORB_CTRL_MODEL, allows to ORB to thread invocations as
    it sees fit.)

    There is a pragmatic problem here: SINGLE_THREAD_MODEL guarantees
    serialization for only a particular POA. This means that if I have a server
    that uses three POAs, all of which use SINGLE_THREAD_MODEL, invocations on
    any one of these POAs are serialized but invocations on different POAs
    can be dispatched in parallel.

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

    No Data Available

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

POA SINGLE_THREAD_MODEL description ambiguous

  • Key: CORBA23-35
  • Legacy Issue Number: 2308
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The description for the SINGLE_THREAD_MODEL policy only states that the
    POA makes all upcalls in a manner that is safe for code that is
    multi-thread-unaware. This statement could be read to disallow
    recursive upcalls from one object implementation to another mediated by
    the same POA on a single thread.

    Proposed resolution:

    Add the following sentence to both sections 9.2.8 and 9.3.7, where the
    text defines the Single Threaded Model:

    A single-threaded POA will still allow recursive upcalls, where an
    object"s implementation invokes an operation on an object implemented
    using the same POA.

  • Reported: CORBA 2.2 — Mon, 18 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Custom marshalling & AbstractBase

  • Key: