Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
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
CORBA23-244 Query Service IDL code CORBA 2.3 CORBA 2.3.1 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-237 Which exceptions should be raised? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-236 Grammar rule issue 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-234 CODESET_INCOMPATIBLE exception is not defined CORBA 1.2 CORBA 2.3 Resolved closed
CORBA23-232 Wide String (and String encoding) CORBA 1.2 CORBA 2.3 Resolved closed
CORBA23-231 IDL TypeExtension correction CORBA 1.2 CORBA 2.3 Resolved closed
CORBA23-233 IDL Type Extensions: DATA_CONVERSION exception CORBA 1.2 CORBA 2.3 Resolved closed
CORBA23-230 OBV chunk boundaries CORBA 2.2 CORBA 2.3 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-225 The insert_dyn_any and get_dyn_any operations are barely documented CORBA 2.3 CORBA 2.3.1 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-221 Object::is_a CORBA 2.0 CORBA 2.3 Resolved closed
CORBA23-220 DII operations "get_response and get_next_response CORBA 1.2 CORBA 2.3 Resolved closed
CORBA23-219 6.5.6. Repository Paragraph 2 - objection CORBA 1.2 CORBA 2.3 Closed; No Change closed
CORBA23-218 Null Value semantics under specified CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA23-217 DynFactory or DynAnyFactory? CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA23-216 is_abstract parameter missing from create_interface() IDL CORBA 2.3 CORBA 2.3.1 Resolved 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-211 Typo on pages 10-53, 10-55, and 10-70 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-210 Proposal for creating recursive TypeCodes 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-208 Missing orb.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-207 Incorrect LifeCycle IDL? CORBA 2.2 CORBA 2.3 Resolved 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-201 TypeCode comparison proposal (01) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-200 Description of Wide String type 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-192 Typos in IR IDL in Specification (050 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-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
CORBA23-165 CDR encoding for fixed CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-166 LocateRequest and LocateReply messages CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-167 profile ids & component ids CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA23-168 Need clarification on GIOP::TargetAddress CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA23-84 Incorrect IDL is section 5.5.3 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-82 forward declaration in ptc/98-10-04 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-92 UNIQUE_ID and ServantActivator issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-91 Clarification on IdUniquenessPolicy 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-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-87 Repository ID for Object 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-70 Inconsistent spellings of "policy" related identifiers: CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-69 IR Changes in 2.3 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-63 Interceptors broken 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-61 Try to define obligatory and optional parts of the CORBA specification. 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-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-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-75 Need to specify exception for abstract interface error 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-72 Inconsistent Definition of Flags type CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-71 CORBA::Object::ping ? 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-77 omg.org prefix not well specified 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-67 Inheritance of value types 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-65 POA Construction Policy. CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-64 another problem with IDL specification section 3.9.2 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-57 Grammar section 3.9.2 missing "float" rules, and other problems 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-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-42 Clarify meaning of no IDL initializers 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-56 Calling get_response twice? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-55 Forward-Declared Interfaces CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-47 No description for ValueBoxDef CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-46 is_a description is wrong 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-49 Text was inserted in wrong place 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-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-28 Core uses both "standard" and "system" exception terminology 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-26 Need namespace for Policy Type CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-40 Codebases with multiple URLs CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-39 Supporting multiple abstract interfaces CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-38 Names of Data*Stream methods 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-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-31 uses of recursive_tc CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-37 Custom Marshaling clarification CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-36 Missing minor code CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-33 Custom marshalling & AbstractBase CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-32 Sequences of recursive structs/unions 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-34 POA threading policies 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-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-17 What does interface substitutability mean in CORBA? 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-12 Handling of minor codes for standard exceptions underspecified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-11 page 3-47: Identifiers CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-14 Missing equality for DynAny CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-13 set_servant_manager CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-10 Nested scopes 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-8 Change to IDL for anonymous types CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-7 DynStruct::get_members needs exception 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-18 Recursive IDL types CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-15 DynUnion::member() 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

Issues Descriptions

question re BiDir IIOP

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

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

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

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

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

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

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

Query Service IDL code

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

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

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

    No Data Available

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

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

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

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

"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

CODESET_INCOMPATIBLE exception is not defined

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

    Summary: CODESET_INCOMPATIBLE is not defined in CORBA 2.0, and so must be added to the list of standard exceptions in section 3.15.1

  • Reported: CORBA 1.2 — Tue, 4 Feb 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    resolved is current core 2.3 draft, issue closed

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

Wide String (and String encoding)

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

    Summary: Are the string lengths number of bytes or characters (in 3.1.2 of orbos/96-02-03)?

  • Reported: CORBA 1.2 — Tue, 1 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    resolved in current 2.3 draft, close issue

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

IDL TypeExtension correction

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

    Summary: There is an error in the grammar as written, so that you cannot (for example) have attributes of type wstring.

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

    resolved in Core 2.3 draft, close dissue

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

IDL Type Extensions: DATA_CONVERSION exception

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

    Summary: Algorithm on p. 27 says to raise DATA_CONVERSION exception, but textual description on p. 28 par 1 specifies CODESET_INCOMPATIBLE exception when client and server native codesets aren"t compatible

  • Reported: CORBA 1.2 — Tue, 4 Feb 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    resolved is current 2.3 draft, closed issue

  • 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

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

The insert_dyn_any and get_dyn_any operations are barely documented

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

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

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

    "The get_dyn_any and

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

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

Object::is_a

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

    Summary: Some ORBs are sloppy about existence. One ORB used raises INV_OBJREV whenever object doesn"t exist, even when server can be reached. Behavior is compliant..tighten spec here.

  • Reported: CORBA 2.0 — Tue, 22 Apr 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    close no change in 2.4

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

DII operations "get_response and get_next_response

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

    Summary: Both operations permit the flag CORBA::RESP_NO_WAIT to be set. How is is invoker being informed that there is no response available? Incorrect to use exception.

  • Reported: CORBA 1.2 — Wed, 18 Dec 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    resolved, closed issue

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

6.5.6. Repository Paragraph 2 - objection

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

    Summary: Para indicates that there may be more than 1 interface Repository in any given environment. How can portable application determine this, and how can it determine what the requirements are?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.3
  • Disposition Summary:

    the application should use either the naming or trading service to determine which IR to use.

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

Null Value semantics under specified

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

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

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

    close issue, no change

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

DynFactory or DynAnyFactory?

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

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

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

    No Data Available

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

is_abstract parameter missing from create_interface() IDL

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

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

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

    No Data Available

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

profile ids & component ids

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

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

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

    editorial change to CORBA 3.0 resolved

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

Need clarification on GIOP::TargetAddress

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

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

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

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

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

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

    withdrawn by submitter...issue closed

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Core uses both "standard" and "system" exception terminology

  • Key: CORBA23-28
  • Legacy Issue Number: 2221
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The core chapters (chapter 3, for example) uses both "standard" and
    "system" to describe the same class of exceptions. Most of the core
    seems to prefer "standard", however the C++ language mapping uses
    SystemException.

    The core should be cleaned up to use "standard" as the normal term, and
    then state that "system" is used in some language mappings as a synonym.

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

    No Data Available

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

create_policy specification needs to be completed

  • Key: CORBA23-27
  • Legacy Issue Number: 2214
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The specification of the create_policy operation in Chapter 4 section
    4.9.2 (ptc-98-10-05, 5 November 98) is missing the following important
    elements:

    1. There is no specification of what is expected of someone who is
    defining a new policy type, in order to use this operation as the
    factory for policy objects of that type.

    2. Policy objects of wich of the PolicyTypes can be created using this
    operation in release 2.3 is not specified. Consequently, the types that
    are valid as input through the "val" parameter are unspecified also.

  • Reported: CORBA 2.2 — Mon, 16 Nov 1998 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

Need namespace for Policy Type

  • Key: CORBA23-26
  • Legacy Issue Number: 2206
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: To allow vendors to define their own value added Policies, the
    PolicyType should be partitioned into spaced that can be assigned to
    vendors. Since the PolicyType is a CORBA long, just like the system
    exception minor code, we can just reuse the VMCID for this purpose.

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

    resolved and closed

  • 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

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

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

Scoping resolution for member names

  • Key: CORBA23-25
  • Legacy Issue Number: 2202
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The wording of the current 2.3 spec says nothing to suggest that member names in structs are in (or
    out) of the scope of the struct. That is, whether

    struct s {
    struct t

    {...}

    t;
    };

    is legal or illegal.

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

    Close this issue in 2.4 noting that the resolution of issue 1893 subsumes this issue.

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

Typo in POA

  • Key: CORBA23-24
  • Legacy Issue Number: 2200
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On P. 11-52 I see:

    ...Assuming the POA has the USE_SERVANT_MANAGER policy and no servant
    manager is associated with a POA, any request received by the POA for
    an Object Id value not present in the Active Object Map will result
    in an OBJECT_NOT_EXIST exception.

    However on P. 11-9:

    If the POA has the USE_SERVANT_MANAGER policy, a servant manager
    has been associated with the POA so the POA will invoke incarnate or
    preinvoke on it to find a servant that may handle the request. (The
    choice of method depends on the NON_RETAIN or RETAIN policy of the
    POA.) If no servant manager has been associated with the POA, the POA
    raises the OBJ_ADAPTER system exception.

  • Reported: CORBA 2.2 — Mon, 9 Nov 1998 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

void * in DII Chapter

  • Key: CORBA23-23
  • Legacy Issue Number: 2162
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Now that we have the native type, it is time to replace those void *s in
    the DII specification PIDL and restate them in terms of native types.

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

    Incorporate changes in text and close issue.

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

is_a underspecified

  • Key: CORBA23-30
  • Legacy Issue Number: 2230
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the description of is_a suffers from the same problem that we fixed for
    non_existent in 2.3: it is not clear what the operation should do if
    it could not make a determination due to a hard error. This means that
    the application does not know whether failure to make a determination
    returns false, or whether that will raise an exception (and false is
    returned only if the object doesn"t have the expected type).

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

    clarify

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

Local operations on CORBA::Object

  • Key: CORBA23-29
  • Legacy Issue Number: 2223
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Basically, people get confused about which operations on CORBA::Object
    can go remote. It"s clear from the GIOP spec that only non_existent(),
    is_a(), get_interface(), and get_domain_managers() can go on the wire.
    It follows that things like nil(), hash(), and is_equivalent() must be
    local. However, as Owen Rees pointed out, this only applies to GIOP, not
    the core, but a compliant ORB need not provide GIOP.

    It seems that it would be a good idea to add some clarification to the core
    to state which operations on CORBA::Object must be local and which ones
    may (but need not) go remote.

  • Reported: CORBA 2.2 — Thu, 19 Nov 1998 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

uses of recursive_tc

  • Key: CORBA23-31
  • Legacy Issue Number: 2235
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: According to ptc/98-10-08, 16 Oct. 98 [REVIEW], p. 10-53,
    "Once the recursive TypeCode has been properly embedded in the
    enclosing TypeCode which corresponds to the specified repository
    id, it will function as a normal TypeCode."

    Given the following idl:

    valuetype v

    { public v m0; }

    ;

    And the following C++ code to generate the typecode for v:

    CORBA::ORB_ptr orb = ...;
    CORBA::TypeCode_ptr tcRecursive =
    orb->create_recursive_tc("IDL:v:1.0");
    CORBA::ValueMemberSeq v_seq;
    v_seq.length(1);
    v_seq[0].type = tcRecursive;
    ...
    CORBA::TypeCode_ptr tcV = orb->create_value_tc("IDL:v:1.0", "v",
    VM_NONE, CORBA::TypeCode::_nil(),
    v_seq);

    After tcRecursive has been properly embedded, what does "tcRecursive
    functioning
    like a normal TypeCode" mean? Does it mean that one can call on
    tcRecursive the same
    methods that are available on tcV? For example, will

    CORBA::Visibility vis = tcRecursive->member_visibility(0);

    work?

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

    Close no change in 2.4

  • 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

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

Custom marshalling & AbstractBase

  • Key: CORBA23-33
  • Legacy Issue Number: 2296
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The 2.3a draft defines DataOutputStream as having the following
    operation (see p. 5-12):

    void write_Abstract(in AbstractBase value);

    Yet there is no definition of the type `AbstractBase" anywhere
    in the document.

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

    Add AbstractBase as a native type in the CORBA module, together with explanation in Chapter 6.

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

Sequences of recursive structs/unions

  • Key: CORBA23-32
  • Legacy Issue Number: 2275
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If I have a recursive struct or union type and want to pass a sequence
    of that type to an operation, I am completely stuck if I want to do
    this with C++. I"m not sure about other mappings, but I expect that
    Java, Ada, etc. will all suffer from the same problem.

  • Reported: CORBA 2.2 — Mon, 21 Dec 1998 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

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

Exception for abstract interface inheritance

  • Key: CORBA23-22
  • Legacy Issue Number: 2156
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Abstract interfaces can only inherit from other abstract interfaces,
    yet the Interface Repository chapter (98-10-08) does not define the
    behavior of an InterfaceDef object when an attempt is made to violate
    this rule.

    Text should be added to section 10.5.23.2 defining the behavior of
    the mutators is_abstract and base_interfaces.

    Since none of the BAD_PARAM minor codes really apply, it appears
    that a new one is needed.

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

    No Data Available

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

long double problem?

  • Key: CORBA23-21
  • Legacy Issue Number: 2119
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: (2.2 3-24) and (2.2 13-8)
    I"m no floating point expert, but it seems to me that these two
    definitions are inconsistent. The first implies 1 + 15 + 64 = 80
    bits of information, while the second implies 1 + 15 + 112 = 128 bits
    of information.

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

    No inconsistency exists as explained in the archive.

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

Lifetime of ORB and validity of ORB pointe

  • Key: CORBA23-6
  • Legacy Issue Number: 1665
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In CORBA 2.2 added the ORB::shutdown operation. What operations are
    valid during the potentially lengthy shutdown process while ongoing
    operations complete? What is the validity of the ORB reference after the
    shutdown? Is the ORB destroyed? Can a new ORB be reconstituted by
    ORB_init?

    This issue came up during the port-rtf discussion for CORBA 2.3. It goes
    beyond considerations for the POA so it should be addressed by
    orb_revision.
    r

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

    Fix the problem as described below

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

Semantics of system exception completion_status

  • Key: CORBA23-5
  • Legacy Issue Number: 1315
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The CORBA 2.2 spec says the following about completion_status:

    Each standard exception also includes a completion_status code which
    takes one of the values

    {COMPLETED_YES, COMPLETED_NO, COMPLETED_MAYBE}

    .
    These have the following meanings:

    COMPLETED_YES The object implementation has completed processing prior
    to the
    exception being raised.
    COMPLETED_NO The object implementation was never initiated prior to the
    exception
    being raised.
    COMPLETED_MAYBE The status of implementation completion is
    indeterminate.

    These definitions do not cover the case where the standard exception was
    raised by the object implementation itself.

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

    No Data Available

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

What does interface substitutability mean in CORBA?

  • Key: CORBA23-17
  • Legacy Issue Number: 1997
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Thanks to Joaquin Miller, a question came up in the context of the OMA
    revision work that is going on in ORMSC about what the ORB vendors think
    "substitutability" means.

  • 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 20:58 GMT

Which OBV initialiser to run is under-specified

  • Key: CORBA23-16
  • Legacy Issue Number: 1981
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Detail: The 2.3 draft says:

    There may be any number of init declarations, as long as the signatures
    of all the initializers declared within the same scope are unique.

    To me, this implies that initialiser selection is done by matching the actual call parameter types against the formal parameter types in all the initialisers, and choosing the one that applies. However (a) this isn"t said explicitly and (b) if it is the intention, it"s fairly easy to construct a case where no one initialiser is more applicable than any other. Assuming initialiser parameters are allowed to be interface types (it doesn"t say they aren"t), consider a declaration of two initialisers in the same scope with parameter interfaces A and B, then calling the initialiser with a parameter of C, an interface that inherits from both A and B. It is impossible to say that one initialiser is more or less applicable than the other. The specification should make clear what choice a compliant ORB should make.

  • Reported: CORBA 2.2 — Sun, 20 Sep 1998 04: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

Handling of minor codes for standard exceptions underspecified

  • Key: CORBA23-12
  • Legacy Issue Number: 1969
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Looking at ptc-98-08-07, I find the discussion of minor codes hopelessly
    underspecified. The text in 3.17.2 doesn"t actually mention the OMG
    space explicitly; it should. Also, the definition of the partitioning
    of the minor code, at the beginning of 3.17, is hopelessly vague – what
    ``high order bits"" are used, what ``low order bits""? What"s the
    policy for obtaining a new vendor registration?

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

    I believe that this issue has been adequately addressed in the 2.3a revision. So I propose that we c

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

page 3-47: Identifiers

  • Key: CORBA23-11
  • Legacy Issue Number: 1893
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 3-47:

    "Identifiers for the following kinds of definitions are scoped:

    • types
    • constants
    • enumeration values
    • exceptions
    • interfaces
    • attributes
    • operations"

    I"m not sure I understand the purpose of this list. In particular, what
    is meant by "are scoped"? Scoped by what? I think the intent was to state
    that if any of these identifiers appears within a nested scope, it needs
    to be unique only within that nested scope?

  • Reported: CORBA 2.2 — Thu, 27 Aug 1998 04: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

Missing equality for DynAny

  • Key: CORBA23-14
  • Legacy Issue Number: 1972
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Type DynAny has no equality operator. This makes it impossible
    to determine whether or not two DynAnys contain the same value, unless
    I am prepared to recursively iterate over all of a DynAny"s components
    to determine whether they are equal. This is rather inconvenient.

    I would suggest to add a new operation to DynAny:

    boolean equal(in DynAny da);

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

    added comparison operator

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

set_servant_manager

  • Key: CORBA23-13
  • Legacy Issue Number: 1970
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What exception should POA::set_servant_manager raise if the wrong servant
    manager type is passed? For example, if a POA has RETAIN and I try to
    register a ServantLocator, should set_servant_manager raise WrongPolicy, or
    some system exception? With respect to set_servant_manager, the spec says

    "This method requires the USE_SERVANT_MANAGER policy; if not present, the
    WrongPolicy exception is raised."

    Because WrongPolicy is used to denote whether set_servant_manager can be
    called correctly or not, it seems like the wrong exception to also use for
    the case of passing the wrong servant manager type. May I suggest that
    BAD_PARAM be raised in that case instead?

  • Reported: CORBA 2.2 — Thu, 24 Sep 1998 04: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

Nested scopes

  • Key: CORBA23-10
  • Legacy Issue Number: 1892
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The name of an interface or a module may not be redefined within
    the immediate scope of the interface or the module. For example:

    module M {
    typedef short M; // Error: M is the name of the module
    in the scope of which the typedef is.
    interface I

    { void i (in short j); // Error: i clashes with the interface name I }

    ;
    };

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

    Incorporate changed text and close issue in 2.4

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

Multiple paths to a recursive sequence typecode

  • Key: CORBA23-9
  • Legacy Issue Number: 1802
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What exactly is the story for how the TypeCodes are created? Is there
    one call to create_recursive_sequence_tc per recursive sequence template in the
    source, or one per cycle in the type graph? I think this is worth clarifying
    in section 8.7.3, which doesn"t seem to conceive of the possibility of multiple
    type graph cycles through the same recursive sequence type.

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

    This was fixed in the process of resolving issue 1928 in Core Revision 2.3a. See resolution of 1928.

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

Change to IDL for anonymous types

  • Key: CORBA23-8
  • Legacy Issue Number: 1729
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Secondly, anonymous types are generally a pain to deal with
    for a language mapping. I know that anonymous sequences are
    a necessary evil because they are needed to define recursive
    structs and recursive unions. For example:

    struct node

    { long data; sequence<node> children; }

    ;

    However, IDL allows anonymous sequences and arrays to be used
    in other ways for which they are not essential.

  • 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 20:58 GMT

DynStruct::get_members needs exception

  • Key: CORBA23-7
  • Legacy Issue Number: 1679
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If get_members is called on a DynStruct whose members have not been
    initialized, what should it do? It can"t return any values, because there
    are none.

    I suggest allowing it to raise DynAny::Invalid in this case. If there are
    objections to adding a raises clause, I suggest having it raise BAD_INV_ORDER.

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

    incorproate changes and close issue in 2.4

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

Recursive exceptions?

  • Key: CORBA23-20
  • Legacy Issue Number: 2084
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is the following IDL legal?

    exception e

    { sequence<e> e_seq; }

    ;

    The grammar permits it, so from that, I would have to conclude it"s legal.
    However, not all ORBs I"ve tried can handle this – some accept it and it
    works, others accept it but generate bad code, and yet others won"t compile
    the IDL.

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

    No Data Available

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

InconsistentTypeCode exception in CORBA 2.3

  • Key: CORBA23-19
  • Legacy Issue Number: 2070
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current CORBA 2.3 ORB interface chapter (ptc/98-08-08) does not
    match the resolution which was voted on for the InconsistentTypeCode
    exception (issue 1089).

    The proposed resolution from ptc/98-05-01 was to place the exception
    in the ORB interface with InvalidName, not in the CORBA module.
    Jishnu, could we correct this mistake by moving InconsistentTypeCode
    from the CORBA module into the ORB interface?

  • Reported: CORBA 2.2 — Sat, 10 Oct 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Already fixed in 2.3a Draft

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

Recursive IDL types

  • Key: CORBA23-18
  • Legacy Issue Number: 2034
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current spec is not terribly clear on how recursive IDL types are
    supposed to work.A minor problem here is that the terminating semicolon is missing following
    the closing curly brace.

    But more seriously, it leaves it open whether, for example, the following
    is legal:

    struct foo {
    union u switch (long)

    { case 0: sequence<foo> foo_mem; case 1: char c_mem; }

    u_mem;

    long l_mem;
    };

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

    No Data Available

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

DynUnion::member()

  • Key: CORBA23-15
  • Legacy Issue Number: 1974
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What does DynUnion::member() return if a union does not have a default
    case label and has no active member? A nil reference? A DynAny
    with TCKind tk_null?

    It"s not specified, but should be.

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

    incorporate change and close in 2.4

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

resolve_initial_references under-specified

  • Key: CORBA23-4
  • Legacy Issue Number: 1156
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: resolve_initial_references can raise an InvalidName exception. However,
    the text in section 4.5 does not attach any semantics to that exception
    (in fact, it does not mention the exception at all).

    The spec needs to state explicitly when InvalidName should be raised.
    Presumably, the intent was that it would be raised for unknown ObjectIds,
    such as "XXXX".

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

    Needs no further action in Core RTF. Close this issue no change.

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

Domain Manager related specification shortcoming (02)-ConstructionPolicy

  • Key: CORBA23-3
  • Legacy Issue Number: 1154
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2) The associated ConstructionPolicy object does not provide any
    facility for allocating an object reference to any domain manager other
    than the domain manager to which the creator (if an object) belongs or a
    completely new domain manager.

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

    This issue is included in the mandatory requirements of the Security Domain Membership management R

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

Domain manager related specification shortcoming(s) (01)

  • Key: CORBA23-2
  • Legacy Issue Number: 1153
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1) The specification lacks any operations for moving an object reference
    from one domain manager to another, thus making the domain manager
    abstraction less useful as a means for managing allocation of policies
    to groups of object references, the memberships of which change over a
    period of time.

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

    This issue is included in the mandatory requirements of the Security Domain Membership Management R

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

Operation to add to CORBA::ORB pseudo-object

  • Key: CORBA23-1
  • Legacy Issue Number: 991
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The following operations should be added to the CORBA::ORB
    pseudo-object:

    module CORBA {
    interface ORB

    { ... typedef sequence<octet> SerializedData; typedef unsigned long SerializedEncoding; const SerializedEncoding CDR_ENCODING = 0; SerializedData serialize(in Any data, in SerializedEncoding how); Any unserialize(in SerializedData data, in SerializedEncoding how); ... }

    ;
    };

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

    Close no change in 2.4

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