Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — All Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA34-450 Standard uuid for interfaces (COM/CORBA Part A) CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-449 Section 4.1.18.5 enum should be named CORBA_CompletionStatus CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-430 Automation View should generate HRESULT DISP_E_TYPEMISMATCH CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-435 boundary violations should cause View to propagate DISP_E_OVERFLOW CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-433 page 4-129, section 4.1.17: change term "CORBA proxy" CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-439 ODL is erroneous CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-434 page 4-129, section 4.1.17.1: retval attribute CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-438 Page 2-41, section 2.9.7.2 Add name for Automation View interface CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-437 page 2-30: There is a label "Examples", but no examples CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-436 page 4-109, section 4.1.5.3: editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-432 INSTANCE_Clone does not need an in-parameter CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-431 Dispatch versions of DCORBAObject and DORBObject CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-443 Add CORBATCKind to end of enum list CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-442 Return value type of DICORBATypeCode::member_type should be changed CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-447 What should Automation View accept in bounded sequences? CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-444 Remove EX_repositoryID readonly property from IForeignException CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-445 Section 4.1.12: DICORBA TypeCode::kind CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-440 page 2-25 contradicts first sentence of 3rd full para on p 4-106 CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-441 uuid for DForeignException has an extra 0 CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-448 VB cannot handle array out-parameters CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-446 Standard ProgramId CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-252 Purpose of related LockSet CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-250 Who is responsible for releasing locks in transaction? CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-251 Which model should ConcurrencyControl support? CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-227 interface QueryEvaluator { CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-12 Incorrect mappings for systems exceptions (part A) CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-10 Section 13A.2.3: editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-11 Capter 13C: Editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-9 Section 13A.5.2: Editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-7 Duplicate union labels CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-5 Section 13C.1.3 Editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-6 COM Sequence changes CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-4 Levels of Indirection for passing COM types CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-8 Changes to ForeignComplexType CORBA 2.0 CORBA 3.4 Deferred closed
CORBA21-113 RMI repository ID references to serial version UID CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-112 Second bit of response_flags CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-111 Issue: Problem with issue 2801 resolution CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-110 fragmentation broken with bi-dir giop CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-109 CODESET_INCOMPATIBLE exception CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-108 A Messaging related issue in GIOP 1.2 CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-107 IIOP 1.2 fragmentation presents an unrecoverable error situation CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-106 New IDL types CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-105 Narrow Interop CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-104 Contents of MultiComponent component an encapsulation? CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-103 Type any marshalling rules force slow implementation CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-102 Marshalling of union type codes CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-101 Typecode encoding is too long CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-100 Type code marshalling CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-99 Typecode indirection issue CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-98 No provision for numbering the fragments in fragmented IIOP messages CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-97 CDR encoding of TypeCodes CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-96 Correct CDR encoding of an empty string CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-95 Typecode equality CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-94 Wchar and Char can both be multibyte CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-93 Issue about CDR encoding for wide characters CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-92 Query about GIOP and IIOP version numbers in 98-01-03 CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-91 GIOP Exception formatting description (12.4.2) CORBA 2.0 CORBA 2.1 Resolved closed
CORBA23-221 Object::is_a CORBA 2.0 CORBA 2.3 Resolved closed
CORBA21-90 OMG IDL prefix pragma CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-89 Description of constant expression semantics is unclear CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-88 Object terminal missing from IDL grammar CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-87 WRONG_TRANSACTION CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-86 OTS 1.1 specification changes CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-85 Interface Repository CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-80 Bug in C++ NVList mapping CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-31 Page 13C-36: Editorials CORBA 2.0 CORBA 2.1 Resolved closed
CORBA22-125 Issue with service context CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-124 CloseConnection messages CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-123 1.0 backward compat (2) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-122 1.0 backward compat (1) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-121 Fragment improvements (2) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-120 Fragment improvements (1) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-119 IDL Type Extensions: wstring CDR encoding issue CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-118 IDL Type Extensions: wchar and wstring CDR encoding CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-117 Type extensions char code set negotiation CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-116 Type Extensions and code set negotiation CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-138 C mapping for list_initial_services is incorrect CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-80 Native types with respect to typecodes, DII, DSI,Interface Reposit. CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-79 TypeCode equality CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-78 Do identifiers and keywords clash if they differ in case? CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-77 Section 3.7.2: take new IDL type extensions into account CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-76 Section 7.8: editorial CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-75 Syntax for basic types must be updated CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-74 create_exception() is declared outside any interface scope CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-73 TCKind enum should be updated CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-72 No defined value for OBJECT_NIL CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-71 Section 7.2: get_implementation function CORBA 2.0 CORBA 2.2 Closed; No Change closed
CORBA22-70 sec 17.7.1: IDL for interface request doesn"t match C++ mapping CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-69 Sequence parameter specified is ignored CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-68 request() should be added to IDL (section 17.13.2) CORBA 2.0 CORBA 2.2 Closed; No Change closed
CORBA22-67 Section 16.7: only C++ mapping defines string_free and string_dup CORBA 2.0 CORBA 2.2 Closed; No Change closed
CORBA22-66 limited-length strings CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-65 Question about IDL grammar CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-64 "service"~~operation or interface? CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-63 What exactly is a request CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-62 inherit vs. include CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-61 Scope and use of prefix pragma in IDL-style repository IDs CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-60 Terminology consistency CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-59 Enums and enumerators CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-58 Internationalization CORBA 2.0 CORBA 2.2 Resolved closed
CPP11-124 IIOP server-initiated connection closure problem CORBA 2.0 CPP 1.0 Resolved closed

Issues Descriptions

Standard uuid for interfaces (COM/CORBA Part A)

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

    Summary: (D)IForeignComplexType,(D)ICORBAStruct,(D)ICORBAUnion,(D)IForeignException,(D)ICORBAUserException should have standard UUIDs and UUID identifiers

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Section 4.1.18.5 enum should be named CORBA_CompletionStatus

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

    Summary: The enum should be named CORBA_CompletionStatus instead of CORBA_ExceptionType

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Automation View should generate HRESULT DISP_E_TYPEMISMATCH

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

    Summary: If number of dimensions of an input SAFEARRAY does not match the mapped CORBA type, the Automation View should generate the HRESULT DISP_E_TYPEMISMATCH

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

boundary violations should cause View to propagate DISP_E_OVERFLOW

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

    Summary: When translating a BSTR to a CORBA bounded string, boundary violations should cause the View to propagate DISP_E_OVERFLOW

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

page 4-129, section 4.1.17: change term "CORBA proxy"

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

    Summary: Second to last paragraph of the section contains the term "CORBA proxy" which should be changed to Automation View Interface.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

ODL is erroneous

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

    Summary: ODL which shows an extra, optional parameter for exception information on property-get or property-set method is erroneous, since MKTYPLIB doesn"t allow extra parameter on property accessor

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

page 4-129, section 4.1.17.1: retval attribute

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

    Summary: The "retval" attribute should be removed from the second argument in both methods. MIDL does not have a retval attribute

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Page 2-41, section 2.9.7.2 Add name for Automation View interface

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

    Summary: There should be a standard name for the Automation View interface.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

page 2-30: There is a label "Examples", but no examples

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

    Summary: Page 2-30, top of page, end of section 2.7.1: There is a label "Examples:" but no example follows

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

page 4-109, section 4.1.5.3: editorial

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

    Summary: "..maximum value of an Automation short" should read "..maximum value of a CORBA::UShort

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

INSTANCE_Clone does not need an in-parameter

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

    Summary: INSTANCE_Clone does not need an in-parameter to specify the instance to be cloned.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Dispatch versions of DCORBAObject and DORBObject

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

    Summary: There should be straight dispatch versions of DCORBAObject and DORBObject

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Add CORBATCKind to end of enum list

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

    Summary: Enum CORBATCKind omits the boolean kind (p.4-123, section 4.1.12) I recommend adding it to the end of list to preserve backward compatibility. Also missing tk_char.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Return value type of DICORBATypeCode::member_type should be changed

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

    Summary: The return value type should be DICORBATypeCode*, not IDispatch. The return value of member_label should be a DICORBAAny* rather than VARIANT

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

What should Automation View accept in bounded sequences?

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

    Summary: When mapping bounded sequences, should the Automation View accept as an in-parameter a Safearray whose upper bound is less than the maximum lenght of the mapped sequence?

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred Automatically

    This proposal was generated automatically.

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

Remove EX_repositoryID readonly property from IForeignException

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

    Summary: This property should be removed because the INSTANCE_repositoryId property in IForeignComplexType provides this functionality

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Section 4.1.12: DICORBA TypeCode::kind

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

    Summary: Section 4.1.12: DICORBAtypeCode::kind has one parameter of type TCKind. It should be of type CORBATCKind

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

page 2-25 contradicts first sentence of 3rd full para on p 4-106

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

    Summary: I suggest that the automation chapter be changed to align with the architecture chapter

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

uuid for DForeignException has an extra 0

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

    Summary: The uuid for DForeignException has an extra 0. It should be E977F907-3B75-11cf-BBFC-444553540000

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

VB cannot handle array out-parameters

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

    Summary: The VB cannt handle array out-parameters. Must use in-outs.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Standard ProgramId

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

    Summary: There should be a standard ProgramId for the class which exposes D(I)CORBAAny

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Purpose of related LockSet

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

    Summary: In the specification, "Related lock sets" appears only in "create_related()" and create_transaction_related()" Where do I use these methods

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Who is responsible for releasing locks in transaction?

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

    Summary: In lock duration of Section 7.1 there are two descriptions. The role of the clients is vague to me

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Which model should ConcurrencyControl support?

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

    Summary: There is inconsistency regarding which model ConcurrencyControl needs to support

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

interface QueryEvaluator {

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

    Summary: I understand the params to be name value pairs of columns and the values for the
    selection, update, delete, insert criteria
    what is in the query? I would think if this is the whole query why would you
    need the params??

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Incorrect mappings for systems exceptions (part A)

  • Key: CORBA34-12
  • Legacy Issue Number: 679
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: Section 4.1.18.6 Table 4-14: A few of these mappings don"t seem to make sense (i.e. the meaning of the different exceptions in each object system is much different

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Section 13A.2.3: editorial

  • Key: CORBA34-10
  • Legacy Issue Number: 707
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: Example of "on both machines" does nor correspond to the diagrams. Add "on an intermediate machine" to sentence

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Capter 13C: Editorial

  • Key: CORBA34-11
  • Legacy Issue Number: 709
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: There are a bunch of code samples that use a different font than the rest of the document

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Section 13A.5.2: Editorial

  • Key: CORBA34-9
  • Legacy Issue Number: 708
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: Third bullet should read:"...are sorted based upon interface name.." Last bullet should read "..the operations introduced in the current interface are mapped last and ordered.."

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Duplicate union labels

  • Key: CORBA34-7
  • Legacy Issue Number: 704
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: When multiple union labels resolve to the same union member, the property accessor for that union member has an additional (optional) argument

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Section 13C.1.3 Editorial

  • Key: CORBA34-5
  • Legacy Issue Number: 710
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: On page 9, paragraph beginning with "Within an interface...." should read "..attributes should appear after operations..."

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

COM Sequence changes

  • Key: CORBA34-6
  • Legacy Issue Number: 703
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: Change the layout of both bounded and unbounded sequences to be the same

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Levels of Indirection for passing COM types

  • Key: CORBA34-4
  • Legacy Issue Number: 702
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary:

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Changes to ForeignComplexType

  • Key: CORBA34-8
  • Legacy Issue Number: 701
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: The following methods should be added to DIForeignComplexType, IID should be changed: string type_name(); string scoped_name(); string_repository_id(); more details in corresponding archive file

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

RMI repository ID references to serial version UID

  • Legacy Issue Number: 4283
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    CORBA formal 00-11-03 10.6.2 states

    "If the actual serialization version UID for the Java class differs from
    the hash code, a colon and the actual serialization version UID
    (transcribed as a 16 digit upper-case hex string) shall be appended to
    the RepositoryId after the hash code."

    Please comment on the following assertions. The CORBA spec is vague
    here, and it has resulted in incompatible interpretations which must be
    resolved quickly.

    1) The "actual serialization version UID" mentioned is as defined in
    the Java Object Serialization specification.

    http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/class.doc6.html#4100

    Based on this Java specification and its note that "If the SUID is not
    declared for a class, the value defaults to the hash for that class":

    2) If a serialVersionUID field is defined in the class with the proper
    modifiers, its value is used as the "actual serialization version UID"
    mentioned in the CORBA spec

    3) If a serialVersionUID field with the proper modifiers is not
    explicitly defined in a class, its value is computed as explained in the
    Java Object Serialization spec, and this computed value is used as the
    "actual serialization version UID" mentioned in the CORBA spec

    4) It is required by the CORBA spec to always include the Java
    serialVersionUID (as computed in assertions 2 and 3 above) in the RMI
    repository ID if the value is different than the OMG hash code (for
    which the algorithm is defined in CORBA formal 00-11-03 10.6.2)

    5) It is not acceptable to leave off the SUID portion of the RMI
    repository ID if the serialVersionUID field is merely absent from the
    Java class

  • Reported: CORBA 2.0 — Wed, 25 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    closed, withdrawn by submitter

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Second bit of response_flags

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

    The question below was posted to the corba-dev list. I have to admit
    that I don't understand the purpose of the second-least significant bit
    of response_flags either. From the text in the spec, it appears that
    this bit is set if a request expects a response and is not invoked via
    the DII, whereas if a request is oneway or invoked via the DII with
    INV_NO_RESPONSE set, the bit is clear.

  • Reported: CORBA 2.0 — Tue, 2 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    closed issue ...clarified

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Issue: Problem with issue 2801 resolution

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

    Summary: > > Add the following paragraph to 15.8:
    > >
    > > "To avoid collisions of requestId in fragment messages when
    > > bi-directional GIOP is in use:
    > >
    > > - a request may not be sent by an endpoint if a reply has been
    > > sent by that endpoint without a terminating fragment.
    > >
    > > - a reply may not be sent by an endpoint if a request has been
    > > sent by that endpoint without a terminating fragment."
    > >
    >
    > Why is a plain (non-fragmented) request/reply prohibited here? There has
    > never been and feature interaction between fragmented request/replies and
    > non-fragmented ones, so why have this restriction.

    Jishnu Mukerji wrote:

    > After poking around some it seems to me that the following words address
    > Martin"s concern and hence the issue of inadvertently disallowing something
    > that wasn"t broken in the current resolution of 2801. The additional word
    > "fragmented" in two places is bracekted between "*"s.
    >
    > "To avoid collisions of requestId in fragment messages when
    > bi-directional GIOP is in use:
    >
    > - a fragmented request may not be sent by an endpoint if a
    > fragemented reply has been sent by that endpoint without a terminating
    >fragment.
    >
    > - a fragemented reply may not be sent by an endpoint if a
    > fragmented request has been sent by that endpoint without a terminating
    >fragment."

  • Reported: CORBA 2.0 — Wed, 15 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved, see below

  • Updated: Sat, 7 Mar 2015 04:35 GMT

fragmentation broken with bi-dir giop

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

    Summary: I wish to raise the following as an urgent issue:

    The way that message fragments are encoded in giop 1.2, in conjunction
    with the giop 1.2 specification for bi-directional use of a connection,
    can lead to situations where the protocol is ambiguous.

    (This is urgent because it is impossible to implement the bi-directional
    part of GIOP 1.2 without it.)

  • Reported: CORBA 2.0 — Tue, 13 Jul 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

CODESET_INCOMPATIBLE exception

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

    Summary: if a code set negotiation fails the CORBA 2.3 specfication says that a
    CODESET_INCOMPATIBLE exception is to be raised. There doesn"t seem to be
    any further reference to a CODESET_INCOMPATIBLE exception elsewhere. So
    where is the CODESET_INCOMPATIBLE exception defined? Or should it read
    INV_OBJREF?

  • Reported: CORBA 2.0 — Thu, 22 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

A Messaging related issue in GIOP 1.2

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

    Summary: Tom and I have discovered a minor outage in GIOP 1.2 relative to the
    Messaging spec. The outage exists if we want to keep the door open for
    publishing Messaging before GIOP is revved again. If we do not fix this
    the publishing of Messaging will have to wait until the next rev of
    GIOP. The outage is the following:

    1) In the Request header the boolean field "response_expected" was
    changed to an octet field "response_flags" in Messaging, with more
    precise definition of the meanings of various flag values.

    2) The Messaging spec defines a IOP::TaggedComponent for including QoS
    policies in an IOR.

    3) The Messaging service defines a ServiceContext for carrying QoS
    policies in GIOP messages that carry ServiceContexts.

  • Reported: CORBA 2.0 — Tue, 13 Oct 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Close with No change required

  • Updated: Sat, 7 Mar 2015 04:35 GMT

IIOP 1.2 fragmentation presents an unrecoverable error situation

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

    Summary: IIOP 1.2 fragmentation presents an unrecoverable error situation
    1.2 IIOP attempted to provide fragment interleaving by defining a 1.2
    fragment header containing request id. This does not solve the
    possibility of receiving multiple first fragments over the same
    connection which do not contain request id"s. There is no way to
    associate subsequent fragments with these initial fragments since the
    initial request id is received after the 1.2 Fragment header specified
    request_id.

  • Reported: CORBA 2.0 — Mon, 24 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

New IDL types

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

    Summary: When the new IDL types were added (fixed, long double, etc), no new
    IIOP or GIOP version was introduced, and no new version of CDR was introduced.
    Instead, the marshaling rules for the new types were simply added to CDR,
    and the type code interface was extended to handle these.

    Unfortunately, this creates some rather serious problems for interoperability.

  • Reported: CORBA 2.0 — Tue, 21 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Narrow Interop

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

    Summary: Narrowing is used in CORBA to check if an object reference obtained by
    a client is of the desired type, ie. supports a specific IDL interface
    that the client wants to use.

    The client program has static information about the interface it wants
    to use from the IDL specification. However, this is not enough as it
    must also be possible to invoke remote objects that support an IDL
    interface derived from the interface the client knows of.

    There are at least 4 possiblities how the type checking can be resolved
    (+ combinations of them):

    Narrow makes a query to an interface repository.
    (ii) Narrow makes a call to the remote object.
    (iii) The object reference contains enough information, e.g. the whole
    interface type hierarchy that the remote object supports.
    (iv) There is no narrow; the type check is made when a request is
    received by the server-side ORB.

  • Reported: CORBA 2.0 — Mon, 13 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Contents of MultiComponent component an encapsulation?

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

    Summary: I can"t find any text in the CORBA 2.2 spec which says explicitly
    whether the "component_data" field of IOP::TaggedComponent is actually
    an encapsulation, or something else.

    Why don"t we define a typedef "Encapsulation" for "sequence<octet>",
    and use it in the IDL for those octet sequences which are really
    encapsulations?

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

    :TaggedComponent is actually

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Type any marshalling rules force slow implementation

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

    Summary: type any marshalling rules force slow implementation

    Proposal: require that type any are marshalled as encapsulations

  • Reported: CORBA 2.0 — Thu, 25 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Marshalling of union type codes

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

    Summary: On page 13-14, the spec says for marshaling of type codes:

    "Note that the tuples identifying struct, exception, and enum
    members must be in the order defined in the OMG IDL definition
    text."

    This is right and proper, otherwise I wouldn"t know in what order things are
    encoded or what their ordinal values are. However, the text does not
    mention unions, so the order in which a type code describes the union
    members is left to the implementation.

    Suggestion: Require union members to also appear in the order in which
    they are defined in the IDL.

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

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Typecode encoding is too long

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

    Summary: Proposal: allow for alternate, compact encoding of typecodes
    It is clear that typecodes are quite long when encoded into CDR and
    transmitted over the wire. This is particularly painful when the CORBA::Any
    type is used in interfaces. Besides, the use of any is becoming increasingly
    important in multiple CORBA specifications, and a global solution to this
    problem should be provided.

    My proposal is to allow for an alternate encoding of typecodes, for those
    specific cases where type identification can be achieved either by other
    application specific mechanisms (for example, Name-Value pairs) or where
    the Repository Id of the type is enough to reconstruct the full typecode
    information locally on the receiving side.

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

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Type code marshalling

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

    Summary: If a type code does not have a repository ID

    (e.g. dynamic type ) then the member names for
    structs and unions etc. should be required to be
    sent on the wire for GIOP marsalling of Typecodes.
    This may help the type code comparision issue to be resolved.

  • Reported: CORBA 2.0 — Sun, 14 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Typecode indirection issue

  • Key: CORBA21-99
  • Legacy Issue Number: 1503
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: We have come across the following issue with regard to typecode
    indirections. The specification states:

    the indirection is a numeric octet offset within the scope of some
    "top level" TypeCode and points to the TCKind value for the
    typecode.

    The question arrises then is it legal to point to the (possible)
    padding bytes preceeding the TCKind value or must the numberic value
    indicate the position of the actual TCKind value. If you assume the
    former then having rewound the required number of bytes you would word
    align before interogating the TCKind enum value.

  • Reported: CORBA 2.0 — Thu, 4 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:
  • Updated: Sat, 7 Mar 2015 04:35 GMT

No provision for numbering the fragments in fragmented IIOP messages

  • Key: CORBA21-98
  • Legacy Issue Number: 1302
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There seems to be no provision for numbering the fragments in fragmented
    IIOP messages. It is apparently assumed that the fragments will always
    be received in the order that they are generated, however in unreliable
    networks, such as mobile networks, this may not be a safe assumption.

  • Reported: CORBA 2.0 — Fri, 1 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

CDR encoding of TypeCodes

  • Key: CORBA21-97
  • Legacy Issue Number: 1292
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I just stumbled on the following paragraph in 13.3.4 describing the CDR
    encoding of TypeCodes:

    "The name parameters in tk_objref, tk_struct, tk_union, tk_enum,
    tk_alias, and tk_except TypeCodes and the member name parameters in
    tk_struct, tk_union, tk_enum and tk_except TypeCodes are not specified
    by (or significant in) GIOP. Agents should not make assumptions about
    type equivalence based on these name values; only the structural
    information (including RepositoryId values, if provided) is significant.
    If provided, the strings should be the simple, unscoped names supplied
    in the OMG IDL definition text. If omitted, they are encoded as empty
    strings."

    This would suggest that the name and member name parts of a typecode
    should never be considered significant when an ORB compares typecodes.

  • Reported: CORBA 2.0 — Mon, 30 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:
  • Updated: Sat, 7 Mar 2015 04:35 GMT

Correct CDR encoding of an empty string

  • Key: CORBA21-96
  • Legacy Issue Number: 1138
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What is the correct encoding for an empty string according to GIOP?

    In section 13.3.2, page 13-11 of CORBA 2.2, the following paragraph
    describes the encoding of strings:

    "A string is encoded as an unsigned long indicating the length of the string
    in octets, followed by the string value in single- or multi-byte form
    represented as a sequence of octets. Both the string length and contents
    include a terminating null."

    This does not clarify what is the correct encoding for empty strings,
    as there are two possibilities:
    a) length=0, no string follows
    b) length=1, "\0" (one-char with the terminating null)

  • Reported: CORBA 2.0 — Wed, 15 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Typecode equality

  • Key: CORBA21-95
  • Legacy Issue Number: 1136
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I just stumbled on the following paragraph in 13.3.4 describing the CDR
    encoding of TypeCodes:

    "The name parameters in tk_objref, tk_struct, tk_union, tk_enum,
    tk_alias, and tk_except TypeCodes and the member name parameters in
    tk_struct, tk_union, tk_enum and tk_except TypeCodes are not specified
    by (or significant in) GIOP. Agents should not make assumptions about
    type equivalence based on these name values; only the structural
    information (including RepositoryId values, if provided) is significant.
    If provided, the strings should be the simple, unscoped names supplied
    in the OMG IDL definition text. If omitted, they are encoded as empty
    strings."

    This would suggest that the name and member name parts of a typecode
    should never be considered significant when an ORB compares typecodes.

    Of course, this still leaves the issue of what to do about aliases up in
    the air.

  • Reported: CORBA 2.0 — Sun, 29 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:
  • Updated: Sat, 7 Mar 2015 04:35 GMT

Wchar and Char can both be multibyte

  • Key: CORBA21-94
  • Legacy Issue Number: 1111
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: With regard to the character encoding issue.

    This is not just a problem with Wchar, and Wstring, it can happen
    with char and string as well. Multibyte encodings are used for
    normal strings in the enhanced IDL as well as for
    Wchars.
    I think the problem is in the definition of char. For interop, the char type could be either:
    1) restricted to a syntactic thing which can only be used with single byte encodings, or
    2) we need to bite the bullet and make the encoding for char a sequence
    of bytes if a multibyte encoding is chosen.

  • Reported: CORBA 2.0 — Wed, 25 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Issue about CDR encoding for wide characters

  • Key: CORBA21-93
  • Legacy Issue Number: 1096
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. When encoding a wchar, always put 4 bytes into the CDR stream,
    > adding any zero pad bytes as necessary to make the value 4 bytes
    > long.
    2. When encoding a wstring, always encode the length as the total
    > number of bytes used by the encoded value, regardless of whether the
    > encoding is byte-oriented or not.

  • Reported: CORBA 2.0 — Tue, 24 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Query about GIOP and IIOP version numbers in 98-01-03

  • Key: CORBA21-92
  • Legacy Issue Number: 960
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"ve been reading through 98-01-03.pdf (Change pages from Interop 1.2
    RTF), and come across a problem concerning version numbers.

    On page 13-39, the following paragraph has been added:

    "The version number published in the Tag Internet IIOP Profile body
    signals the highest GIOP minor version number that the server supports
    at the time of publication of the IOR"

    As far as I can see, the only version information in the profile body is
    "iiop_version", which has the following note in its description:

    "Note - This value is not equivalent to the GIOP version number
    specified in GIOP message headers. Transport-specific elements of the
    IIOP specification may change independantly from the GIOP specification"

    Which is correct?

  • Reported: CORBA 2.0 — Thu, 5 Feb 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

GIOP Exception formatting description (12.4.2)

  • Key: CORBA21-91
  • Legacy Issue Number: 935
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA 2.1"s GIOP Exception formatting description (12.4.2)
    partitions the space of valid minor codes, with
    20 bits reserved for unique vendor IDs and only 12 bits
    (4096) for possible minor codes for each exception.
    This seems backwards (1 million vendors each with
    only 4 thousand minor codes!) and I would like
    to request a change to (at least) swap these
    numbers with the following textual change:

    The high order 10 bits of minor_code_value contain a 10-bit
    "vendor minor codeset ID" (VMCID); the low order 22 bits
    contain a minor code. A vendor (or group of vendors)
    wishing to define a specific set of system exception
    minor codes should obtain a unique VMCID from the OMG, and
    then define up to (22 bits of) 4194304 minor codes for each
    system exception. Any vendor....

  • Reported: CORBA 2.0 — Mon, 2 Feb 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 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

OMG IDL prefix pragma

  • Key: CORBA21-90
  • Legacy Issue Number: 566
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: All standard OMG IDL including the CORE and all services have implicit #pragma prefix "omg.org". Make sure this appears intext of ALL IDL that is specified, particular in CORBAServices

  • Reported: CORBA 2.0 — Thu, 22 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    closed issue

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

Description of constant expression semantics is unclear

  • Key: CORBA21-89
  • Legacy Issue Number: 564
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:

  • Reported: CORBA 2.0 — Thu, 1 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved, closed issue

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

Object terminal missing from IDL grammar

  • Key: CORBA21-88
  • Legacy Issue Number: 563
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Given the current IDL grammar, there is no way to parse any IDL containing the keyword "Object". It never appears in the grammar as a terminal symbol.

  • Reported: CORBA 2.0 — Thu, 1 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved, closed in "97

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

WRONG_TRANSACTION

  • Key: CORBA21-87
  • Legacy Issue Number: 557
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: OTS 1.1 spec (page 10-17 and 10-18) is not clear whether the WRONG_TRANSACTION exception is intended to be a system exception or a user exception

  • Reported: CORBA 2.0 — Mon, 28 Apr 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    issue resolved, see revised text

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

OTS 1.1 specification changes

  • Key: CORBA21-86
  • Legacy Issue Number: 556
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: OTS 1.1 spec doesn"t clearly say which module defines the TRANSACTION_REQUIRED, TRANSACTION_ROLLEDBACK, INVALID_TRANSACTION WRONG_TRANSACTION exceptions.

  • Reported: CORBA 2.0 — Mon, 28 Apr 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved close issue

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

Interface Repository

  • Key: CORBA21-85
  • Legacy Issue Number: 542
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the Interface Repository spec, StructDef,UnionDef, and ExceptionDef should be derived from Container,since types can be defined within structs,unions,and exceptions according to IDL gram

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

    resolved, close issue

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

Bug in C++ NVList mapping

  • Key: CORBA21-80
  • Legacy Issue Number: 501
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: NVList has an item () operation, which returns a NamedValue reference. The same special memory management rules should apply to item().

  • Reported: CORBA 2.0 — Thu, 20 Feb 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by portability submission

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

Page 13C-36: Editorials

  • Key: CORBA21-31
  • Legacy Issue Number: 711
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The typpedef enum at top of page should be called CORBA_CompletionStatus, not CORBA_ExceptionType. Second line 4th paragraph, text should refer to table 13-5, not 3-5

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    closed with issue 901-2 revision text

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

Issue with service context

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

    Summary: What should an ORB do when it gets a message with an unknown service context ID value?

  • Reported: CORBA 2.0 — Mon, 4 Aug 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with revision

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

CloseConnection messages

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

    Summary: 1.1 client may get 1.0 CloseConnection prior to first attemptto send Requests which it needs to recognize. Spec should clarify this.

  • Reported: CORBA 2.0 — Tue, 17 Jun 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with revised text

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

1.0 backward compat (2)

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

    Summary: Assuming a 1.1 server we must Reply using 1.o to Request sent from 1.o client. If we get request with junk revision (eg 2.2) we wil automatically send (1.1) MessageError, but connection is close

  • Reported: CORBA 2.0 — Tue, 17 Jun 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed, accomodated by clarification of version semantics

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

1.0 backward compat (1)

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

    Summary: If 1.1 client sends request to 1.0 server and tis causes 1.0 MessageError msf from serverthen 1.1 client must recognize MessageErrors from 1.o servers

  • Reported: CORBA 2.0 — Tue, 17 Jun 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    accomodated by clarification of version semantics

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

Fragment improvements (2)

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

    Summary: A response_expected setting should be added to a new "Fragment Header"(issue589) so that this setting may be delayed until the final fragment

  • Reported: CORBA 2.0 — Tue, 17 Jun 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    issue closed, no change required

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

Fragment improvements (1)

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

    Summary: Fragment messages should contain fragment header which contains a Request ID to associate the fragment with given request message. Frgamented request could otherwise block connection until sent.

  • Reported: CORBA 2.0 — Tue, 17 Jun 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    fixed, close issue

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

IDL Type Extensions: wstring CDR encoding issue

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

    Summary: Section 4.1.2 p. 20 : Implementation needs to know whether it is byte-oriented or not, since CDR representation is different in each case. ORB expected to maintain table mapping of all codesets?

  • Reported: CORBA 2.0 — Thu, 29 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    duplicate to closed issue 1096

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

IDL Type Extensions: wchar and wstring CDR encoding

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

    Summary: Section 4.1 GIOP CDR Transfer Syntax: The spec should cover cases where TCS-W is byte-oriented or non-byte oriented

  • Reported: CORBA 2.0 — Thu, 29 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    duplicate to closed issue 1096

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

Type extensions char code set negotiation

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

    Summary: This negotiation adds 16 bytes to both request and reply messages. It"s overburdening an already obese message header scheme.

  • Reported: CORBA 2.0 — Wed, 14 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed, no revision required

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

Type Extensions and code set negotiation

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

    Summary: page 26 of ptc/97-01-01: replace "Code set negotiation is not....." with"Code set negotiation is performed on a per-request basis."

  • Reported: CORBA 2.0 — Wed, 14 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with no revision required

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

C mapping for list_initial_services is incorrect

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

    Summary: Section 14.29: The C mapping for list_initial_services is incorrect and should return a pointer to a sequence (example in corresponding archive file)

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in CORBA 2.2 editing process

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

Native types with respect to typecodes, DII, DSI,Interface Reposit.

  • Key: CORBA22-80
  • Legacy Issue Number: 666
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The portability spec is silent on issue of native types with respect to typecodes, DII, DSI and Interface Repository. Issue should be addressed. (see archive for details)

  • Reported: CORBA 2.0 — Mon, 11 Aug 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Proposed resolution is to add representation of native type in the IR. Details below as proposed by

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

TypeCode equality

  • Key: CORBA22-79
  • Legacy Issue Number: 665
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: TypeCode equality is not very well-specified or portable.

  • Reported: CORBA 2.0 — Mon, 11 Aug 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate more complete specification as shown below:

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

Do identifiers and keywords clash if they differ in case?

  • Key: CORBA22-78
  • Legacy Issue Number: 641
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 3.2.3 and 3.2.4: It"s not said explicitly that an identifier may not differ from a keyword only in case since it differs only in case from a keyword

  • Reported: CORBA 2.0 — Wed, 30 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in 2.2+, Close

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

Section 3.7.2: take new IDL type extensions into account

  • Key: CORBA22-77
  • Legacy Issue Number: 624
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The section states that the <<and>> operands must be in the range 0 to 32. Should be changed to 0 to 64 to take new IDL type extensions into account

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Close, Fixed in 2.2

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

Section 7.8: editorial

  • Key: CORBA22-76
  • Legacy Issue Number: 623
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 7.8: ; is missing from definition of attribute policy_type

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Close, Fixed in 2.2

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

Syntax for basic types must be updated

  • Key: CORBA22-75
  • Legacy Issue Number: 611
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 3.8.1: The syntax for basic types must be updated to include the adopted IDL type extensions.

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in 2.2

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

create_exception() is declared outside any interface scope

  • Key: CORBA22-74
  • Legacy Issue Number: 610
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 6.8: The create_exception() methos is declared outside any interface scope. It seems logical to move it to Container Interface along with other create_XXX() methods

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in 2.2

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

TCKind enum should be updated

  • Key: CORBA22-73
  • Legacy Issue Number: 609
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 6.8: TCKind enum should be updated to include adopted IDL type extensions as follows: tk_longlong, tk_longdouble, tk_wstring, tk_wchar. Update DefinitionKind and PrimitiveKind enum

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Close, fixed in 2.2

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

No defined value for OBJECT_NIL

  • Key: CORBA22-72
  • Legacy Issue Number: 607
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 7.2.3: reference is made to OBJECT_NIL but there is no defined value for this. A value must be explicitly defined and typed

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved, close issue

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

Section 7.2: get_implementation function

  • Key: CORBA22-71
  • Legacy Issue Number: 604
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Why does Object have a get_implementation function instead of a readonly implementation attribute? (likewise for get_interface)

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.2
  • Disposition Summary:

    closed issue, no change

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

sec 17.7.1: IDL for interface request doesn"t match C++ mapping

  • Key: CORBA22-70
  • Legacy Issue Number: 598
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The IDL for interface Request does not match the C++ mapping. There are a series od add_arg methods in the mapping that should be added to the IDL.

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Language mappings are allowed to have custom mappings for pseudo-interfaces.

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

Sequence parameter specified is ignored

  • Key: CORBA22-69
  • Legacy Issue Number: 597
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Why does mapping ignore the sequence parameter specified in the IDL for the initialization service and split this single parameter into 2 separate ones in the mapping?

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    That is an artificat of C/C++ historical usage and is not a core issue. In general language mapping

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

request() should be added to IDL (section 17.13.2)

  • Key: CORBA22-68
  • Legacy Issue Number: 596
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Object C++ mapping has an _request() method that is not in the IDL. This method should be added to the IDL

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.2
  • Disposition Summary:

    The Object::_request operation is an artifact of the C++ mapping and not generally applicable to ot

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

Section 16.7: only C++ mapping defines string_free and string_dup

  • Key: CORBA22-67
  • Legacy Issue Number: 595
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Only the C++ mapping defines string_free and string_dup. Why are these methods not present in other language mappings? If they are generally applicable they should be added to the IDL

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.2
  • Disposition Summary:

    They are C++ language specific helper functions, that is why they are in the C++ mapping section. T

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

limited-length strings

  • Key: CORBA22-66
  • Legacy Issue Number: 588
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Limited-length strings are missing from enumeration in section 1.2.4. Were they intended to go in "Basic Types" or the "Constructed types" section?

  • Reported: CORBA 2.0 — Thu, 29 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate change in 2.3a and close issue

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

Question about IDL grammar

  • Key: CORBA22-65
  • Legacy Issue Number: 571
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is it a mistake, in IDL grammar as given in CORBA 2.0, revised July 1996, that <octet_type> is not one of <const_type>s?

  • Reported: CORBA 2.0 — Tue, 6 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    subsumed by issue 725

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

"service"~~operation or interface?

  • Key: CORBA22-64
  • Legacy Issue Number: 570
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Does a service consist of single operation, or a collection of related operations, exceptions, types, and constants?

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Cleaning up the use of the word service throughout the document does not seem to be an achievable g

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

What exactly is a request

  • Key: CORBA22-63
  • Legacy Issue Number: 569
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: One may expect it to be a reply or response.Reading chapters 1,4,5 makes clear that it is the entirety of an invocation of an operation, including request and response. Change possible soon?

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Clarify the sense in which the term Request is used in section 1.2.2

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

inherit vs. include

  • Key: CORBA22-62
  • Legacy Issue Number: 568
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Ther is sense in which an interface "includes" operations it inherits from its base interface.Does it also "include" types, constants, and exceptions?

  • Reported: CORBA 2.0 — Wed, 21 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue with annotation fixed in Rev 2.2+

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

Scope and use of prefix pragma in IDL-style repository IDs

  • Key: CORBA22-61
  • Legacy Issue Number: 567
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is confusion about effect of "prefix" pragma evident in the Interface Repository chapter. Whole notion of prefix should be explained more fully in section 6.6.1

  • Reported: CORBA 2.0 — Mon, 12 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Clarifying language has been incorporated in section 10.6.5.2 (old section 8.6.5.2) in Rev 2.3 adeq

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

Terminology consistency

  • Key: CORBA22-60
  • Legacy Issue Number: 565
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What terminology should the core settle on? Interface inheritance with use of subtype/supertype? What about immediate and transitive versions of relationships?

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved closed issue

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

Enums and enumerators

  • Key: CORBA22-59
  • Legacy Issue Number: 545
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 3.13 says enumerators don"t create a nested scope.Implication: 2 differnt enum types within same module can"t have same enumerator names. Flag following example as an error

  • Reported: CORBA 2.0 — Thu, 10 Apr 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    issue closed, no change

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

Internationalization

  • Key: CORBA22-58
  • Legacy Issue Number: 499
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: New Idl types have been introduced to cover non-ISO code sets.Sec 5.4.1 indicates that where "generic strings" are required in a spec "wstring"should be used. Place holder in naming spec: Istring

  • Reported: CORBA 2.0 — Wed, 12 Feb 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    not interpretable, closed

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

IIOP server-initiated connection closure problem

  • Key: CPP11-124
  • Legacy Issue Number: 543
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On several operating systems the client"s writing of Request message after CloseConnection message can cause the unread CloseConnection message to be discarded from buffer

  • Reported: CORBA 2.0 — Wed, 16 Apr 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved, see above

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