Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — Closed Issues

  • Acronym: CORBA
  • Issues Count: 134
  • 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
CORBA3-134 IDL keyword clash in CosNotification.idl CORBA 2.6 CORBA 3.0 Resolved closed
CORBA3-133 insufficient examples of component attributes CORBA 3.0.2 CORBA 3.0.3 Duplicate or Merged closed
CORBA3-132 Derived component supported interface restriction CORBA 3.0 CORBA 3.0.1 Resolved closed
CORBA3-131 Error in Chapter 21 of CORBA 3.0 CORBA 3.0.2 CORBA 3.0.3 Resolved closed
CORBA3-130 Wrong minor code listed in POAManager::deactivate CORBA 3.0 CORBA 3.0.1 Resolved closed
CORBA3-129 DATA_CONVERSION minor code 2 not listed in Table 4-3 CORBA 2.6.1 CORBA 3.0 Resolved closed
CORBA3-124 Issues related to CCM's XML descriptors: chapter 69.4.5.4 CCM 3.0 CORBA 3.0.2 Resolved closed
CORBA3-128 Creating IORs CORBA 2.4.2 CORBA 3.0.3 Resolved closed
CORBA3-127 There is no way to modify a POA's ORT and append to it CORBA 2.4.2 CORBA 3.0.3 Resolved closed
CORBA3-126 Interoperability of ObjectReferenceTemplate and Factory. CORBA 2.4.2 CORBA 3.0.3 Resolved closed
CORBA3-125 Object Adapter name problem in ORT CORBA 2.4.2 CORBA 3.0.3 Resolved closed
CORBA3-116 Productions 140, 141, 142 and 143 must be removed CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-115 paragraph 60.2.1 : There is two mistakes in keywords CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-123 Update Table 5-13 in the EJB Chapter of formal/02-06-65 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-122 Editorial issues in formal/02-06-65 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-120 Remove section 4.4.1.4 in formal/02-06-65 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-119 create operation of AssemblyFactory interface CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-114 CIDL Grammar problems: Productions must be renumbered : 134 -> 1, ... CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-118 69.8.2 Property File XML Elements CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-117 Typo (??) in chapter 61 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-121 Corrections in XML DTDs for packaging CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-106 components-ftf: connectevent element CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-105 components-ftf: registercomponent element CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-104 components-ftf: repository id in software package descriptor CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-103 IDL3 keyword "eventtype" conflicts with struct "CosNotification::EventType CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-113 Issues related to CCM's XML descriptors: chapter 695.4 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-112 Issues related to CCM's XML descriptors: chapter 69.7.2.38 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-107 Issue regarding language mapping for keyless homes CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-102 Generic operations for subscribing/unsubscribing at publishing ports CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-108 simple type element of the property file issue CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-111 Issues related to CCM's XML descriptors: chapter 69.7.2.25 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-110 Issues related to CCM's XML descriptors: chapter 69.4.5.16 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-109 Issues related to CCM's XML descriptors: chapter 69.4.4 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-95 add a ClientInterceptor then create_POA() in the post_init() method? CORBA 3.0.1 CORBA 3.0.2 Resolved closed
CORBA3-94 CORBA::WrongTransaction and Interceptors CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-93 How do Portable Interceptors interact with Messaging callbacks CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-92 What ORBInitInfo operations are legal during pre_init() and post_init()? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-91 ORBInitInfo::arguments() underspecified CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-90 Exception handling in Interceptor initialization CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-89 Derived component supported interface restriction (formal/2002-06-01) CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-88 Local types allowed as valuetype state? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-87 Why does PollableSet::number_left() return unsigned short? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-86 Pollable in more than one PollableSet? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-85 Oneway operations should not generate sendc_ and sendp_ variants CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-84 DII sendc reply delivery underspecified CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-83 Bad example code in 22.11.4.3 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-82 Messaging Poller generation is broken for interfaces with multiple inherite CORBA 1.1 CORBA 3.0.2 Resolved closed
CORBA3-81 name disambiguation for AMI interface & poller names is confusing CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-80 potential name clash with Messaging type-specific poller timeout argument CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-101 What ORBInitInfo operations are legal during pre_init() and post_init()? CORBA 3.0 CORBA 3.0.2 Duplicate or Merged closed
CORBA3-100 AMI vs abstract & local interfaces CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-99 Sending codeset context more than once? CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-98 Getting reply svc ctxts from PersistentRequests CPP 1.0 CORBA 3.0.2 Resolved closed
CORBA3-97 Type code creation CORBA 3.0.1 CORBA 3.0.2 Resolved closed
CORBA3-96 Unfortunate CDR Encapsulation of ASN.1 Encodings CORBA 3.0.1 CORBA 3.0.2 Resolved closed
CORBA3-79 Messaging type-specific poller valuetypes should be abstract CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-78 Errors in definition of Messaging poller types CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-77 Messaging: bad example code for type specific poller CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-76 SyncScope for oneway invocations CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-75 Messaging time based policy enforcement? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-74 determining TimeT or UtcT value CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-73 Is a router allowed to pick any value in the range for a priority? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-72 Who is responsible for generating the TIMEOUT exception CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-71 Object::validate_connection() CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-70 Sloppy text in CORBA 3.0, 4.3.8.1 get_policy CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-69 Object::get_client_policy problem CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-68 Inconsistent definition of semantics of RebindPolicy? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-63 pragma prefix syntax CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-62 Avoiding Interceptors for colocated method requests CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-61 Codeset negotiation and the CODESET_INCOMPATIBLE exception CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-60 Replace deprecated anonymous type declarations? CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-59 reference_to_servant CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-67 BAD_INV_ORDER minor code 5 and 10 mean the same thing? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-66 Serious backward compatibility issue in the PI CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-65 OpaqueValue/add_arg never mapped to languages CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-64 Minor codes in specified NO_IMPLEMENT exceptions incomplete/inconsistent CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-58 Valuetypes supporting forward declared interfaces CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-57 Inconsitent exception handling with find_POA & unknown_adapter CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-56 IOR processing performance CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-47 Wide string in reply before codeset was negotiated CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-46 conflict between CORBA specification and C++ mapping (_this method CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-51 Codeset negotiation requires clarification CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-50 The whole negotiation thing should be removed, Unicode should be mandated CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-53 discussion on the create_union_tc operation could use some clarifications CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-52 IDL inheritance issue CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-49 interaction of #pragma and typeid, typeprefix CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-48 IPv6 in corbaloc URLs CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-55 GIOP version in replies CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-54 definition of the TypeCode interface (4.11.1) CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-43 Issue with chunking CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-42 TypeCode indirections CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-41 Chapters 13.10.1.9, and 13.10.1.12 -- issue CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-38 Alignment for empty sequence? CORBA 2.5 CORBA 3.0.2 Resolved closed
CORBA3-37 CORBA 2.5 and Portable Interceptors mismerged CORBA 2.5 CORBA 3.0.2 Resolved closed
CORBA3-36 Detecting Recursion in Other Interceptors CORBA 2.5 CORBA 3.0.2 Resolved closed
CORBA3-27 X/Open Codeset registry is obsolete needs to be replaced CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-26 Clarify that each interception point executes in a distinct logical thread CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA3-45 11.3.2.1 Processing States (end of second paragraph and third paragraph CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-44 Potential problem using BiDir GIOP and codeset conversion service context CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-40 GIOP 1.2 encoding of wstring CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-39 ORBs using BOMs for UTF-16 (closely related to issue 4008) CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-29 Problem with CSIv2 and GIOP LocateRequest CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-28 21.8.1 register_initial_reference CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-33 rep_id() operation on Object? CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-32 Repository ID in nil references CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-31 Note on page 15-43, OBJECT_FORWARD_PERM CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-30 Interpretation of defined ServiceConfigurationSyntax constants is incomplet CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-35 CORBA components requires new GIOP version? CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-34 TypeCodes for custom marshaled valuetypes CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-25 Stateful boolean causes all CSI mechanisms to operate the same way. CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA3-11 Detail lacking in when request interceptors are called CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-10 How correlate requests and replies when using pollable sets? CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-18 no way to register value factory from ORB initializer CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-17 ORB accessor on POA? CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-16 RoutingPolicy issue CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-24 ORB::shutdown vs. ORB::destroy CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA3-23 Encodings of Sequences of Certificates are not standard. CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA3-20 Portable interceptors and invocation timeouts CORBA 2.4 CORBA 3.0.2 Resolved closed
CORBA3-19 Missing minor codes in Messaging Chapter CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-22 wchar endianness CORBA 2.4 CORBA 3.0.2 Resolved closed
CORBA3-21 No portable way to turn IOR components into object-reference policies CORBA 2.4 CORBA 3.0.2 Resolved closed
CORBA3-15 Portable Interceptors / register_initial_reference() CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-14 Policy Management in Portable Interceptors CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-9 ORBInitInfo needs the ORB CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-8 PI needs the ORB to be available in IDL CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-7 Question about routing policies CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-6 Portable Interceptors: object_to_string, string_to_object CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-5 Implementing proper handling of CloseConnection CORBA 2.3.1 CORBA 3.0.2 Resolved closed
CORBA3-13 Overriding POA policies CPP 1.1 CORBA 3.0.3 Resolved closed
CORBA3-12 Portable Interceptors: 9.2.3 text describing `Arguments' CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-2 No way to detect that ORB has outstanding deferred synchronous requests CORBA 2.2 CORBA 3.0.2 Resolved closed
CORBA3-1 constant decls broken CORBA 2.2 CORBA 3.0.2 Resolved closed
CORBA3-4 scheme name for IORs CORBA 2.3 CORBA 3.0.2 Resolved closed
CORBA3-3 issue with ForwardRequest exception in POA CORBA 2.2 CORBA 3.0.2 Resolved closed

Issues Descriptions

IDL keyword clash in CosNotification.idl

  • Key: CORBA3-134
  • Legacy Issue Number: 4901
  • Status: closed  
  • Source: Memorial University of Newfoundland ( Jeffrey Parsons)
  • Summary:

    CosNotification.idl contains a struct named 'EventType', which
    clashes with the new CCM-related keyword 'eventtype'.

  • Reported: CORBA 2.6 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0
  • Disposition Summary:

    purely editorial issue

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

insufficient examples of component attributes

  • Key: CORBA3-133
  • Legacy Issue Number: 5906
  • Status: closed  
  • Source: Raytheon ( Craig Rodrigues)
  • Summary:

    In OMG document formal/02-06-65, in section "1.3.3 Component Body", there
    is this text:

    "Declarations for facets, receptacles, event sources, event sinks,
    and attributes all map onto operations on the component's equivalent
    interface. These declarations and their meanings are described in
    detail below."

    In the following sections, I see facets, receptacles, event sources,
    and event sinks described, but I see no mention of attributes.
    It would be usefult to have an example of attributes in an appropriate
    place, as outlined by section 1.3.3.

    In section "1.10 Configuration with Attributes", I see that configurators
    are described, but I see no example of using attributes directly
    to configure a component.

    It would be very useful to include a small example to illustrate
    how to configure a component directly by using attributes.

    Diego Sevilla Ruiz <dsevilla@ditec.um.es> gave this
    C++ example on the CCM mailing list ( http://moriarty.dif.um.es/mailman/listinfo/ccm ):

    ======================================================

    component Whatever

    { attribute long cacheMaxKb; }

    ;

    home WhateverHome manages Whatever
    {
    };

    // C++
    WhateverHome_var weh = // obtain ref
    Whatever_var we = weh->create();

    we->cacheMaxKb(200);

    we->configuration_complete();

    ======================================================

    I don't suggest that this example be used verbatim,
    but a similar example would be useful to have in the
    CCM spec.

  • Reported: CORBA 3.0.2 — Thu, 10 Apr 2003 04:00 GMT
  • Disposition: Duplicate or Merged — CORBA 3.0.3
  • Disposition Summary:

    duplicate of issue 5898

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

Derived component supported interface restriction

  • Key: CORBA3-132
  • Legacy Issue Number: 5683
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Both the CORBA spec (formal/02-06-01 page 3-61) and the CCM spec (formal/02-06-65 page 1-51) state that "A derived component type may not directly support an interface." Moreover the sentence you depicted is a contradiction with the formal/02-06-65 section 1.3.2.4 page 1-7.
    Resolution:

    In formal/02-06-65 page 1-51 and formal/02-06-01 page 3-61 replace the sentence

    "A derived component type may not directly support an interface."

    with

    "If a derived component type directly supports one or more IDL interfaces, the component interface is derived from both the interface of its base component type and the supported interfaces."

  • Reported: CORBA 3.0 — Thu, 10 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.1
  • Disposition Summary:

    No Data Available

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

Error in Chapter 21 of CORBA 3.0

  • Key: CORBA3-131
  • Legacy Issue Number: 6912
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    there is a serious error in Chapter 21 in both the CORBA 3.0 specification and the 3.1 drafts. The ORT final adopted specification (ptc/01-08-31 mentioned above) does NOT contain the methods ObjectReferenceFactory::equals an ObjectReferenceFactory::make_profiles. These methods were first added in the ORT FTF in issue 4476, then removed after further discussion in issue 4478. The final adopted specification reflects this, but somehow the incorrect text was incorporated into the official CORBA 3.0 specification. Unfortunately I only noticed this recently

  • Reported: CORBA 3.0.2 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    issue closed editorially

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

Wrong minor code listed in POAManager::deactivate

  • Key: CORBA3-130
  • Legacy Issue Number: 5449
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 11.3.2.5 states that BAD_INV_ORDER with minor code 6 is raised
    if POAManager::deactivate is called from an invocation on a POA that
    would be affected by the deactivate call.

    This minor code ought to be 3 instead

  • Reported: CORBA 3.0 — Mon, 1 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.1
  • Disposition Summary:

    editorially fixed in 3.0

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

DATA_CONVERSION minor code 2 not listed in Table 4-3

  • Key: CORBA3-129
  • Legacy Issue Number: 5322
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    It is used by RealTime CORBA as documented in 24.17.2

  • Reported: CORBA 2.6.1 — Thu, 23 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0
  • Disposition Summary:

    non issue...editorial, issue withdrawn

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

Issues related to CCM's XML descriptors: chapter 69.4.5.4

  • Key: CORBA3-124
  • Legacy Issue Number: 5493
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    chapter 69.4.5.4
    "The information obtained by (...) it allows component assembly
    tools to decide WHAT ports
    on a component are capable (...)"
    it seems that the word "which" would be better than "what" in
    this sentence

  • Reported: CCM 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Replace "what" by "which".

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

Creating IORs

  • Key: CORBA3-128
  • Legacy Issue Number: 4478
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    > // ulgy conversion to objectref: we should think about
    > // creating utilities for IOR<->objref conversion

    I meant to raise that second issue (the ugly IOR to ObjRef conversion).
    It is too painful and I think we should address it. I can think of a few
    possible solutions.

    1. have make object just return profiles, so the ORB can do the
    conversion internally.
    2. Add a method on the ORT to provide this functionality
    3. Add a separate CODEC interface to manufacture IORs from Profiles
    (IORFactory, rir etc)

  • Reported: CORBA 2.4.2 — Tue, 14 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    Undo the resolution of issue 4476 and close 4478 no change

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

There is no way to modify a POA's ORT and append to it

  • Key: CORBA3-127
  • Legacy Issue Number: 4476
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    If I wish to register an ORF (ObjectReferenceFactory) as the current
    factory, there is no way for it to append to the current template. In
    other words, an updated factory can only replace the original but not
    say add another profile to the one the given POA would generate w/ the
    adapter template.

    As an inverse, there is no way for a POA to require or even request an
    ORF to include profiles that it deems fit.

    Proposal:

    Add a parameter to make_object

    Object make_object( in string repositoryId, in ObjectId id,
    ObjectReferenceTemplate template);

    Add the following methods to ObjectReferenceTemplate

    abstract valuetype ObjectReferenceTemplate : ObjectReferenceFactory

    { readonly attribute ServerId server_id ; readonly attribute ORBId orb_id ; readonly attribute AdapterName adapter_name; ProfileSeq getProfiles(in string repositoryId, in ObjectId id); ComponentSeq getComponents(in IOP::ProfileId profile_id); }

    ;

    where ProfileSeq is defined as

    module IOP

    { typedef sequence <TaggedProfile> ProfileSeq; typedef sequence <TaggedComponent> ComponentSeq; }

    Add the following sections:

    21.5.3.8 getProfiles

    This returns the set of profiles that the POA would have generated using
    its default template. This can optionally be included in the generated
    IOR.
    [ED: This is independent of make_object, because make_object returns an
    object reference from which profiles would have to be extracted for
    inclusion]

    21.5.3.9 getComponents
    This returns set of components that would have been include in the
    profile with the id profile_id and allows the factory to choose to
    include those in the profiles that it generates.

  • Reported: CORBA 2.4.2 — Sun, 12 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    see above

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

Interoperability of ObjectReferenceTemplate and Factory.

  • Key: CORBA3-126
  • Legacy Issue Number: 4445
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    Nothing in the specs (I think the submission does say this somewhere)
    say that the valuetypes defined in this spec and implemented by the ORB
    vendor are not expected to be transmitted across different ORB
    implementations.

    Proposal:

    Add paragraph to 51.5.3.1:

    Concrete definitions and implementations of ObjectReferenceTemplate and
    ObjectReferenceFactory are ORB implementation specific and are not
    defined as they are not expected to be exchanged between ORB
    implementations.

  • Reported: CORBA 2.4.2 — Thu, 2 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    Add a clarification to the specification

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

Object Adapter name problem in ORT

  • Key: CORBA3-125
  • Legacy Issue Number: 4440
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    The adopted specification for the Object Reference Template is
    ptc/01-04-03. This specification introduces adapter names for
    object adapters. Adapter names are needed in the definition of the
    ObjectReferenceTemplate abstract valuetype. An AdapterName is
    simply a sequence of strings that is used to identify an
    instance of an object adapter.

    In the case of the POA, the spec defines the AdapterName as follows
    in section 21.5.2.1:

    In the case of the POA, the adapter name shall be the sequence
    of names starting with the root POA that is required to reach
    the POA using the find_POA call. The name of the root POA is
    the empty sequence.

    Also, in section 21.3.14.6:

    The adapter_name attribute defines a name for the object adapter that
    services requestws for the invoked object. In the case of the POA,
    the adapter_name is the sequence of names from the root PAO to the POA
    that services the request. The root POA is not named in this sequence.

    The problem here is that the POA occupies the entire name space of
    possible adapter names, so an ORB that supports other proprietary
    object adapters cannot unambiguously identify instances of other
    object adapter through ServerRequestInfo.adapter_name.

  • Reported: CORBA 2.4.2 — Mon, 30 Jul 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    Update the specification so that the Object Adapter ID of the root POA is

    { "RootPOA" }
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Productions 140, 141, 142 and 143 must be removed

  • Key: CORBA3-116
  • Legacy Issue Number: 5500
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    Productions 140, 141, 142 and 143 must be removed. Catalog has been
    removed
    from the PSS specification.
    Production 145 : <home_executor_body> refers to <stored_on_dcl> which is
    defined in production 151
    as <home_persistence_dcl>. Pick one or the other and changes references
    as required ...
    Productions 149 and 150 are not valid any more. Remove them and add a
    new production :
    <abstract_storage_home_name> ::= <identifier>
    identifier must be the name of an abstract storagehome previously
    declared

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

paragraph 60.2.1 : There is two mistakes in keywords

  • Key: CORBA3-115
  • Legacy Issue Number: 5499
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:
    • Capital letters are not appropriated. Correct "storageHome" with
      "storagehome".
    • The keyword "catalog" must be removed as it was removed from PSDL.
  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Update Table 5-13 in the EJB Chapter of formal/02-06-65

  • Key: CORBA3-123
  • Legacy Issue Number: 5588
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In ptc/01-11-03, page 64-410, there is the following note

    Issue This table will be completed after the Interface Repository
    chapter is ready.

    Then Table 5-13 in formal/02-06-65 would be completed.

  • Reported: CORBA 3.0 — Thu, 22 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    No Data Available

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

Editorial issues in formal/02-06-65

  • Key: CORBA3-122
  • Legacy Issue Number: 5585
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    The Adopted CORBA Components Specification (formal/02-06-65)
    always contains some texts removed by the Components December
    2000 RTF (ptc/01-11-02 and ptc/01-11-03). See at

    formal/02-06-65 ptc/01-11-03

    page 1-24 and 25 page 61-241
    page 1-26 page 61-243
    page 1-28 page 61-245
    page 4-37 page 62-363
    page 6-67 page 69-542
    page 6-72 page 69-548
    page 8-23 page 70-601

    Remove these old texts once again.

    Proposed revised text:

    Following must be applied on formal/02-06-65.

    At pages 1-24 and 1-25, remove

    module <module_name> {
    module <component_name>EventConsumers

    { interface <event_type>Consumer; };
    interface <component_name> : Components::CCMObject { Components::Cookie subscribe_ <source_name> ( in <component_name>EventConsumers:: <event_type>Consumer consumer) raises (Components::ExceededConnectionLimit); <component_name>EventConsumers:: <event_type>Consumer unsubscribe_<source_name> (in Components::Cookie ck) raises (Components::InvalidConnection); };
    module <component_name>EventConsumers {
    interface <event_type>Consumer :
    Components::EventConsumerBase { void push (in <event_type> evt); };
    };
    };


    At page 1-26, remove


    module <module_name> {
    module <component_name>EventConsumers { interface <event_type>Consumer; }

    ;
    interface <component_name> : Components::CCMObject

    { void connect_ <source_name> ( in <component_name>EventConsumers:: <event_type>Consumer consumer ) raises (Components::AlreadyConnected); <component_name>EventConsumers:: <event_type>Consumer disconnect_ <source_name>() raises (Components::NoConnection); }

    ;
    module <component_name>EventConsumers {
    interface <event_type> Consumer :
    Components::EventConsumerBase

    { void push (in <event_type> evt); };
    };
    };


    At page 1-28, remove


    module <module_name> {
    module <component_name>EventConsumers { interface <event_type>Consumer; };
    interface <component_name> : Components::CCMObject { <component_name>EventConsumers:: <event_type>Consumer get_consumer _<sink_name>(); };
    module <component_name>EventConsumers {
    interface <event_type>Consumer :
    Components::EventConsumerBase { void push (in <event_type> evt); }

    ;
    };
    };

    At page 4-37, remove in Session2Context interface
    the two occurrences of PortableServer::ObjectId.

    At page 6-67, remove

    Note Of the interfaces described below, only
    ComponentInstallation,
    AssemblyFactory, and Assembly are required by this specification;
    the other
    interfaces are included for illustrative purposes and to support an
    end-to-end scenario.

    At page 6-72, remove

    exception InvalidLocation { };

    At page 8-23, remove Figure 8-20.

  • Reported: CORBA 3.0 — Thu, 22 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Remove section 4.4.1.4 in formal/02-06-65

  • Key: CORBA3-120
  • Legacy Issue Number: 5583
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    Proposed resolution:

    The Adopted CORBA Components Specification (formal/02-06-65)
    always contains the section 4.4.1.4 at page 4-36.

    However, this section was removed in the ptc/01-11-03 document
    by the resolution of the issue 3937 of the Final Report of
    Components December 2000 FTF (ptc/01-11-02).

    Proposed revised text:

    In formal/02-06-65 page 4-36, remove the section 4.4.1.4.

  • Reported: CORBA 3.0 — Tue, 20 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

create operation of AssemblyFactory interface

  • Key: CORBA3-119
  • Legacy Issue Number: 5577
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Dr. Tom Ritter)
  • Summary:

    The name of the create operation in the AssemblyFactory Interface shall
    be renamed to a more specific identifier. Create is often used in other
    interfaces and this may lead to problems e.g. in inheritance relationships.

    suggested change:

    create -> create_assembly

  • Reported: CORBA 3.0 — Tue, 13 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see below

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

CIDL Grammar problems: Productions must be renumbered : 134 -> 1, ...

  • Key: CORBA3-114
  • Legacy Issue Number: 5498
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    Productions must be renumbered : 134 -> 1, ...

    In all productions, replace ...storage_home... by ...storagehome... and
    ...storage_type...
    by storagetype...

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

69.8.2 Property File XML Elements

  • Key: CORBA3-118
  • Legacy Issue Number: 5507
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    1. 69.8.2.1 The properties Root Element, page 69-537
    Properties Element Cardinality. Suggested change is to replace "*" with "
    +".
    Why does it make sense to have an empty properties file, since the
    properties are
    optional references in the Software Package DTD, CORBA Component DTD, and
    Component Assembly DTD?

    Current Format

    <!ELEMENT properties
    ( description?
    , ( simple

    sequence
    struct
    valuetype
    )*
    ) >

    Suggested New Format

    <!ELEMENT properties
    ( description?
    , ( simple

    sequence
    struct
    valuetype
    )+
    ) >
  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    No Data Available

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

Typo (??) in chapter 61

  • Key: CORBA3-117
  • Legacy Issue Number: 5506
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In the CCM specification document ptc/2001-11-03 page 61-227
    the 'session' word should be removed from the OMG IDL 3.0
    example, i.e.:

    component baz session {

    should be replaced by:

    component baz {

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Correct the typo by removing the 'session' word

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

Corrections in XML DTDs for packaging

  • Key: CORBA3-121
  • Legacy Issue Number: 5584
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In the Adopted CORBA Components Specification (formal/02-06-65),
    page 6-4, section 6.3.2.1, the version attribute of the softpkg
    element is tagged as #OPTIONAL and is tagged as #IMPLIED at page 7-5.
    As #OPTIONAL is not valid in XML, then replace it by #IMPLIED.

    In chapter 7, the softpkg XML DTD does not contain the
    ins and objref elements which they are used by the repository
    element described at page 7-4. Add them.

    Proposed revised text:

    In formal/02-06-65:

    At page 6-4, section 6.3.2.1, replace #OPTIONAL
    by #IMPLIED for the version attribute of the softpkg element.

    At page 7-3, add before the humanlanguage element

    <!ELEMENT ins EMPTY >
    <!ATTLIST ins
    name CDATA #REQUIRED >

    At page 7-4, add before the os element

    <!ELEMENT objref EMPTY >
    <!ATTLIST objref
    string CDATA #REQUIRED >

  • Reported: CORBA 3.0 — Wed, 21 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

components-ftf: connectevent element

  • Key: CORBA3-106
  • Legacy Issue Number: 5093
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    On page 69-521 (ptc/01-11-03), the connectevent
    element of an Assembly Descriptor is defined as

    <!ELEMENT connectevent (consumesport,
    (emitsport |
    publishesport))>

    This does not allow for emits and publishes
    ports to be connected to existing consumer
    interfaces that are registered in the naming
    or trading service. I suggest to change that
    element in the spirit of connectinterface to

    <!ELEMENT connectevent (emitsport |
    publishesport) ,
    (consumesport |
    existinginterface)>

  • Reported: CORBA 2.6 — Tue, 26 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

components-ftf: registercomponent element

  • Key: CORBA3-105
  • Legacy Issue Number: 5092
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    On page 69-532 (ptc/01-11-03), the
    registercomponent element of an Assembly
    Descriptor is defined to optionally
    contain an emitsidentifier and publishes-
    identifier element, in order to register
    an event source in the Naming or Trading
    Service. There is also a note saying, "In
    the case of events, what gets registered?"

    I suggest to replace the emitsidentifier
    and publishesidentifier elements with the
    consumesidentifier element, and to change
    the first two paragraphs to read:

    "The registercomponent element is to specify
    that a component, a provided interface, or
    an event consumer interface should be regis-
    tered with a naming service or trader.

    If a consumesidentifier or publishesidentifier
    is specified, then that element is registered.
    If none of the above are specified, then it is
    implied that the component itself is to be
    registered."

  • Reported: CORBA 2.6 — Tue, 26 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

components-ftf: repository id in software package descriptor

  • Key: CORBA3-104
  • Legacy Issue Number: 5091
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The id attribute of the idl element in a
    Software Package Descriptor currently
    contains the Repository Id of the component.

    I suggest to change this to the Repository
    Id of the home, as the home implies the
    component, but not vice versa. This makes
    it easier for the deployment application to
    find out about the home interface, e.g. for
    the purpose of configuring properties.

  • Reported: CORBA 2.6 — Tue, 26 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The Repository Id of the home should be added as an attribute of the idl element

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

IDL3 keyword "eventtype" conflicts with struct "CosNotification::EventType

  • Key: CORBA3-103
  • Legacy Issue Number: 4986
  • Status: closed  
  • Source: Tech-X ( Nanbor Wang)
  • Summary:

    The "eventtype" keyword defined in Section 3.2.4 of the "CORBA 3.0 New
    Components Chapters" (ptc/2001-11-03) will make the Notification
    Service IDL un-compilable because Notification Service defines a
    struct called "EventType" in Section 3.1 of formal/00-06-20.

    I guess one of the specs will have to change.

  • Reported: CORBA 2.6 — Mon, 18 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Issues related to CCM's XML descriptors: chapter 695.4

  • Key: CORBA3-113
  • Legacy Issue Number: 5497
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    chapter 695.4
    the elements aren't in the alphabetical order
    proxyhome must be placed before publishesidentifier

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Issues related to CCM's XML descriptors: chapter 69.7.2.38

  • Key: CORBA3-112
  • Legacy Issue Number: 5496
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    chapter 69.7.2.38
    the processcollocation element given in this chapter lacks a
    DESTINATION child element
    right one:
    <!ELEMENT processcollocation
    (usagename?
    , impltype?
    , (homeplacement

    extension
    )+
    ,destination?
    )>
    <!ATTLIST processcollocation
    id ID #IMPLIED
    cardinality CDATA "1">
  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Issue regarding language mapping for keyless homes

  • Key: CORBA3-107
  • Legacy Issue Number: 5340
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In 01-11-03.pdf page 61-255

    Given a base home definition with a primary key (H, T, K), and a derived home
    definition with no primary key (H', T'), such that H' is derived from H, then the
    definition of H' implicitly includes a primary key specification of type K, becoming
    (H', T', K). The implicit interface for H' shall have the form specified for an
    implicit interface of a home with primary key K and component type T'.

    In same document section 615.3.3.6 Home I see no mention that a keyless
    home that inherits from a keyed home is implicitly a keyed home and thus
    the Home Implicit Executor Interface must be constructed for a keyed home
    using the key type declared for the base keyed home. Everyone agree?

  • Reported: CORBA 3.0 — Fri, 7 Jun 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Generic operations for subscribing/unsubscribing at publishing ports

  • Key: CORBA3-102
  • Legacy Issue Number: 4983
  • Status: closed  
  • Source: Anonymous
  • Summary:

    generic operations for subscribing and unsubscribing at publishing ports of components should have the same funtionality as the specific ones. Therefore the generic unsubscribe operation should return the unsubscribed consumer reference like the specific operation does. proposal: change

    void unsubscribe (in FeatureName publisher_name, in Cookie ck) raises (InvalidName, InvalidConnection);

    to

    EventConsumerBase unsubscribe (in FeatureName publisher_name, in Cookie ck) raises (InvalidName, InvalidConnection);

  • Reported: CORBA 2.6 — Fri, 15 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

simple type element of the property file issue

  • Key: CORBA3-108
  • Legacy Issue Number: 5429
  • Status: closed  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    In document 01-11-03.pdf section 69.8.2.8 the simple type element
    of the property file descriptor excludes the types:

    long long
    unsigned long long
    long double
    wchar

    Is there any reason why we can't add these types to the simple element?

  • Reported: CORBA 3.0 — Thu, 13 Jun 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Issues related to CCM's XML descriptors: chapter 69.7.2.25

  • Key: CORBA3-111
  • Legacy Issue Number: 5495
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    chapter 69.7.2.25
    the given reference to the fileinarchive element is wrong
    (69.3.2.11);
    the right one is 69.3.2.12

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Correct the false cross-reference

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

Issues related to CCM's XML descriptors: chapter 69.4.5.16

  • Key: CORBA3-110
  • Legacy Issue Number: 5494
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    chapter 69.4.5.16
    this eventpolicy element is said to be child element of
    corbacomponent
    in fact it can be child element of: consumes, emits, publishes
    but it's NOT a child element of corbacomponent

  • Reported: CORBA 3.0 — Tue, 23 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Issues related to CCM's XML descriptors: chapter 69.4.4

  • Key: CORBA3-109
  • Legacy Issue Number: 5492
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    chapter 69.4.4
    the sample componentkind definition given as an entity with
    "process" lifetime seems
    unadapted as described in 69.4.5.49, we can give a best lifetime
    with "container"

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

add a ClientInterceptor then create_POA() in the post_init() method?

  • Key: CORBA3-95
  • Legacy Issue Number: 5764
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Isit possible to add a ClientInterceptor then create_POA() in the
    post_init()
    method? It seems that the ClientInterceptor is not called after that. Do
    you know the
    reason why?

    My Investigation:
    If the post_init method in SampleClientLoader.C creates the new POA
    using create_POA method, the client side PI will not be called. Even if
    an ORB-mediated call is made from within post_init(), ServerInterceptor
    is called beyond the scope of post_init(). Moreover, even if an
    ORB-mediated call is made from within post_init() in VisiBroker for
    Java, ClientInterceptor and ServerInterceptor are called beyond the
    scope of post_init(). However, in Visibroker for C++, the
    ClientInterceptor of VBC is not called. Please see the attachments for
    the difference in results of VBC & VBJ. A testcase is also attached.

    Any comments will be greatly appreciated.

  • Reported: CORBA 3.0.1 — Mon, 18 Nov 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

CORBA::WrongTransaction and Interceptors

  • Key: CORBA3-94
  • Legacy Issue Number: 5743
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    How can a portable OTS implementation, using only Portable Interceptors,
    achieve the correct semantics for raising CORBA::WrongTransaction from
    Request::get_response or ORB::get_next_response or type specific
    pollers? There doesn't appear to be a way to do this for two reasons:

    1. ClientRequestInterceptors can only change a request result into a
    system exception, but WrongTransaction is a user exception.

    2. 21.4.4.6 says:

    "Interceptors shall assume that each client-side interception point
    logically runs in its own thread, with no context relationship between
    it and any other thread. While an ORB implementation may not actually
    behave in this manner, it is up to the ORB implementation to treat
    PICurrent as if it did."

    I take this to mean that the PICurrent in the receive_* client
    interception points cannot be guaranteed to share the same slot data as
    the client thread that called Request::get_response. This means that
    the interceptor has no way to determine whether or not the transaction
    context of the client thread matches that of the request.

  • Reported: CORBA 3.0 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Resolved together with 3599. Resolution appears in the resolution for 3599

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

How do Portable Interceptors interact with Messaging callbacks

  • Key: CORBA3-93
  • Legacy Issue Number: 5726
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    In the messaging callback model, the response is delivered as a request
    invocation on another object. What is the call-pattern for
    ClientRequestInterceptors in this case?

    My guess is that the receive_other interception point is called for each
    registered ClientRequestInterceptor.

  • Reported: CORBA 3.0 — Fri, 25 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

What ORBInitInfo operations are legal during pre_init() and post_init()?

  • Key: CORBA3-92
  • Legacy Issue Number: 5691
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There is no information in chapter 21 that specifies which operations on
    ORBInitInfo can be legally called during pre_init or post_init.

    The intention appears to be that calls to register new interceptors or
    allocate a new slot id should be illegal during post_init.

    Calling resolve_initial_references during pre_init does not appear to be
    wise, but otherwise seems benign.

    Proposed resolution:

    Add the following to 21.7.1.2:

    "During a call to post_init(), invoking the ORBInitInfo methods:
    add_client_request_interceptor, add_server_request_interceptor,
    allocate_slot_id or add_ior_interceptor will raise the BAD_INV_ORDER
    standard system exception with minor code nnn."

  • Reported: CORBA 3.0 — Fri, 18 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fix it as suggested in the archive.

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

ORBInitInfo::arguments() underspecified

  • Key: CORBA3-91
  • Legacy Issue Number: 5690
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    21.7.2.3 states:

    "This attribute contains the arguments passed to ORB_init. They may or
    may not contain the ORB's arguments."

    First, what good does this do? A portable application can't depend on
    anything useful being returned by this attribute.

    This should be changed to state that ORBInitInfo::arguments() returns
    the original unmodified argv parameter that was passed to ORB_init.


    Second, this attribute really ought to be read-write, so that an
    Interceptor implementation can find and strip out arguments that are
    intended for the Interceptor.

    Alternatively, we should specify a standard prefix for arguments that
    are recognized and processed by interceptors, so that the ORB and client
    code can be explicitly coded to recognize and ignore them.

  • Reported: CORBA 3.0 — Wed, 16 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Exception handling in Interceptor initialization

  • Key: CORBA3-90
  • Legacy Issue Number: 5689
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    It is undocumented what should happen if an exception is thrown while
    the ORB initialization process is calling ORBInitializer::pre_init or
    post_init.

    In section 21.7.3.1 concerning the Java binding, the following statement
    related to calling pre_init and post_init appears:

    "If there are any exceptions, the ORB shall ignore them and proceed."

    Taking this as precedent, it suggests that exceptions raised by pre_init
    and post_init should be ignored. However, I'm not convinced that this
    is a good idea, since a failure in an ORBInitializer is very likely to
    cause the application to fail in mysterious ways later on that would be
    difficult to debug.

    I think it would be better to define explicit behavior for exceptions
    raised from pre_init and post_init to be that the ORB initialization is
    abandoned and the ORB is destroyed. Any ORBInitializer implementation
    that really needs the ORB to ignore any thrown exceptions can simply
    catch and discard them itself.

  • Reported: CORBA 3.0 — Wed, 16 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Derived component supported interface restriction (formal/2002-06-01)

  • Key: CORBA3-89
  • Legacy Issue Number: 5687
  • Status: closed  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    Both the CORBA spec (formal/02-06-01 page 3-61) and the CCM spec (formal/02-06-65 page 1-51) state that "A derived component type may not directly support an interface."
    Resolution:

    In formal/02-06-65 page 1-51 and formal/02-06-01 page 3-61 replace the sentence

    "A derived component type may not directly support an interface."

    with

    "If a derived component type directly supports one or more IDL interfaces, the component interface is derived from both the interface of its base component type and the supported interfaces."

  • Reported: CORBA 3.0 — Thu, 10 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Local types allowed as valuetype state?

  • Key: CORBA3-88
  • Legacy Issue Number: 5674
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    A bullet in 3.8.7 states:

    "o A local type may not appear as a parameter, attribute, return type,
    or exception declaration of an unconstrained interface or as a state
    member of a valuetype."

    while 3.9.1.4 says:

    "A valuetype that has a state member that is local (i.e. non-marshalable
    like a local interface), is itself rendered local. That is, such
    valuetypes behave similar to local interfaces when an attempt is made to
    marshal them."

    I presume the second statement is the correct one.

    Proposed resolution:

    Strike "or as a state member of a valuetype." from the bullet in 3.8.7.

  • Reported: CORBA 3.0 — Sat, 12 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Presumption is correct. Fix as suggested

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

Why does PollableSet::number_left() return unsigned short?

  • Key: CORBA3-87
  • Legacy Issue Number: 5673
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Is there a particular design reason to limit the Pollable count to
    65535?

  • Reported: CORBA 3.0 — Mon, 7 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Incorporate change and close issue

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

Pollable in more than one PollableSet?

  • Key: CORBA3-86
  • Legacy Issue Number: 5672
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The descriptions of Pollable and PollableSet in 7.4 do not indicate if
    it is legal to add a Pollable to more than one PollableSet. If this is
    made illegal, it is easier to implement Pollable and PollableSet to
    cooperate behind the scenes to improve the efficiency of the PollableSet
    implementation.

    Recommended Resolution:

    Make it illegal to add a Pollable to more than one PollableSet, by
    adding the following text to 7.4.3.2:

    "If the supplied Pollable has already been added to another PollableSet,
    this operation raises the standard BAD_PARAM system exception with minor
    code XYZ.

    and add a new minor code for BAD_PARAM to appendix A:

    "XYZ: Attempt to add a Pollable to a second PollableSet."

  • Reported: CORBA 3.0 — Sat, 5 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Oneway operations should not generate sendc_ and sendp_ variants

  • Key: CORBA3-85
  • Legacy Issue Number: 5669
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Somewhere in the discussion in 22.6, it should specify that oneway
    operations are not mapped with sendc_ and sendp_ variants, because they
    would be useless.

  • Reported: CORBA 3.0 — Mon, 30 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

DII sendc reply delivery underspecified

  • Key: CORBA3-84
  • Legacy Issue Number: 5668
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    7.2.10 states that sendc delivers the reply by using the supplied
    Messaging::ReplyHandler, but it does not spell out the mechanics of the
    delivery.

    I presume that for an invocation of operation "foo", the "foo" or
    "foo_excep" methods of the ReplyHandler will be invoked to deliver the
    reply

  • Reported: CORBA 3.0 — Mon, 30 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Yes, indeed. Insert a short description in section 7.10.2 on how the reply is obtained from the Repl

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

Bad example code in 22.11.4.3

  • Key: CORBA3-83
  • Legacy Issue Number: 5667
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The example code in 22.11.4.3 seems to be from a draft version of the
    Messaging specification where the Pollable type was an interface rather
    than a valuetype

  • Reported: CORBA 3.0 — Mon, 30 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Turns out that the examples in both 22.11.4.2 and 22.11.4.3 need fixing. Make changes as described

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

Messaging Poller generation is broken for interfaces with multiple inherite

  • Key: CORBA3-82
  • Legacy Issue Number: 5666
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    22.10.1 states that Type-Specific poller valuetypes inherit from the
    poller valuetype associated with the interface that the original
    interface inherits from. This does not address multiple inheritance,
    and in fact it cannot, since valuetype inheritance is more limited than
    interface inheritance.

    The problem is that the base valuetype for polling, Messaging::Poller,
    is not abstract, and cannot be inherited more than once by a derived
    valuetype. So as it stands now, the AMI polling model is broken for
    multiple inheritance, and needs to be treated as an urgent issue in
    order to produce an immediate fix.

    Proposed resolution:

    1. Make Messaging::Poller an abstract valuetype, and remove the state
    members from it. Change the IDL for Poller in 22.9 and 22.16.1 to:

    module Messaging {
    abstract valuetype Poller : CORBA::Pollable

    { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; }

    ;
    };

    2. Add back the private target and op_name state members to the
    persistent type-specific poller valuetypes. Modify the example IDL in
    22.10.2 to:

    valuetype AMI_<ifaceName>PersistentPoller : AMI_<ifaceName>Poller

    { private MessageRouting::PersistentRequest outstanding_request; private Object target; private string op_name; }

    ;

    This is necessary so the PersistentPoller can be propagated from one
    process to another with all of its necessary state.

    3. Change the text in 22.10.1 that describes inheritance of
    type-specific pollers to:

    For each interface, the IDL compiler generates a type-specific Poller
    value. A Poller is created by the ORB for each asynchronous invocation
    that uses the polling model operations. The name of the basic
    type-specific Poller is AMI_<ifaceName>Poller, where ifaceName is the
    unqualified name of the interface for which the Poller is being
    generated. If the interface ifaceName derives from one or more IDL
    interfaces, then the Poller is derived from the corresponding
    Poller for each base interface, but if it does not, then it is derived
    from Messaging::Poller. Poller valuetypes are declared abstract. If
    this name conflicts with definitions in the original IDL, additional
    AMI_ prefixes are prepended before <ifaceName> until a unique valuetype
    name is generated (such as "AMI_AMI_FooPoller"for interface Foo).

    4. Change the example IDL in 22.10.3 to make the poller abstract:

    // AMI implied-IDL of type-specific Poller
    // for original example IDL defined in Section 22.5
    abstract valuetype AMI_StockManagerPoller : Messaging::Poller {
    ...

    and add the target and op_name private state members to the persistent
    poller:

    valuetype AMI_StockManagerPersistentPoller : AMI_StockManagerPoller

    { private MessageRouting::PersistentRequest request; private Object target; private string op_name; }

    ;

  • Reported: CORBA 1.1 — Mon, 28 Sep 1992 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Make the changes recommended in the archive

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

name disambiguation for AMI interface & poller names is confusing

  • Key: CORBA3-81
  • Legacy Issue Number: 5665
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The rule for generating a unique AMI_ callback or poller name is to
    stuff additional "AMI_" strings until the name is unique. However,
    consider the following IDL:

    // IDL
    module M {

    interface A {
    };

    interface AMI_A {
    };

    };

    this apparently maps to the implied IDL:

    // implied IDL
    module M {

    interface A {
    };

    interface AMI_AMI_A

    { // callback interface for A }

    ;

    interface AMI_A {
    };

    interface AMI_AMI_AMI_A

    { // callback interface for AMI_A }

    ;
    };

    however, if I switch the order of declaration of A and AMI_A, the names
    of the associated callback interfaces change.

    Not only that, but if I split the IDL into two files:

    // File 1
    module M {

    interface A {
    };
    };

    // File 2
    module M {
    interface AMI_A {
    };

    };

    and try to compile them separately, the generated code will fail.

    I don't think there is any solution to this problem other than to
    declare it an error to use an IDL identifier that begins with "AMI_" if
    it causes a name clash.

    The same problem applies to the AMI poller valuetypes.

  • Reported: CORBA 3.0 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Resolution: Insert the requirement that any IDL that is meant to be used for AMI should not have any

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

potential name clash with Messaging type-specific poller timeout argument

  • Key: CORBA3-80
  • Legacy Issue Number: 5663
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The name generated for the type-specific poller timeout argument is
    "timeout", which could clash with a real IDL argument name.

    The name should be changed to "ami_timout", similar to "ami_return_val".

  • Reported: CORBA 3.0 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    make it so

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

What ORBInitInfo operations are legal during pre_init() and post_init()?

  • Key: CORBA3-101
  • Legacy Issue Number: 5692
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There is no information in chapter 21 that specifies which operations on
    ORBInitInfo can be legally called during pre_init or post_init.

    The intention appears to be that calls to register new interceptors or
    allocate a new slot id should be illegal during post_init.

    Calling resolve_initial_references during pre_init does not appear to be
    wise, but otherwise seems benign.

    Proposed resolution:

    Add the following to 21.7.1.2:

    "During a call to post_init(), invoking the ORBInitInfo methods:
    add_client_request_interceptor, add_server_request_interceptor,
    allocate_slot_id or add_ior_interceptor will raise the BAD_INV_ORDER
    standard system exception with minor code nnn."

  • Reported: CORBA 3.0 — Thu, 17 Oct 2002 04:00 GMT
  • Disposition: Duplicate or Merged — CORBA 3.0.2
  • Disposition Summary:

    duplicate of issue 5691

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

AMI vs abstract & local interfaces

  • Key: CORBA3-100
  • Legacy Issue Number: 5664
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The spec is silent about the interaction of AMI implied IDL and abstract
    interfaces

  • Reported: CORBA 3.0 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Clarify that sendc_ and sendp_ operations are not generated for abstract interfaces

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

Sending codeset context more than once?

  • Key: CORBA3-99
  • Legacy Issue Number: 3318
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Question: Is it legal to send the same codeset context more than once
    on the same connection?

    The spec says:

    Codeset negotiation is not performed on a per-request basis,
    but only when a client initially connects to a server.

    These words suggest that the codeset must be sent on the first request,
    but don't say whether it's OK to send it more than once.

    I would like to have clarification, and also a loose interpretation. Here
    is why:

    A multithreaded client starts talking to a new object from
    multiple threads more or less simultaneously. If the codeset
    info must be sent only on the first request and is illegal on
    subsequent requests, we end up with rather complex locking
    logic in the connection management layer of the ORB. In effect,
    each request is no longer a stand-alone and context-free thing;
    instead, how to send a specific request now depends on what
    other threads may have done in the past.

    That's not very nice (even though it can be implemented) because
    it needlessly complicates things.

    So, I would like to change things such that it is legal to send the
    codeset context even if it was sent previously on the same connection.
    When that happens, the server should simply and silently ignore all
    but the first context (even if the subsequent contexts have different
    codeset information from earlier ones). That way, requests remain
    context-free. [ Yet again, we see a sterling demonstration that attaching
    semantics to the duration of a connection was a very bad idea, especially
    in a model that is connectionless ]

    Further, it seems pointless to send codeset info at all unless the client
    actually uses an operation that involves a wchar or wstring parameter.
    So, I think it would make sense to relax things such that the codeset
    need not be sent until the first request is made that requires sending it.

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

    see above

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

Getting reply svc ctxts from PersistentRequests

  • Key: CORBA3-98
  • Legacy Issue Number: 2629
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It does not appear that reply service contexts are maintained when retrieving
    polled requests from a Router. Although the Router interfaces properly
    propogate the service contexts to the the untyped reply handler representing the
    PersistentRequest, there is no way for the client to retrieve these contexts
    from the PersistentRequest::get_reply. This may make it impossible for the
    client to interpret the reply data (e.g. if the reply contained CodeSet
    contexts).

  • Reported: CPP 1.0 — Tue, 4 May 1999 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Type code creation

  • Key: CORBA3-97
  • Legacy Issue Number: 5771
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The core spec says in section 4.11.3:

    Typecode creation operations that take name as an argument shall check that
    the name
    is a valid IDL name or is a null string.

    This is oxymoronic: we are talking about IDL here; IDL does not have the
    concept of
    a null string. If anything, we can say "empty string".

    Looking at this bit of spec, it would appear that a call such as

    orb->create_interface_tc(someRepId, 0);

    is legal. But that doesn't make sense because it's illegal to pass null
    pointers
    across IDL interfaces in C++ (or null references as strings in Java).

  • Reported: CORBA 3.0.1 — Sun, 1 Dec 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fix as suggested

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

Unfortunate CDR Encapsulation of ASN.1 Encodings

  • Key: CORBA3-96
  • Legacy Issue Number: 5766
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Document: Chapter 24 Corba, CSIv2

    There is a misinterpretation in the current JDK implementations as to the
    interpretation of the word of "encapsulation" in the CSIv2 specification
    in relation to the encoding of the fields within the CSI Identity Token.

    The issue is that the JDK and already certified implementations have
    performed a CDR encapsulation of the byte arrays within the Identity
    Token. This CDR encapsulation is not needed as the the Identity Token is
    already a CDR encapsulation, so further CDR encapsulating the byte array
    containing the ASN.1 encodings is inefficient.

    We can suggest that current implementations do not generate CDR
    encapsulation for these fields, yet accept them to be compatible with
    misaligned implementations.

    Proposed Fix:

    Remove the word "encapsulation" before "octet stream" from the rows of the
    table 24-2 "Identity Token Types".

    Remove the word "encapsulation" in the paragraph in section 24.2.3
    "Authorization Token Format".

    Remove the word "encapsulated" in the comments in the IDL section for the
    definition of the X509CertifcateChain.

    Remove the sentence "The two-part SEQUENCE is encapsulated in an octet
    stream." in the IDL definition for "const AuthorizationElementType
    X509AttributeCertChain".

    Add paragraph to section 24.2.5 "Identity Token Formats".

    The identity token for ITTPrincipalName, ITTDistinguishedName,
    ITTX509CertChain should contain their respective ASN.1 encodings of the
    name directly. However, the token may contain a CDR encapsulation of the
    octet stream that contains the ASN.1 encoding of the name. The TSS shall
    distinguish the difference by the first octet of the field. The values of
    0x00 or 0x01 shall indicate that the field contains a CDR encapsulation.
    Any other value indicates the field for these identity token types
    contains the ASN.1 encoded value. For instance, the ASN.1 encoding for
    ITTPrincipalName starts with 0x04, and ITTDistinguishedName and
    ITTX509CertChain each start with 0x30. The TSS shall accept both the CDR
    encapsulation form and the direct ASN.1 encoding for these identity token
    types.

  • Reported: CORBA 3.0.1 — Tue, 19 Nov 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Indeed a severe interoperability problem. Fix as suggested.

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

Messaging type-specific poller valuetypes should be abstract

  • Key: CORBA3-79
  • Legacy Issue Number: 5661
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The generated type-specific poller valuetypes generated for an interface
    should be abstract valuetypes and should inherit the corresponding
    type-specific poller valuetypes of the base interfaces.

    Without this, code reuse is prevented in both implementing the
    type-specific poller valuetypes, as well as in using them in client
    code.

  • Reported: CORBA 3.0 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The resolution of 5666 fixes this. Close this one no change with that comment

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

Errors in definition of Messaging poller types

  • Key: CORBA3-78
  • Legacy Issue Number: 5660
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The definintion of Messaging::Poller in section 22.9 is missing the
    keyword "private" on the target & op_name valuetype attribute
    declarations.

    The persistent poller in 22.10.2 is also missing a "private" on the
    "outstanding_request" attribute, as well as the example in 22.10.3.

  • Reported: CORBA 3.0 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Resolution: Fix as suggested. No problem with versioninhg since the published IDL already contains t

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

Messaging: bad example code for type specific poller

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

    22.10.3 has bad example code for the type specific poller generated for
    the StockManager interface. The AMI_StockManagerPoller is shown with
    the following:

    valuetype AMI_StockManagerPoller : Messaging::Poller

    { ... attribute AMI_StockManagerHandler associated_handler; ... }

    ;

    This is illegal, since Messaging::Poller also defines an attribute named
    "associated_handler". Since the text does not specify that this
    attribute ought to be generated in a type-specific poller, I suspect
    that this is an editing mistake from a draft version of the Messaging
    RFP response and should be removed.

    The C++ example generated code in 22.11.4.2 also needs to be edited to
    remove the associated_handler attribute as well.

  • Reported: CORBA 3.0 — Wed, 11 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The observation above is correct. Fix it

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

SyncScope for oneway invocations

  • Key: CORBA3-76
  • Legacy Issue Number: 5641
  • Status: closed  
  • Source: Eternal Systems ( Wenbing Zhao)
  • Summary:

    I was reading the CORBA specification (formal/02-06-01) concerning the
    SyncScope for oneway invocations. I found out that there is a mismatch on
    the meaning of SYNC_WITH_TARGET:

    On page 21-23 (Request Interceptors), there is the following paragraph:

    "For SYNC_WITH_SERVER and SYNC_WITH_TARGET, the server does send an empty reply back to the client before the target is invoked."

    That is true for SYNC_WITH_SERVER, but not correct according to the specification of the CORBA Messaging service, given on page 22-7:

    "SYNC_WITH_TARGET - equivalent to a synchronous, non-oneway operation in CORBA. The server-side ORB shall only send the reply message after the target has completed the invoked operation."

    Note that a reply is send back to the client AFTER the target has completed the invoked operation, not BEFORE.

    This error has been around already in eariler versions of the CORBA specification.

  • Reported: CORBA 3.0 — Mon, 9 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The statement about SYNC_WITH_TARGET in 21-23 is indeed wrong. Fix it.

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

Messaging time based policy enforcement?

  • Key: CORBA3-75
  • Legacy Issue Number: 5626
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 22.2.4 provides various time-based policies to bound the
    delivery and lifetime of requests, but has no information about who
    (client, router or target server) is responsible for enforcing those
    policies. Without this information, there will certainly be
    interoperability issues.

  • Reported: CORBA 3.0 — Mon, 2 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fix it as suggested in the archive with a few minor changes

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

determining TimeT or UtcT value

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

    The Time service states that determining if a TimeT or UtcT value is
    absolute or relative needs to be specified by the context. One presumes
    that the Messaging RequestStartTimePolicy, RequestStopTimePolicy,
    ReplyStartTimePolicy and ReplyEndTimePolicy contain absolute timestamps,
    and that RelativeRequestTimeoutPolicy and RelativeRoundtripTimeoutPolicy
    contain relative timestamps. The specification should make the context
    explicit.

  • Reported: CORBA 3.0 — Sun, 1 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Is a router allowed to pick any value in the range for a priority?

  • Key: CORBA3-73
  • Legacy Issue Number: 5622
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Does it make sense (and is it legal) for a request to be sent with a
    RequestPriorityPolicy or ReplyPriorityValue in a service context where
    the min and max priorities are not the same? Is a router allowed to
    pick any value in the range for a priority?

  • Reported: CORBA 3.0 — Sun, 1 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Close no change

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

Who is responsible for generating the TIMEOUT exception

  • Key: CORBA3-72
  • Legacy Issue Number: 5620
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    What is the expected behavior of a server or router that receives a
    request with a RequestEndTimePolicy or ReplyEndTimePolicy value that has
    expired? Who is responsible for generating the TIMEOUT exception--the
    client or server or both?

  • Reported: CORBA 3.0 — Sun, 1 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    This issue is a subset of issue 5626. Merge it with 5626 and close this issue

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

Object::validate_connection()

  • Key: CORBA3-71
  • Legacy Issue Number: 5619
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    How does Object::validate_connection() interact with RoutingPolicy
    values of ROUTE_FORWARD or ROUTE_STORE_AND_FORWARD? Should
    validate_connection() force the client to open a connection to a message
    router and fail if it cannot?

  • Reported: CORBA 3.0 — Sun, 1 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Sloppy text in CORBA 3.0, 4.3.8.1 get_policy

  • Key: CORBA3-70
  • Legacy Issue Number: 5614
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    In CORBA 3.0 section 4.3.8.1, the description of the Object::get_policy
    operation says:

    "Invoking non_existent on an object reference prior to get_policy
    ensures the accuracy of the returned effective Policy.Ifget_policy is
    invoked prior to the object reference being bound, the returned
    effective Policy is implementation dependent. In that situation, a
    compliant implementation may do any of the following: raise the standard
    system exception BAD_INV_ORDER, return some value for that PolicyType
    which may be subject to change once a binding is performed, or attempt a
    binding and then return the effective Policy."

    This is silly, since the only portable thing that applications can do is
    to call validate_connection or non_existent before calling get_policy,
    having two other non-portable behaviors just serves to make the standard
    larger and confuse users.

    We should pick one of the two reasonable behaviors--throw BAD_INV_ORDER
    or force a binding before returning a valid policy value--and make that
    the only valid behavior. Either one will be backwards compatible with
    portable code.

  • Reported: CORBA 3.0 — Thu, 29 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Makes sense. Fix it as suggested

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

Object::get_client_policy problem

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

    4.3.7.2 says:

    "Returns the effective overriding Policy for the object reference. The
    effective override is obtained by first checking for an override of the
    given PolicyType at the Object scope, then at the Current scope, and
    finally at the ORB scope. If no override is present for the requested
    PolicyType, the system-dependent default value for that PolicyType is
    used. Portable applications are expected to set the desired defaults
    at the ORB scope since default Policy values are not specified."

    Some policies may not have a sensible default value, such as
    RequestStartTime and in fact, perhaps should not have one to avoid
    putting any value in the INVOCATION_POLICIES service context. In this
    case, it would be better if get_client_policy were allowed to return a
    nil Policy reference.

    Suggested revision:

    Change the sentence that reads:

    "If no override is present for the requested PolicyType, the
    system-dependent default value for that PolicyType is used."

    to:

    "If no override is present for the requested PolicyType, a
    system-dependent default value for that Policy Type may be returned. A
    nil Policy reference may also be returned to indicate that there is no
    default for the policy."

  • Reported: CORBA 3.0 — Sat, 24 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fix as suggested

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

Inconsistent definition of semantics of RebindPolicy?

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

    4.12.3.32 states:

    > REBIND is raised when the current effective RebindPolicy, as described in
    > Section 22.2.1.2, interface RebindPolicy on page 22-5, has a value of
    > NO_REBIND or NO_RECONNECT and an invocation on a bound object reference results
    > in a LocateReply message with status OBJECT_FORWARD or a Reply message with
    > status LOCATION_FORWARD. This exception is also raised if the current effective
    > RebindPolicy has a value of NO_RECONNECT and a connection must be re-opened.
    > The invocation can be retried once the effective RebindPolicy is changed to
    > TRANSPARENT or binding is re-established through an invocation of
    > CORBA::Object::validate_connection.

    but 22.2.1.2 says:

    > If the effective Policy of this type has a rebind_mode value of NO_REBIND, the
    > ORB will raise a REBIND system exception if any rebind handling would cause a
    > client-visible change in policies. This could happen under the following
    > circumstances:
    >
    > o The client receives a LocateReply message with an OBJECT_FORWARD status and a
    > new IOR that has policy requirements incompatible with the effective policies
    > currently in use.
    >
    > o The client receives a Reply message with LOCATION_FORWARD status and a new
    > IOR that has policy requirements incompatible with the effective policies
    > currently in use.

    So the former says that a REBIND exception always occurs a rebind is
    necessary (and NO_REBIND is set), but the latter says that a REBIND
    exception only occurs when any client-visible policies would change.

    Which one is correct?

    Also, it is not clear from the specification whether an invocation on a
    new object reference that has never been bound must fail if RebindMode
    is not TRANSPARENT, forcing the use of validate_connection, or whether
    the first initial binding can proceed without the use of
    validate_connection.

  • Reported: CORBA 3.0 — Tue, 20 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

pragma prefix syntax

  • Key: CORBA3-63
  • Legacy Issue Number: 5327
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    suppose the following [pseudo-]idl:

    #pragma prefix "2abc.def"

    module xyz {
    interface q

    {...}

    ;
    };

    It would generate a Java class 'q' within package 'def.2abc.xyz'.
    The package name '2abc' is not that popular with the java compiler
    since it starts with a digit.

    From what I could see in CORBA 2.6.1, identifiers have to start
    with a character (or at least not a digit). So, I guess that the
    prefix pragma is erroneous here, right ?

    The OpenORB IDL parser 1.2.0 did though generate Java code without any
    complaints, which confuses me ...

  • Reported: CORBA 2.6.1 — Sat, 25 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Avoiding Interceptors for colocated method requests

  • Key: CORBA3-62
  • Legacy Issue Number: 5296
  • Status: closed  
  • Source: International Business Machines ( Ann Collins)
  • Summary:

    Could we please discuss the possibility of introducing a performance
    optimization for Interceptors.

    There may be considerable overhead involved in invoking Portable
    Interceptors. While some interceptors need to be invoked when caller
    and target are colocated (the locally optimized path), many do not.
    I think it would be useful to introduce a mechanism to allow this
    unnecessary overhead to be avoided for interceptors that do not need
    to be invoked on the colocated path, for example by adding a
    'run_local' parameter to the add_xxx_request_interceptor methods of
    the ORBInitInfo interface.

    I realise that this issue was touched upon during discussion of interop
    issue 4291 but, at the time, the focus was on getting the interceptor
    mechanism to work correctly in the colocated case; the performance
    aspect of the issue seems to have been lost.

  • Reported: CORBA 2.6.1 — Mon, 13 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Provide means for the optimization as shown below

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

Codeset negotiation and the CODESET_INCOMPATIBLE exception

  • Key: CORBA3-61
  • Legacy Issue Number: 5270
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    1. There's no minor code assigned to the use of CODESET_INCOMPATIBLE
    for a failed codeset negotiation in 13.10.2.6.

    2. There's no indication of what a server should do if the client
    delivers a codeset via a CodeSetContext that the server does not support
    as a transmission codeset). This isn't likely to happen, but we ought
    to close the hole. I propose that we have the server raise
    CODESET_INCOMPATIBLE (with a different minor code from 1) in this case
    too.

    3. Would it be a good idea for us to include recommendations on how to
    change a persistent server's native codeset while remaining backwards
    compatible with existing IORs floating around the world with obsolete
    CodeSetComponent data? Or is it too obvious? (Just make sure the new
    server advertises (or at least continues to support) the old native
    codeset as a transmission codeset.)

  • Reported: CORBA 2.6.1 — Tue, 7 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Replace deprecated anonymous type declarations?

  • Key: CORBA3-60
  • Legacy Issue Number: 5232
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Now that we've deprecated defining types anonymously with bounded
    strings, fixed, sequences and arrays, should we take the next step and
    deliberately purge them from the Core IDL?

    Here are the offenders that I've identified and the edits that should
    occur:

    In module CORBA:

    1. the service_detail member of struct ServiceDetail

    Fix: Add 'typedef sequence<octet> ServiceDetailData' and replace
    member type

    2. the service_options & service_details members of struct
    ServiceInformation

    Fix: Add 'typedef sequence<ServiceOption> ServiceOptionSeq' and
    'typedef sequence<ServiceDetail> ServiceDetailSeq' and replace
    member type

    In module GIOP:

    3. the magic member in the various struct MessageHeader_1_X types

    Fix: Add 'typedef char Magic[4]' and replace member types

    4. the reserved member in the struct RequestHeader_1_1 and
    RequestHeader_1_2 types

    Fix: Add 'typedef octet RequestReserved[3]' and replace member
    types

    5. the object_key member in various Header structures

    Fix: replace member types with IOP::ObjectKey

    In module IIOP:

    6. the object_key member in various struct ProfileBody_1_X types

    Fix: replace member types with IOP::ObjectKey

    7. the components member in struct ProfileBody_1_1

    Fix: replace member type with IOP::ComponentSeq

    In module IOP:

    8. the profile_data member in struct TaggedProfile

    Fix: Add 'typedef sequence<octet> ProfileData' and replace member
    type

    9. the profiles member in struct IOR

    Fix: Add 'typedef sequence<TaggedProfile> TaggedProfileSeq' and
    replace
    member type

    10. the component_data member in struct TaggedComponent

    Fix: Add 'typedef sequence<octet> ComponentData' and replace member
    type

    11. the context_data in struct ServiceContext

    Fix: Add 'typedef sequence<octet> ContextData' and replace member
    type

    also to complete fixes for cases 5, 6, and 20:

    Fix: Add 'typedef sequence<octet> ObjectKey' and
    'typedef sequence<TaggedComponent> TaggedComponentList'

    In module MessageRouting:

    12. the body member in struct MessageBody

    Fix: Add 'typedef sequence<octet> BodyData' and replace member type

    13. the object_key member in struct RequestMessage

    Fix: replace member type with 'IOP::ObjectKey'

    14. the reserved member in struct RequestMessage

    Fix: replace member type with 'GIOP::RequestReserved'

    15. the typed_excep_holder_repids in struct ReplyDestination

    Fix: replace member type with 'CORBA::RepositoryIdSeq'

    In module Messaging:

    16. the pvalue member in struct PolicyValue

    Fix: Add 'typedef sequence<octet> PolicyData' and replace member
    type

    17. the marshaled_exception member in valuetype ExceptionHolder

    Fix: Add 'typedef sequence<octet> MarshalledException' and replace
    member
    type

    In module CONV_FRAME:

    18. the conversion_code_sets member in struct CodeSetComponent

    Fix: Add 'typedef sequence<CodeSetId> CodeSetIdSeq' and replace
    member type

    In module DCE_CIOP:

    19. the object_key member in struct InvokeRequestHeader and struct
    LocateRequestHeader

    Fix: replace member type with 'IOP::ObjectKey'

    In module DCE_CIOPSecurity.idl:

    20. the components member in struct DCESecurityMechanismInfo

    Fix: replace member type with 'IOP::TaggedComponentList'

  • Reported: CORBA 2.6 — Tue, 30 Apr 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

reference_to_servant

  • Key: CORBA3-59
  • Legacy Issue Number: 5105
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    For reference_to_servant(), the spec says:

    > This operation requires the RETAIN policy or the USE_DEFAULT_SERVANT
    policy.
    > If neither policy is present, the WrongPolicy exception is raised.
    >
    > If the POA has the RETAIN policy and the specified object is present in
    the Active
    > Object Map, this operation returns the servant associated with that object
    in the Active
    > Object Map. Otherwise, if the POA has the USE_DEFAULT_SERVANT policy and a
    > default servant has been registered with the POA, this operation returns
    the default
    > servant. Otherwise, the ObjectNotActive exception is raised.

    This says that, if I use USE_DEFAULT_SERVANT, reference_to_servant() always
    and unconditionally returns the default servant.

    This appears to be wrong. In particular, I can have USE_DEFAULT_SERVANT but
    still add other servants explicitly to the AOM. If I do that, I can have,
    for example,
    servant X with object ID 1 as an explicitly activated servant, in addition
    to the default
    servant. In this situation, if I call reference_to_servant() with a
    reference with object ID 1,
    it should return servant X instead of the default servant.

    The exact same reasoning applies to id_to_servant(), which also
    unconditionally returns
    the default servant with USE_DEFAULT_SERVANT().

    I think we need to fix this – it appears that the current words are simply
    wrong.

  • Reported: CORBA 2.6 — Tue, 2 Apr 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

BAD_INV_ORDER minor code 5 and 10 mean the same thing?

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

    From the descriptions in CORBA 2.6.1 sections 7.2 and 7.2.3, the
    BAD_INV_ORDER minor codes 5 and 10 appear to mean the same thing. We
    should officially deprecate one, or state that either is acceptable

  • Reported: CORBA 3.0 — Sun, 30 Jun 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Easiest fix is to state either is acceptable

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

Serious backward compatibility issue in the PI

  • Key: CORBA3-66
  • Legacy Issue Number: 5430
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    I have recently realized that there is a serious backward compatibility
    issue in the PI changes introduced by the Object Reference Template.
    The problem is in the IORInterceptor. The original PI specification
    defined only the establish_components method on IORInterceptor.
    ORT added 3 new methods to this interface: components_established,
    adapter_state_changed, and adapter_manager_state_changed.

    The compatibility problem arises with the Java mapping. Prior to
    the CORBA 3.0 IDL to Java mapping, local interfaces were simply
    mapped to interfaces. The mapping for the CORBA 3.0 IORInterceptor
    is then simply:

    public interface IORInterceptorOperations
    extends org.omg.PortableInterceptor.InterceptorOperations

    { void establish_components (org.omg.PortableInterceptor.IORInfo info); void components_established (org.omg.PortableInterceptor.IORInfo info); void adapter_manager_state_changed (int id, short state); void adapter_state_changed ( org.omg.PortableInterceptor.ObjectReferenceTemplate[] templates, short state); }

    public interface IORInterceptor extends IORInterceptorOperations,
    org.omg.PortableInterceptor.Interceptor, org.omg.CORBA.portable.IDLEntity
    {
    }

    Any client of PI that implements IORInterceptor from CORBA 2.6 defines only the
    establish_components method, so that client will fail on a CORBA 3.0 version of PI.

    I propose the following changes to the draft CORBA 3.0 spec to fix this problem:

    In Section 21.5.4, replace the definition of IORInterceptor with:

    local interface IORInterceptor : Interceptor

    { void establish_components( in IORInfo info ) ; }

    ;

    local interface IORInterceptor_3_0 : IORInterceptor

    { void components_established( in IORInfo info ) ; void adapter_manager_state_changed( in AdapterManagerId id, in AdapterState state ) ; void adapter_state_changed( in ObjectReferenceTemplateSeq templates, in AdapterState state ) ; }

    ;

    Replace the first sentence in 21.5.4.2 with:

    After all of the establish_components methods have been called, the
    components_established methods are called on all registered IORInterceptor_3_0
    instances.

    Replace the first sentence in 21.5.4.3 with:

    Any time the state of an adapter manager changes, the adapter_manager_state_changed
    method is invoked on all registered IORInterceptor_3_0 instances.

    Replace the first sentence in 21.5.4.4 with:

    Adapter state changes unrelated to adapter manager state changes are reported by
    invoking the adapter_state_changed method on all registered IORInterceptor_3_0
    instances.

  • Reported: CORBA 3.0 — Fri, 14 Jun 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Resolve urgently as suggested

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

OpaqueValue/add_arg never mapped to languages

  • Key: CORBA3-65
  • Legacy Issue Number: 5333
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Bill Beckwith)
  • Summary:

    As far as I can tell, OpaqueValue, a new native type
    introduced in Issue 2162 (void * in DII Chapter) for
    add_arg, was never documented in any of the language
    mappings.

    Also, the len parameter of add_arg is underspecified.

  • Reported: CORBA 3.0 — Mon, 3 Jun 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Minor codes in specified NO_IMPLEMENT exceptions incomplete/inconsistent

  • Key: CORBA3-64
  • Legacy Issue Number: 5329
  • Status: closed  
  • Source: Xanalys ( Martin Simmons)
  • Summary:

    The minor codes in the specified NO_IMPLEMENT exceptions are incomplete/inconsistent.

    In particular:

    1) In 3.7.6.1 "Semantics", minor code 3 is mentioned for DII support pseudo-operations, but 3.7.6.2 seems to specify minor code 4 for these (though it uses different wording).

    2) 3.7.6.2 "LocalObject" doesn't specify the minor code for "is_a" etc, though presumably it should be 3 as in 3.7.6.2.

    3) The explanation for minor code 3 is "Unable to use any profile in IOR." but that isn't particular clear for local objects, which probably don't have an IOR at all.

  • Reported: CORBA 2.6.1 — Tue, 28 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Valuetypes supporting forward declared interfaces

  • Key: CORBA3-58
  • Legacy Issue Number: 5100
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Interfaces cannot inherit from forward declared interfaces and
    valuetypes cannot inherit from forward declared valuetypes, but there is
    no specific prohibition against a valuetype supporting a forward
    declared interface. There should be.

    Proposed resolution:

    Add the following sentence to section 3.8.4:

    "It is illegal for a value type to support a forward-declared interface
    whose definition has not yet been seen."

  • Reported: CORBA 2.6 — Fri, 29 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Do as suggested

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

Inconsitent exception handling with find_POA & unknown_adapter

  • Key: CORBA3-57
  • Legacy Issue Number: 4982
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    I think we totally messed up the resolution to issue 3740. We added the
    following text (circa CORBA 2.5) to 11.3.3.2:

    "If unknown_adapter returns FALSE then find_POA raises
    AdapterNonExistent. If
    unknow_adapter raises any system exception then find_POA passes through
    the
    system exception it gets back from unknown_adapter."

    [ There is also a typo in this text: "unkown_adapter".]

    and this text to 11.3.8.3:

    "If find_POA receives a system exception in response to a call to
    unknown_adapter
    on a POA, find_POA raises OBJ_ADAPTER system exception with standard
    minor
    code 1."

    In the former, system exceptions raised by unknown_adapter are to be
    passed through unchanged by find_POA. In the latter, system exceptions
    raised by unknown_adapter are to be replaced with OBJ_ADAPTER(1).

    I think the former behavior is more correct, since it preserves the
    original exception and doesn't throw away useful debugging information.

  • Reported: CORBA 2.6 — Thu, 14 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The former (i.e. 11.3.3.2) is right. Change the latter to match the former

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

IOR processing performance

  • Key: CORBA3-56
  • Legacy Issue Number: 4945
  • Status: closed  
  • Source: International Business Machines ( Ann Collins)
  • Summary:

    The overhead of processing TaggedComponents within an IOR becomes
    significant when done many times, as in the case of J2EE implementations
    where multiple request interceptors are used. IOR access and creation
    performance could be improved by making better use of Java facilities to
    provide access to an IOR's components without the overhead of CDR encoding,
    and by recognising that many of the constituent parts of an IOR are
    identical for all objects within an object adapter.

    I would like to propose that we introduce a Java API for IOR, along the
    following lines:-

    An abstract model of an IOR could be defined as follows:
    an IOR has a type ID string, and contains TaggedProfile instances
    an IIOPProfile is a TaggedProfile
    an IIOPProfile is composed of an IIOPProfileTemplate and an object ID
    an IIOPProfileTemplate has an ObjectKeyTemplate, and contains
    TaggedComponents
    a TaggedComponent has an ID, and can be written to an OuputStream.
    a TaggedComponentFactory reads a TaggedComponent from an InputStream.

    It should be possible to manipulate IOR TaggedProfiles and
    IIOPProfileTemplate TaggedComponents using all of the facilities in the
    Java collections framework.

    Templates can be used to create IIOPProfile and ObjectKey because the basic
    object adapter model for object creation is to establish all properties of
    an IOR (except for type and object ID) when the object adapter is created.
    This has been present for the POA essentially from the beginning, since
    policies can only be passed to create_POA, and cannot be changed on an
    existing POA. The Portable Interceptors work has also made this clear,
    since the IOR interceptor runs only when an object adapter is created,
    which is the only time that user code can add tagged components to an IOR.

    TaggedComponent is a framework that may be extended to support application
    defined TaggedComponents. It would be necessary to be able to register
    TaggedComponentFactory instances with an ORB, in which case any IOR
    unmarshalled by that ORB instance would use the registered
    TaggedComponentFactory to unmarshal the TaggedComponent.

    In order to use the IOR API, a method would be needed, probably on ORB,
    to obtain an abstract IOR from an object reference.

  • Reported: CORBA 2.6 — Wed, 6 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    No Data Available

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

Wide string in reply before codeset was negotiated

  • Key: CORBA3-47
  • Legacy Issue Number: 4824
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Martin von Loewis posed the following rather intersting question in
    comp.object.corba:

    > Also notice that you must perform character set negotiation to
    > communicate wstring values, unlike string values. You don't have to do
    > that in the first message, though, but sometime before the first wide
    > string is transmitted (I wonder what happens if the client does not
    > negotiate a character set in its first message but the server wants to
    > sent back a wstring response, e.g. inside an any).

    The current codeset negotiation rules don't address this problem.

  • Reported: CORBA 2.6 — Tue, 12 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

conflict between CORBA specification and C++ mapping (_this method

  • Key: CORBA3-46
  • Legacy Issue Number: 4823
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I think that there is conflict between CORBA specification and C++ mapping (_this method). May be it relates both to CORBA specification and C++ mapping.

    The Portable Object Adapter chapter of CORBA 2.6 specification 11.2.7 Implicit Activation (last paragraph - before Note)

    If the POA has the MULTIPLE_ID policy, the servant_to_reference and servant_to_id operations will always perform implicit activation, even if the servant is already associated with an Object Id. The behavior of language mapping operations in the MULTIPLE_ID case is specified by the language mapping. For example, in C++, the _this() servant member function will not implicitly activate a MULTIPLE_ID servant if the invocation of _this() is immediately within the dynamic context of a request invocation directed by the POA to that servant; instead, it returns the object reference used to issue the request.

    If I am right, author thinks that _this operation can be called on servant (related to POA with MULTIPLE_ID policy) multiple times (and it will not raise PortableServer::WrongPolicy exception).

    But C++ mapping provides the following semantics of _this:

    1.36.5 Skeleton Operations 3. ... This requires the POA with which the servant was activated to have been created with the UNIQUE_ID and RETAIN policies. If the POA was created with the MULTIPLE_ID or NON_RETAIN policies, the PortableServer::WrongPolicy exception is thrown.

    Moreover CORBA specification provides the following semantics for servant_to_reference method: 11.3.8.20 servant_to_reference 2. If the POA has both the RETAIN and the IMPLICIT_ACTIVATION policy and either the POA has the MULTIPLE_ID policy or the specified servant is not active, the servant is activated using a POA-generated Object Id and the Interface Id associated with the servant, and a corresponding object reference is returned.

    If I am right, _this and servant_to_reference are very close by their semantics (sometimes _this can be implemented using servant_to_reference invocation on appropriate POA). That's why I think that C++ mapping conflicts with CORBA specification.

    Could you please provide some explanation about this problem (even if I am not right).

  • Reported: CORBA 2.6 — Mon, 4 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, close no change

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

Codeset negotiation requires clarification

  • Key: CORBA3-51
  • Legacy Issue Number: 4850
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    We need to analyze this problem in pieces, because our discussions have been all
    over
    the map.

    I have identified some legitimate needs for clarification though this discussion.
    To help
    we should target each discussion to be within one or more of these scenarios:

    Lets look at a few typical scenarios a, b, and c:

    a) server does not support international Strings

    Server cannot support Objects which use WSTRING in their IDL. It does not use
    codeset component in IORs, thus closing off Client’s use of international strings
    on the connection.

    We have a problem as to what to do with an ANY which may have WSRING in it for
    this case (we could mandate the orb to consider this a failed negotiation and go
    to the fallback of UTF-16).

    b) Server supports only Latin 1 for string, and Unicode UCS-2 for Wstring

    Server places a Codeset component in the IOR with TCS-W indicated.

    There may be a need for clarification as to what Native Code Sets should be used
    for Unicode.

    • If we view the GIOP negotiation mechanism as transport oriented, then the Server
      should put in UTF-16 as the Native Code set.in the IOR component
    • If we view it as a presentation mechanism, then the Server might put UCS-2 as
      Native code set, and UTF-16 as Conversion Code Set in the IOR component.

    What can the server legally put in the IOR component for TCS-C in this case. Is
    Null allowed? Should ISO 8859-1 be explicitly called out in the TCS-C portion of
    the codeset component?

    c) Server supports ShiftJISC for string and Unicode UCS-2 for Wstring

    There might be an issue on whether the server may also place UTF-8 in as an
    explicit Conversion code set in the TCS-C portion of the IOR component?

    If the client does not support ShiftJISC, it should assert UTF-8 in the Codeset
    Service context for the TCS-C.

  • Reported: CORBA 2.6 — Thu, 28 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

The whole negotiation thing should be removed, Unicode should be mandated

  • Key: CORBA3-50
  • Legacy Issue Number: 4846
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The whole negotiation thing should be removed from the spec and Unicode should be mandated"

  • Reported: CORBA 2.6 — Wed, 27 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, close no change

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

discussion on the create_union_tc operation could use some clarifications

  • Key: CORBA3-53
  • Legacy Issue Number: 4852
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The discussion on the create_union_tc operation could use some clarifications to prevent implementation errors.

    Firstly, in the previous paragraph of the spec it states that member names must be unique, but this is not true for unions: only the member (label) values need to be unique, not the member names.

    Secondly, there is a check that each member (label) type matches the discriminator type, but this will not hold for the default label, because according to the typecode spec (section 4.11.1) the default label type of a union will be octet so it will never match the discriminator type.

  • Reported: CORBA 2.6 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    There is indeed a defect that should be fixed by replacing a single sentence as shown below

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

IDL inheritance issue

  • Key: CORBA3-52
  • Legacy Issue Number: 4851
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    The IDL specification is unclear about the names that can be used to
    denote a base interface. Section 3.7.2 says

    "Each <scoped_name> in an <interface_inheritance_spec> must denote a
    previously defined interface."

    but the word "denote" is not defined. In particular, is the following
    legal?

    interface I { };
    typedef I J;
    interface K : J { };

    There is real IDL in use in the world that assumes that inheriting
    from a typedef is permitted. I therefore suggest re-wording the part
    of section 3.7.2 to be

    "Each <scoped_name> in an <interface_inheritance_spec> must be the
    name of a previously defined interface or an alias to a previously
    defined interface."

    A similar clarification is required in section 3.8.1.3, regarding
    valuetype inheritance.

  • Reported: CORBA 2.6 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Good point. Incorporate the clarification

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

interaction of #pragma and typeid, typeprefix

  • Key: CORBA3-49
  • Legacy Issue Number: 4835
  • Status: closed  
  • Source: Memorial University of Newfoundland ( Jeffrey Parsons)
  • Summary:

    The CCM final draft has a section on repository identity
    related declarations (3.15), and the rules for which trumps
    which and what may be reset a second time are clear. Likewise
    for the #pragma prefix, version and ID directives in section
    10.7.5. But I'm still confused about how these two things
    interact – I haven't been able to find anywhere where this is
    addressed.

  • Reported: CORBA 2.6 — Mon, 18 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

IPv6 in corbaloc URLs

  • Key: CORBA3-48
  • Legacy Issue Number: 4825
  • Status: closed  
  • Source: Progress Software ( Markus Heichel)
  • Summary:

    is there any recent specification for IPv6 addresses in corbaloc
    URLs? I could not find any hint.

    Since it is not possible to unambiguously determine the meaning
    of something like:

    corbaloc::10:5::5:6/Hello

    there should be an escape for the colons or a delimiter for
    the IP address.

  • Reported: CORBA 2.6 — Tue, 12 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

GIOP version in replies

  • Key: CORBA3-55
  • Legacy Issue Number: 4899
  • Status: closed  
  • Source: seimet.de ( Uwe Seimet)
  • Summary:

    is it allowed to return a reply with a GIOP version number of 1.0 for a
    request with GIOP version number 1.1 or 1.2, as long as the reply can be
    correctly encoded with GIOP 1.0? IMO the spec is not clear about that, i.e.
    it does not explicity state that the version numbers of request and reply
    must match. This should be clarified.

  • Reported: CORBA 2.6 — Fri, 1 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Clarify that the reply message must have the same GIOP version as the request message

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

definition of the TypeCode interface (4.11.1)

  • Key: CORBA3-54
  • Legacy Issue Number: 4870
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Jason Courage)
  • Summary:

    In the definition of the TypeCode interface (4.11.1) the length operation is defined as:

    // for tk_string, tk_sequence, and tk_array unsigned long length () raises (BadKind);

    The comment for this operation should include tk_wstring.

  • Reported: CORBA 2.6 — Wed, 27 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fixed editorially in CORBA 3.0, close no change

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

Issue with chunking

  • Key: CORBA3-43
  • Legacy Issue Number: 4806
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    15.3.4 is silent on the treatment of encapsulations containing chunked valuetypes and in particular chunked valuetypes containing encapsulations containing chunked valuetypes. My understanding of encapsulations leads me to believe that the encapsulation should ignore the current nesting level and chunk length and start from scratch, i.e. chunks within an encapsulation are calculated relative to the start of the encapsulation rather than relative to the stream.

    The reason this needs clarification is because the spec goes to great lengths to make sure chunks are not nested so I think that it would be clearer if this case was specifically discussed. Additionally I don't know whether 15.3.4.6 should include encapsulations in the list of data types that cannot be split across a chunk. In general you would probably have to read the entire encapsulation before you can decode it, so allowing it to be split across chunks might be problematic.

  • Reported: CORBA 2.6 — Tue, 15 Jan 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Clarify as shown below

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

TypeCode indirections

  • Key: CORBA3-42
  • Legacy Issue Number: 4796
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    This issues was previously raised as issue 4294, and was deferred to the
    GIOP 1.3 wishlist. Now that GIOP 1.3 is about to become a reality, I am
    re-raising the issue because of its importance for efficient RMI-IIOP
    communications. This is an interop issue, but I am also copying the
    Java to IDL list because of its impact on RMI-IIOP performance.

    CDR should allow TypeCode indirections that refer to top-level TypeCodes.
    The current prohibition of this causes servere performance penalties for
    RMI-IIOP because the Java to IDL mapping requires that Java objects of
    declared type java.lang.Object are marshalled as CORBA anys. In the case
    of a Vector or HashTable with 100 elements, this means that 100 anys must
    be marshalled. If all of these are of actual type foo, the restriction
    on TypeCode indirections means that all 100 of these data values must repeat
    the TypeCode for foo, which could be very large. This causes very substantial
    overheads, since the space and time needed to marshal the TypeCode for foo
    can greatly exceed that needed to marshal the data for foo.

    I understand why a nested indirection cannot refer to any TypeCode outside
    the scope of its enclosing top-level TypeCode. However, this restriction
    does not need to apply to a top-level TypeCode. We have made this change
    experimentally without any adverse effects and we have discovered that
    using indirections for all repeated top-level TypeCodes can speed up some
    common scenarios by at least a factor of 5 on end-to-end measurements.
    There appears to be no downside to making this change.

    Proposed Resolution:

    In the section headed "Indirection: Recursive and Repeated TypeCodes" within
    section 15.3.5.1, replace the current first bullet:

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

    by the following two bullets:

    For GIOP 1.2 and below, the indirection applies only to TypeCodes nested
    within some “top-level” TypeCode. Indirected TypeCodes are not “freestanding,”
    but only exist inside some other encoded TypeCode.

    For GIOP 1.3 and above, the indirection applies only to TypeCodes nested
    within some “top-level” TypeCode, or from one top-level TypeCode to another.
    Indirected TypeCodes nested within a top-level TypeCode can only reference
    TypeCodes that are part of the same top-level TypeCode, including the
    top-level TypeCode itself. Indirected top-level TypeCodes can reference
    other top-level TypeCodes but cannot reference TypeCodes nested within
    some other top-level TypeCode.

  • Reported: CORBA 2.6 — Fri, 21 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Chapters 13.10.1.9, and 13.10.1.12 -- issue

  • Key: CORBA3-41
  • Legacy Issue Number: 4725
  • Status: closed  
  • Source: International Business Machines ( Richard Sitze)
  • Summary:

    [3, Chapters 13.10.1.9, and 13.10.1.12] apparently indicate that both TCS-C
    and TCS-W can be byte-oriented or non-byte-oriented.

    Assume the following configurations for two communicating ORBs.

    CNCS-C = windows-1252, SNCS-C = ISO-8859-1, and CCCS-C = SCCS-C =

    {UTF-16}

    .

    The execution of the OMG code set negotiation algorithm [3, Chapter
    13.10.2.6] in this case will result in the value of the TCS-C as UTF-16!

    An IDL string will then be marshalled as UTF-16 encoded data, which may
    have embedded single-octet NULLs. This point should be mentioned explicitly
    somewhere in [3, Chapter 15.3.1.6], especially when IDL string data types
    are not allowed to contain any embedded NULLs [3, Chapter 3.10.3.2]. [3,
    Chapter 15.3.1.6] states that "Both the string length and contents include
    a terminating null". If TCS-C is selected to be UTF-16, this 'null' should
    be a null of two-octet size. [3, Chapter 15.3.1.6] should be explicit in
    stating that the concrete representation of the 'terminating null' is
    dependent on the TCS-C.

    Similarly, for the following configuration
    CNCS-W = UCS-2, SNCS-W = UCS-4, and CCCS-W = SCCS-W =

    {UTF-8}

    TCS-W will be selected as UTF-8!

    Are these configurations valid? Regardless of the answer to this question,
    [3, Chapters 13.10.1.9, and 13.10.1.12] should clarify the issue of the
    orthogonality of TCS with respect to the byte-oriented and
    non-byte-oriented code sets with appropriate examples.

  • Reported: CORBA 2.6 — Tue, 4 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Alignment for empty sequence?

  • Key: CORBA3-38
  • Legacy Issue Number: 4650
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    struct X

    { long long_1; sequence<double> double_seq; long long_2; }

    ;

    The question is, how should things be padded if double_seq is empty?
    (Assume that we are starting at byte offset 0 for marshaling this structure.)

    Approach taken by ORB 1:

    • long_1 is aligned on a four-byte boundary (offset 0).
    • The length of double_seq is aligned on a four-byte boundary,
      immediately following long_1 (offset 4).
    • long_2 is aligned on a four-byte boundary. Because double_seq is
      empty, this means that long_2 immediately follows the length of
      double_seq on the wire, so long_2 begins at offset 8 and the total
      number of bytes for the struct is 12.

    Approach taken by ORB 2:

    • long_1 is aligned on a four-byte boundary (offset 0).
    • The length of double_seq is aligned on a four-byte boundary,
      immediately following long_1 (offset 4).
    • Now four bytes of padding are inserted because the sequence element
      type is double, so the next data item is expected to start on
      an eight-byte boundary.
    • long_2 is aligned on that eight-byte boundary, so long_2 begins at
      offset 12 and the total number of bytes for the struct is 16.

    The spec isn't clear on what should happen:

    Sequences are encoded as an unsigned long value, followed by the
    elements of the sequence. The initial unsigned lon gcontains the
    number of elements in the sequence. The elements of the sequence
    are encoded as specified for their type.

    >From this, I cannot infer unambiguously which interpretation is correct.

    Both approaches seem reasonable. (Personally, I have a slight preference
    toward approach 2 because it's more consistent: after consuming the sequence,
    the next data item will always start on an 8-byte boundary, which is more
    consistent than approach 1, because the padding rules don't depend on the
    length of the sequence at run time.)

    I suspect that the best way to resolve this might be to take a majority vote
    in line with the behavior of current implementations. And, of course,
    the question now is what do we do with the GIOP version? We probably should
    increment it, but I don't see what that would achieve for already existing
    implementations, sigh...

  • Reported: CORBA 2.5 — Tue, 30 Oct 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, no change necessary

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

CORBA 2.5 and Portable Interceptors mismerged

  • Key: CORBA3-37
  • Legacy Issue Number: 4585
  • Status: closed  
  • Source: Vanderbilt University ( Mr. Ossama Othman)
  • Summary:

    The new Portable Interceptor chapter in the CORBA 2.5 specification
    has apparently been mismerged. Section 13.8 "Coder/Decoder
    Interfaces," the Codec related interfaces added to the "IOP" module,
    should supercede those in the deprecated "IOP_N" module that is listed
    in section 21.10 "Portable Interceptor IDL."

    Suggested changes include:

    • Remove the IOP_N module from Section 21.10 "Portable Interceptor
      IDL."
    • Change all instances of "IOP_N" to "IOP." In particular, methods
      listed in sections 21.3.13 (ClientRequestInfo IDL) and 21.10 refer
      to the "IOP_N" module. The following methods in section 21.10 must
      be updated:

    module PortableInterceptor {

    // ...
    local interface ClientRequestInfo

    { // ... IOP_N::TaggedComponent get_effective_component (...) IOP_N::TaggedComponentSeq get_effective_components (...) // ... }

    ;
    // ...

    local interface ORBInitInfo

    { readonly attribute IOP_N::CodecFactory codec_factory; }

    ;

    };

  • Reported: CORBA 2.5 — Mon, 1 Oct 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fixed in CORBA 3.0 (ptc/02-01-14). Close no change

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

Detecting Recursion in Other Interceptors

  • Key: CORBA3-36
  • Legacy Issue Number: 4554
  • Status: closed  
  • Source: International Business Machines ( Mr. Tim Baldwin)
  • Summary:

    We have identified a requirement where the interceptors for one service
    need to be able to detect recursive invocations made by some other
    interceptor during the processing of a request. As far as we have been
    able to determine there is no way to achieve this using the
    Request-scope/Thread-scope Current mechanism described in the spec.

    It is probably easiest to explain this using a specific example. Start
    with some form of "transaction" service that registers client-side
    interceptors so it can detect all new request invocations and add service
    contexts that perform some form of "begin transaction" processing at the
    server. This transaction service must only perform this "begin
    transaction" once per application-level request, so it allocates a
    PICurrent slot and performs the processing described in section 21.4.4.2 to
    ensure that any recursive calls it makes itself will form part of the same
    transaction and not begin a new one.

    However a problem now occurs if we introduce some other service, say a
    "security" service that has its own interceptors registered. The order in
    which these two service's interceptors run can affect what happens, but
    since interceptor ordering is undefined assume that the security
    interceptor runs first.

    An application makes a request on its own thread A. The send_request
    interceptors start to run on thread B and the security interceptor runs
    first, at this point both the RSC and TSC slots for the transaction service
    are empty. The security interceptor makes a recursive request so the
    send_request interceptors run again on a new thread C. The security
    interceptor runs again and this time doesn't recurse so the transaction
    interceptor now runs on thread C. At this point it finds its RSC slot
    empty so does a "begin transaction" and sets its TSC for thread C. We've
    now finished interceptors on thread C and return to thread B and invoke
    send_request for the transaction service. Once again it finds its RSC slot
    empty and will try to "begin transaction" again. Now we have a problem as
    we have issued two "begin transactions" for the same application request.

    In fact it as actually the second of those two "begin transactions" that we
    really want to do, as that represents the true start of the application's
    transaction. The first one (caused by the recursive call in the other
    interceptor) is at best redundant and wasteful and at worst wrong and
    problematic.

    Does anyone have any comments on this problem?

  • Reported: CORBA 2.5 — Tue, 4 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

X/Open Codeset registry is obsolete needs to be replaced

  • Key: CORBA3-27
  • Legacy Issue Number: 4236
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    13.9.1 refers to the X/Open (nee OSF) Codeset registry. This registry
    is obsolete and no longer maintained. We should replace it with the
    IANA codeset registry instead and grandfather the old values for a
    transition period.

  • Reported: CORBA 2.4.2 — Mon, 26 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Clarify that each interception point executes in a distinct logical thread

  • Key: CORBA3-26
  • Legacy Issue Number: 4173
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    To me the key word is "EACH" - in other words values set via
    PICurrent.set_slot in send_request are visible to other interceptors in
    that point and go into the RSC of client interceptors serving any
    requests made from within the interceptor(s). However, the TSC for
    receive_reply (etc) would have a clean PICurrent since it runs in its
    own logical thread.

    We should clarify this.

  • Reported: CORBA 2.4.1 — Wed, 24 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Clarify as shown below

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

11.3.2.1 Processing States (end of second paragraph and third paragraph

  • Key: CORBA3-45
  • Legacy Issue Number: 4822
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Hello, I think I've found inconsistency (or slips of the pen) in CORBA specification.

    ----------------------------------------- 11.3.2.1 Processing States (end of second paragraph and third paragraph):

    For example, if a POA is in active state, it does not change state due to an activate operation. Such operations complete successfully with no special notice.

    The only exception is the inactive state: a deactivate operation raises an exception just the same as every other attempted state change operation.

    Probably incosistent to:

    11.3.2.5 deactivate (first paragraph):

    This operation changes the state of the POA manager to inactive. This operation has no affect on the POA manager's state if it is already in the inactive state. (no more explanation about AdapterInactive exception)

    ------------------------------------------ So, each POAManager state changing operation do nothing if it will not really change the state of the POAManager (activate call on already active POAManager, for example)

    On the other hand:

    Each POAManager state changing operation raises the AdapterInactive exception if issued while the POA manager is in the inactive state.

    CORBA 2.5 specification was the first in which explanation about AdapterInactive exception during deactivate operation was removed (but third paragraph of 11.3.2.1 was not changed respectively).

    Probably, the third paragraph of 11.3.2.1 should be removed.

    Could you please provide some explanation about this problem (even if I am not right).

  • Reported: CORBA 2.6 — Mon, 4 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Potential problem using BiDir GIOP and codeset conversion service context

  • Key: CORBA3-44
  • Legacy Issue Number: 4820
  • Status: closed  
  • Source: ICL ( Chris Wood)
  • Summary:

    I've just noticed there's a potential problem when using BiDir GIOP and the codeset conversion service context, or in fact any service context that has connection rather than request scope.

    Take the following example:

    A opens connection to B

    A issues a request 1 (R1) containing the bidir service context, but not the codeset conversion service context.

    B processes R1, marking the connection as bidirectional.

    B invokes a callback object with a request (R2), this request does contain the codeset conversion service context, since B has noticed A has not set one for the request.

    A symultaniously issues another request (R3), this one does contain the codeset service context, however the codesets it selects are different.

    So we have a problem, which codesets should be used for the connection?

    The obvious solution is to force each direction to negotiate it's own character encodings, however this is not stated anywhere in the spec AFAICS. This problem will also occour for any connection specific state as set up by service contexts.

    Suggested resolution: add to the BiDir part of chapter 15 the following:

    "For any connection level state negotiated by exchange of service contexts, each direction of a bidirectional connection should be negotiated independently. For example, the codeset negotiation process shall produce independent transmission codesets for each direction"

  • Reported: CORBA 2.6 — Fri, 1 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, close no change

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

GIOP 1.2 encoding of wstring

  • Key: CORBA3-40
  • Legacy Issue Number: 4724
  • Status: closed  
  • Source: International Business Machines ( Richard Sitze)
  • Summary:

    [3, Chapter 3.10.3.2] defines an IDL wstring data type to be a sequence of
    wchars. But the GIOP 1.2 encoding of wstring is defined differently [3,
    Chapter 15.3.2.7]. A GIOP 1.2 encoded wstring is not a sequence of GIOP 1.2
    encoded wchars.

    Each individually encoded wchar is associated with an octet containing the
    size of the encoded wchar in octets [3, Chapter 15.3.1.6], whereas an
    encoded wstring is associated with an unsigned long containing the length
    of the entire wstring in octets. Probably [3, Chapter 15.3.2.7] should
    clearly mention and explain this point with sample layout diagrams of
    appropriately encoded wchars and wstrings.

  • Reported: CORBA 2.6 — Tue, 4 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

ORBs using BOMs for UTF-16 (closely related to issue 4008)

  • Key: CORBA3-39
  • Legacy Issue Number: 4723
  • Status: closed  
  • Source: International Business Machines ( Richard Sitze)
  • Summary:

    [3, Chapter 15.3.1.6] mentions the use of BOM to indicate (and override the
    OMG byte order indicator flag [3, Chapter 15.2.1]) the endian-ness of the
    UTF-16 encoded wchar or wstring data.

    This is incorrect and goes against the Unicode recommendations [1]?refer to
    the Unicode conformance clause C3 [4, Chapter 3.1], and the discussion
    related to the use of BOM [4, Chapter 2.7].

    [4, Chapter 3.1] unambiguously implies that a BOM is not necessary if a
    higher-level protocol indicates the endian-ness. [4, Chapter 2.7]
    categorically states: "if other signaling methods (the OMG byte order flag
    in this context) are used, signatures (BOM) should not be employed".

    The UTF-16 endian rules of [3, Chapter 15.3.1.6] are clearly influenced by
    [2]. In the MIME world, an initial U+FEFF or U+FFFE is interpreted as BOMs.
    The BOM (or its absence) indicates the endian-ness of UTF-16 encoded data
    in the internet MIME world. But for CORBA messages or CDR encapsulations,
    the OMG byte order flag is already explicitly marking the UTF-16 encoded
    data as UTF-16BE or as UTF-16LE. U+FEFF or U+FFFE should not be used as
    BOMs for UTF-16 encoded data in the CORBA domain.

    Therefore, it is proposed that any U+FEFF or U+FFFE, regardless of their
    positions in the marshalled data, must be interpreted as ZERO WIDTH
    NO-BREAK SPACE characters, and not as BOMs. All the references to BOM in
    [3, Chapter 15.3.1.6] must be removed altogether.

    Adoption of the above Unicode conformant rule will
    – result in more efficient encoding of wchar/wstring data?no need to place
    U+FFFE for little-endian UTF-16/UTF-32 wchars/wstrings,
    – eliminate the ugly situation, where the BOM of an UTF-16/UTF-32 encoded
    wchar/wstring data contained in a message or CDR encapsulation indicate a
    different byte order than that specified by the OMG byte order flag for the
    same message or CDR encapsulation.

  • Reported: CORBA 2.6 — Tue, 4 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    This proposal results in a complete reversal of an earlier adopted resolution, and hence would be in

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

Problem with CSIv2 and GIOP LocateRequest

  • Key: CORBA3-29
  • Legacy Issue Number: 4290
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    CSIv2 uses GIOP ServiceContexts to associate a security context with a
    given GIOP message, but the GIOP LocateRequest & LocateReply messages to
    not have a ServiceContext field to carry the CSIv2 security context
    information. Thus, it is impossible to use LocateReuest & LocateReply
    when using CSIv2.

  • Reported: CORBA 2.4.2 — Fri, 20 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

21.8.1 register_initial_reference

  • Key: CORBA3-28
  • Legacy Issue Number: 4284
  • Status: closed  
  • Source: SeeBeyond Technology Corp. ( Tom Urquhart)
  • Summary:

    21.8.1 register_initial_reference

    An operation is available in the ORB interface:
    void register_initial_reference (in ObjectId id, in Object obj) raises
    (InvalidName);
    If this operation is called with an id, Y , and an object, YY, then a
    subsequent call to ORB::resolve_initial_references ( Y ) will return object
    YY.
    InvalidName is raised if:
    " this operation is called with an empty string id;
    or
    " this operation is called with an id that is already registered, including
    the default names defined by OMG.
    What we think this means is that it would be impossible to register (and
    resolve) ORB vendor external implementations of, for example, CORBA
    Services, such as Naming, Trading, Notification, etc. as they are some of
    the "default names".

    Could you please amend the second "or" clause to something like:
    or
    " this operation is called with an id that is already registered, including
    the default LOCALLY CONSTRAINED names defined by OMG, where 'LOCALLY
    CONSTRAINED' would not then apply to any predefined CORBA Service names
    such as NameService, NotificationService, etc.
    Many thanks and apologies if you've already addressed this.

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

    see above

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

rep_id() operation on Object?

  • Key: CORBA3-33
  • Legacy Issue Number: 4337
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I'm seeing more and more questions along the lines of:

    "How can I get the repository ID of an object, given its reference?"

    The standard answer is to call get_interface() and to then grope around
    in the IFR. However, that's cumbersome, and the IFR may well not be
    populated or running.

    So, why is it that there is no way to get the repository ID from the target
    object directly? I would think that adding something like the following
    to CORBA::Object would work nicely:

    interface Object

    { // ... string rep_id(); }

    ;

    As far as the implementation is concerned, it would be trivial. We'd have
    another "_rep_id" operation name in IIOP (similar to "_get_interface" and
    "_non_existent"). On the server side, the implementation would simply
    return the repository ID of the servant (the result of _primary_interface()
    in the C++ mapping).

    Yes, I know, we'd have to rev IIOP (which we are due to do some time
    soon anyway, so we might as well add this at the same time).

    Apart from the IIOP issue, I'd be interested in hearing what other people
    think of this idea. Any glitches with it?

  • Reported: CORBA 2.4.2 — Tue, 5 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Repository ID in nil references

  • Key: CORBA3-32
  • Legacy Issue Number: 4334
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    on page 13-17, the spec says:

    A Null TypeID is the only mechanism that can be used to represent
    the type CORBA::Object.

    This is in conflict with the information provided on page 15-28:

    When a reference to a base Object is encoded, there are two allowed
    encodings for the Repository ID: either "IDL:omg.org/CORBA/Object:1.0"
    or "" may be used.

    I would suggest to strike the sentence on page 13-17 because that is a
    historical hangover.

    Also, the entire section talks about "type IDs", when what it really means
    are "repository IDs". I would suggest to hunt down all uses of "type ID"
    and to replace them with "repository ID", because that's the correct
    terminology.

  • Reported: CORBA 2.4.2 — Tue, 5 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above Close no change

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

Note on page 15-43, OBJECT_FORWARD_PERM

  • Key: CORBA3-31
  • Legacy Issue Number: 4324
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    On page 15-43, we have a note:

    Note--Usage of OBJECT_FORWARD_PERM is now deprecated, due to problems it
    causes with the semantics of the Object::hash operation.
    OBJECT_FORWARD_PERM features could be removed from some future GIOP
    versions if solutions to these problems are not provided.

    This seems to be in conflict with the decision to retain permanent forwarding
    for FT ORBs. The note needs to be either deleted or updated to reflect
    the real state of affairs.

  • Reported: CORBA 2.4.2 — Tue, 29 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Good catch. The note is simply wrong and should be removed

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

Interpretation of defined ServiceConfigurationSyntax constants is incomplet

  • Key: CORBA3-30
  • Legacy Issue Number: 4321
  • Status: closed  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    If the ServiceConfigurationSyntax identifier is a 0, the specification
    says that the contents of the associated ServiceConfiguration is an ANS.1
    Encoded version of a GeneralNames construct.

    It is not specified what a conforming client implementation does when it
    encounters this type of privilege authority. What is the conforming
    behavior of a client?

    If there is no conforming behavior, I believe the definition of
    CSIIOP:SCS_GeneralNames should be removed from the specification, as there
    is nothing "interoperable" about it, and this specification is an
    interoperability specification.

    As a remedy to this situation we should probably use a resolution of the
    VMCID solution sought after in issue 4268, and let that Vendor specify it
    in their specification (i.e. does EJB have a use for this?), when there is
    a specification for it.

    The ServiceConfigurationSyntax identifier of 1 specifies that the
    ServiceConfiguration is a GSSExported name.

    This one has a bit more use than 0, as the contents of a GSS exported name
    construct can imply a lot, such as the protocol, the format of the token,
    and a specification of where to get the authorization token.

    So, the specification should state the specific OIDs that are understood
    by a conforming CSS, and where to find the specification of the conforming
    behavior of each OID.

    Obviously there are no OID specified (yet), but there might be in the
    future. It would be nice to know where to look, or otherwise remove the
    definition of SCS_GSSExportedName from the specification.

  • Reported: CORBA 2.4.2 — Thu, 24 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

CORBA components requires new GIOP version?

  • Key: CORBA3-35
  • Legacy Issue Number: 4536
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    Please forgive me if this is old news. I was trying to find a recent
    CORBA Components spec to see what changes it has had on the core spec.

    It looks like several new TypeCode kinds have been added (two from
    CCM?), but doesn't that require a new GIOP version? Even if the specs
    did declare the wire formats in new versions of Chapter 15, how could
    older GIOP 1.2 ORBs handle them?

    Specs:

    CCM FTF drafts of modified CORBA Core chapters
    Adds tk_component and tk_home in 10.7.1. No update to 15.
    http://www.omg.org/cgi-bin/doc?ptc/99-10-03

    CORBA 2.4.2 complete specification
    Adds tk_local_interface in 10.7.1. No update to 15.
    http://www.omg.org/cgi-bin/doc?formal/01-02-01

  • Reported: CORBA 2.4.2 — Mon, 27 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change, see above

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

TypeCodes for custom marshaled valuetypes

  • Key: CORBA3-34
  • Legacy Issue Number: 4506
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    It is underspecified what value member information for custom
    marshaled valuetypes an ORB must provide.

    Users of custom marshaled valuetypes must provide their own marshaling
    code, and the ORB has no way of knowing what it does before executing
    it.

    This comes into play for custom marshaled valuetypes inside of Anys,
    as well as the ValueMemberSeq in the FullValueDescription of a custom
    marshaled valuetype.

    In both cases, one can query whether or not the valuetype is custom
    marshaled. With Anys, the TypeCode has a ValueModifier type_modifier
    which is set to VM_CUSTOM. The FullValueDescription includes a
    boolean is_custom.

    I can see two possible solutions:

    1. TypeCodes for custom marshaled valuetypes will encode no value
    member information, so the member_count will be 0. The
    FullValueDescription will have a zero length sequence for the
    ValueMemberSeq members.

    or

    2. Value member information for the TypeCode or FullValueDescription
    for a custom marshaled valuetype is the state defined in the
    valuetype's IDL in the same way as if it were not custom marshaled.

    I propose #1 as the solution. This member information is only useful
    for finding out what is encoded, and solution #2 doesn't provide
    that. Plus, it can be very expensive to create and transmit if many
    repository IDs are involved.

  • Reported: CORBA 2.4.2 — Thu, 16 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Stateful boolean causes all CSI mechanisms to operate the same way.

  • Key: CORBA3-25
  • Legacy Issue Number: 4167
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    The stateful boolean of the CSIIOP::CompoundSecMech forces all CSI
    mechanisms to behave the same way with respect to state retention. This is
    problematic and makes mechanisms parametric on the POA they are
    supporting. The retention of state is actually a function of an
    established transport, not a POA.

    Discussion:

    In the architecture (OMA) POA's are the 'owners' of object references.
    Therefore, the state retention boolean must be set there, as there is only
    one CompundSecMecList per object reference.

    You may have cases where multiple CSI mechanisms must support one POA.

    These mechanisms may span POA's as they may be defaults for many POA's. If
    state retention is parameterized on the particular mechanism, then
    negotiating the state retention for each mechanism becomes easier to
    handle, as the state retention algorithm is mechanism specific. Therefore,
    that mechanism may operate independently of knowing the POA.

    This makes the TSS mechanisms to be able to work independently of the POA
    policy.

    Also, for another reason, CSI state retention is based on the established
    transport, which has nothing to do with a POA, therefore it is part of the
    CSI mechanism over which the transport it is working.

    I think the purpose for the "stateful" boolean was ill conceived. It was
    thought of by some as a deficiency in your implementation and you needed
    to provide a single boolean so one could RED FLAG a security service
    "inferior" in some sense.

    The fact is that state retention can be inefficient in some cases. State
    retention is actually parameter that is a function of the mechanism over a
    particular transport mechanism. One may want to use mechanisms that retain
    their state where one makes lots of invocations over a single transport
    (long live connections). (State retention is a function of transport).
    Short lived connections need not incur the overhead.

    Proposed Solution:

    Move the stateful field, as follows:

    module CSIIOP {
    // type used in the body of a TAG_CSI_SEC_MECH_LIST component to describe a
    // compound mechanism

    struct CompoundSecMech

    { AssociationOptions target_requires; IOP::TaggedComponent transport_mech; AS_ContextSec as_context_mech; SAS_ContextSec sas_context_mech; boolean stateful; }

    ;

    // type corresponding to the body of a TAG_CSI_SEC_MECH_LIST component

    struct CompoundSecMechList

    { sequence <CompoundSecMech> mechanism_list; }

    ;

    };

  • Reported: CORBA 2.4.1 — Mon, 22 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    CLOSE NO CHANGE

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

Detail lacking in when request interceptors are called

  • Key: CORBA3-11
  • Legacy Issue Number: 3599
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    I set out reading ptc/2000-04-05 to answer a question: how could a
    client interceptor for the OTS implement the proper behavior for the DII
    get_response or get_next_response operations that require the
    WrongTransaction to be raised if the current thread is not properly
    associated with the same transaction as the request.

    I wasn't able to answer this question authoritatively, because there is
    nothing in the Portable Interceptors Chapter that indicates the proper
    time sequencing of when the client side request interceptor operations
    are invoked in relation to the use of the DII (or the AMI_ messaging
    interfaces either.)

    By inference, it appears to me that the only way to allow an OTS client
    request interceptor to exhibit the proper semantics is for the ORB to
    not make calls to receive_

    {reply,exception,other}

    when the response is
    received from the protocol stack, but instead to make them when
    get_response or get_next_response is called by the application.

    This paragraph in 21.3.7.2:

    "Asynchronous requests are simply two separate requests. The first
    request receives no reply. The second receives a normal reply. So the
    normal (no exceptions) flow is: first request - send_request followed by
    receive_other; second request - send_request followed by receive_reply."

    is also not particularly useful, since it doesn't give any indication
    how the interceptor can distinguish the "first request" from the "second
    request".

    So, to sum up, the PI chapter needs explicit information showing the
    time sequencing of when the request interceptor operations are invoked
    in relationship to a static call, a DII call, and AMI_ calls.

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

    see above

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

How correlate requests and replies when using pollable sets?

  • Key: CORBA3-10
  • Legacy Issue Number: 3541
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    When using the pollable sets, pollers are registered with
    PollableSet::add_pollable() and retrieved using
    PollableSet::get_ready_pollable(). As pollers are valuetypes they are passed by
    copy, thus portable applications must assume that get_ready_pollable() returns
    a different poller instance than the one passed to add_pollable(). Thus, with
    non-TII, currently there is no portable way to find out how requests
    (represented by the pollers returned from sendp) and replies (represented by
    the pollers returned from get_ready_pollable ) correlate.

    Consider the following IDL:

    module Stock
    {
    interface Quoter

    { long get_quote(in string stock_name); }

    };

    and a client that does a 1000 invocations in the style

    poller = quoter->sendp_get_quote(portfolio[i].stock_name);
    poll_set->add_pollable(poller);

    Now, the client could retrieve the 1000 replies in the order:

    while(poll_set->number_left() > 0)

    { pollable = poll_set->get_ready_pollable(timeout); ... }

    ;

    But how can the client find out which returned quote belongs to which
    stock_name?

    Possible resolutions:
    ---------------------
    (a) Reconsider the introduction of a correlation id on pollers which can be
    used to compare if two pollers are referring to the same request/reply.

    (b) Based on the fact that pollable set is locality-constrained and that
    valuetypes support sharing semantics (see CORBA 2.3, 5.2.4.2 Sharing
    Semantics), it could be required that PollableSet::get_ready_pollable() returns
    a pointer to the same valuetype instance as the one passed as argument of
    PollableSet::add_pollable().

    (c) Close without action, i.e. has to be solved at the application level, e.g.
    in our example the application would have to solve this by changing get_quote to

    long get_quote(in string stock_name, out string stock_name);

    Discussion:
    -----------
    (c) contradicts with the CORBA Messaging Philosophy that AMI is a mere
    client-side issue and that in principle any existing target can be called
    asynchronously.

    (b) means that we would have two different polling-related correlation
    mechanisms:

    • one for correlating requests and replies in different processes based on the
      PersistentRequest objref
    • one for correlating requests and replies in the same process based on poller
      pointers

    (a) means that a generic correlation mechanism is defined that covers both:
    intra- and inter-process correlation. This was variant (a) of issue 2803 in the
    latest vote. It failed with 5 NO : 4 YES : 3 ABSTAIN.

    I could work out two straw men for (a) and (b) for the next vote, or much
    better, we could try to discuss this before the next vote and just work out a
    straw man for the variant that has better acceptance.

  • Reported: CPP 1.1 — Mon, 10 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

no way to register value factory from ORB initializer

  • Key: CORBA3-18
  • Legacy Issue Number: 3793
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    There is currently no way to register a value factory from an ORB
    initializer.

  • Reported: CPP 1.1 — Mon, 28 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above.

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

ORB accessor on POA?

  • Key: CORBA3-17
  • Legacy Issue Number: 3772
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    looking at the POA IDL, I get the impression that it was written at a time
    where the use of multiple ORBs in a process wasn't anticipated. With
    the advent of messaging, OTS, QoS policies, etc, it is more and more common
    for one application to use several ORBs simultaneously.

    When writing code, it becomes an endless pain dealing with multiple ORBs.
    That's because I have to endlessly pass the ORB around in my program, just
    so I can do things like call object_to_string() or string_to_object(), etc.

    I think it would be really useful to have an ORB() accessor on the POA
    interface:

    interface POA

    { CORBA::ORB ORB(); // ... }

    ;

    The accessor would return the ORB for this POA. Doing this would eliminate
    most of the cases in my code where I have to pass the ORB around. For
    example, in a servant, I can call _default_POA(), and then call ORB() to
    get at the ORB.

    Adding the operation would cause any compatibility problems, I believe.

    Opinions?

  • Reported: CPP 1.1 — Tue, 15 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

RoutingPolicy issue

  • Key: CORBA3-16
  • Legacy Issue Number: 3770
  • Status: closed  
  • Source: Perot Systems ( Bill Binko)
  • Summary:

    This problem comes from the fact that RoutingPolicy is actually a range: min and max. Basically, Messaging defines this range of Routing QoS:

    ROUTE_NONE(0) ---> ROUTE_FORWARD(1) ---> ROUTE_STORE_AND_FORWARD(2)

    You can set your min and max to any of the values, with the caveat that min must be <= max. The issue that concerns us is when the min is ROUTE_NONE(0) and the max is either ROUTE_FORWARD(1) or ROUTE_STORE_AND_FORWARD(2).

    If you look at the Messaging spec (orbos/98-05-06) in section 5.3.5.3, it says:

    "If, for example, the min is ROUTE_NONE and the max is ROUTE_FORWARD, the Routing protocol will normally be used but a direct connection may be used if available."

    Of course, we've left in "usually" just to make sure we could screw up OTS for you

    Reading the text in section 3.3 makes me believe that an issue should really be raised in the Messaging-RTF to clarify this. Here's what I BELIEVE the results would be for all of the combinations.

    min maxresultconfidence ----------- ---------- -------------------- ROUTE_NONEROUTE_NONEDirect Call100% ROUTE_NONEROUTE_FORWARDTII if possible50% direct if not ROUTE_NONEROUTE_STORE_AND_FORWARDTII if possible50% direct if not ROUTE_FORWARDROUTE_FORWARDTII Only100% ROUTE_FORWARDROUTE_STORE_AND_FORWARDTII Only100% ROUTE_STORE_AND_FORWARDROUTE_STORE_AND_FORWARDTII Only100%

    Obviously, the problem is with cases #2 and #3.

    How should an ORB determine which to use: what priority is given to each of the RoutingType values?

  • Reported: CPP 1.1 — Mon, 31 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

ORB::shutdown vs. ORB::destroy

  • Key: CORBA3-24
  • Legacy Issue Number: 4164
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    The CORBA 2.3 spec says under ORB shutdown:

    Once an ORB has shutdown, only object reference management
    operations(duplicate, release and is_nil) may be invoked on the ORB or
    any object reference obtained from it. An application may also invoke
    the destroy operation on the ORB itself. Invoking any other operation
    will raise the BAD_INV_ORDER system exception with the OMG minor code 4.

    This implies that calling ORB::shutdown also terminates the client
    side processing. I think that this wrong. I believe that ORB::shutdown
    should terminate server side processing. ORB::destroy should terminate
    the client side processing.

  • Reported: CORBA 2.4.1 — Sat, 20 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

Encodings of Sequences of Certificates are not standard.

  • Key: CORBA3-23
  • Legacy Issue Number: 4156
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Explicit ASN.1 definitions of a sequence of certificates make a single
    ASN.1 object out of the certificates. This approach is not what most
    systems use today.

    Discussion:

    The CSI::ITTX509CertChain and the CSI::X509AttributeCertChain both
    stipulate that the encodings of these "chains" be a single ASN.1 encoded
    object. Sequences of certificates usually come in the form of a byte
    stream of either ASN.1 DER encoded objects, or PEM encoded objects, (i.e.
    Base64 encodings wrapped with "---BEGIN CERTIFICATE--", "---END
    CERTIFICATE---" lines). It would be ideal to be able to handle both of
    kinds these sequences, since many toolkits work this way already.

    Tool kits that are provided in OpenSSL and Java, namely,
    java.security.cert.CertificateFactory will not be able to handle the
    encoding brought forth by the CSIv2 specification. However, the toolkits
    will be able to handle a stream sequence of ASN.1 or even PEM encoded
    objects, i.e. without the ASN.1 SEQUENCE wrapper.

    Proposed Solution:

    Eliminate the ASN.1 definitions in the specification, namely para 50 that
    defines ASN.1 syntax for a certificate chain (i.e. "CertificateChain"),
    and para 33 thru 34 for the corresponding one that fits the
    AttributeCertificate(i.e. AttributeCertChain and VerifyingChain).

    Furthermore, I believe, that the definition of CSI:ITTX509CertChain be
    eliminated in favor of a single OID that forms a GSS_NT_ExportedName type,
    in which it's name component is simply a non-empty sequence of
    certificates (in any form), as well as creating an OID that stipulates a
    supported name type is a DN, ASN.1 encoded or string form.

  • Reported: CORBA 2.4.1 — Thu, 18 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The proposed change is backward incompatible. Close no change

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

Portable interceptors and invocation timeouts

  • Key: CORBA3-20
  • Legacy Issue Number: 3947
  • Status: closed  
  • Source: Progress Software ( Eoghan Glynn)
  • Summary:

    I'd like to raise an issue and garner feedback on the interaction of the
    Messaging timeout QoS policies (or indeed any proprietary invocation
    timeout mechanism) and portable interceptors.

    Where a bound is being imposed on request and/or reply delivery, and
    portable interceptors are present in the client- and/or server-side
    binding, these interceptors surely must be made aware of the relevant
    timeout(s) so that they may bound any potentially blocking activities
    they engage in. Assuming that it would be unacceptable to dictate that
    potentially blocking activity (such as making a subsidiary invocation)
    may not be undertaken in interception point operations, it appears some
    addition to the PortableInterceptor::RequestInfo interface is required
    to facilitate the Messaging timeout policies at least. For instance, the
    absolute request and reply expiry times could be passed as additional
    attributes:

    module PortableInterceptor
    {
    interface RequestInfo

    { // ... readonly attribute TimeBase::UtcT request_end_time; readonly attribute TimeBase::UtcT reply_end_time; }

    ;
    };

    the former bounding the send_request, send_poll,
    receive_request_service_contexts and receive_request interception points
    and the latter bounding the send_reply, send_exception, send_other,
    receive_reply, receive_exception and receive_other interception points.
    Of course this all relies on the discipline of the portable interceptor
    implementor, i.e. that they do not ignore the constraints imposed by the
    timeouts.

  • Reported: CORBA 2.4 — Thu, 12 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

Missing minor codes in Messaging Chapter

  • Key: CORBA3-19
  • Legacy Issue Number: 3914
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    Minor codes specifications are missing in all the places where the
    specifications states that a system exception is to be raised. The minor
    codes need to be specifiedto complete the specification of exceptional
    beahivior.

  • Reported: CPP 1.1 — Thu, 14 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

wchar endianness

  • Key: CORBA3-22
  • Legacy Issue Number: 4008
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    In a similar vein to Vishy's question about alignment, what should the
    endianness of a word-oriented wchar be? This applies both to single
    wchars, and the separate code points in a wstring. With the 2.3 spec,
    it seemed quite obvious to me that word-oriented wide characters
    should have the same endianness as the rest of the stream. After all,
    they are no different from any other word-oriented type.

    However, with the new 2.4 spec, there is now a bizarre section saying
    that if, and only if, the TCS-W is UTF-16, all wchar values are
    marshalled big-endian unless there is a byte-order-mark telling you
    otherwise. I don't understand the point of this. Section 2.7 of the
    Unicode Standard, version 3.0 says [emphasis mine]:

    "Data streams that begin with U+FEFF byte order mark are likely to
    contain Unicode values. It is recommended that applications sending
    or receiving untyped data streams of coded characters use this
    signature. _If other signaling methods are used, signatures should
    not be employed._"

    It seems quite clear to me that a GIOP stream is a typed data stream
    which uses its own signalling methods. The Unicode standard therefore
    says that a BOM should not be used.

    I guess it's too late to clean up the UTF-16 encoding, but what about
    other word-oriented code sets? What if the end-points have negotiated
    the use of UCS-4? Should that be big-endian unless there's a BOM?
    The spec doesn't say. Even worse, what if the negotiated encoding is
    something like Big5? That doesn't have byte order marks. Big5
    doesn't have a one-to-one Unicode mapping, so it's not sensible to
    always translate to UTF-16.

    GIOP already has a perfectly good mechanism for sorting out this kind
    of issue. Please can wchar be considered on equal footing with all
    other types, and use the stream's endianness?

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

    see above

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

No portable way to turn IOR components into object-reference policies

  • Key: CORBA3-21
  • Legacy Issue Number: 3989
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    For instance, OTS has a policy called OTSPolicy. This policy is
    encoded in an IOR component with component id TAG_OTS_POLICY. This
    policy governs how transactions are handled when invocations are made
    on the object reference.

    Problem:

    As an end user I would like to be able to interrogate the value of this
    policy. I would expect to be able to call CORBA::Object::_get_policy
    with the OTS PolicyType identifier to retrieve the OTSPolicy and
    subsequently determine the value. However, at present there is no
    portable way to turn this IOR component into a policy.

  • Reported: CORBA 2.4 — Tue, 24 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    This is in essence the same as issue 3615. Merge with 3615 and close this issue

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

Portable Interceptors / register_initial_reference()

  • Key: CORBA3-15
  • Legacy Issue Number: 3672
  • Status: closed  
  • Source: International Business Machines ( Mr. Phil Adams)
  • Summary:

    I am in the process of implementing Portable Interceptors within a C++
    ORB,
    and I would like to raise an issue for resolution regarding the semantics
    of the
    "register_initial_reference()" function, particularly with respect to the
    memory
    management of the object being registered.

    The interface for this function is as follows:

    void register_initial_reference (
    ObjectId id,
    Object_ptr obj
    );

    Within the Portable Interceptors specification, there is really no
    information about
    how the memory for the object should be managed. For example, does the
    caller of
    "register_initial_reference()" pass ownership of the object to the ORB, or
    not?
    Also, does the caller of "resolve_initial_references()" gain ownership of
    the object
    which is returned, or not?

    Here is my proposed resolution:

    The fact that the "obj" parameter is a CORBA::Object implies that it is a
    reference-counted
    object. Therefore, it would make sense that when
    "register_initial_reference()" is called, the
    ORB performs a "_duplicate()" on the object to increment its reference
    count (the ORB would
    then hold its own reference count). The caller of
    "register_initial_reference()" can decide
    whether to call "release()" or retain its own reference count.

    Later, when "resolve_initial_references()" is called, the ORB would call
    "_duplicate()" on the
    object prior to returning it to the caller, thereby giving the caller its
    own reference count.
    The caller would then need to call "release()" when it is finished with
    the object.

    When the ORB is deleted, it must clean up the lookup table of registered
    objects. To do this,
    it simply calls "release()" on each one, and if no one else holds a
    reference count, then
    the object is simply deleted.

    I would like the hear other people's thoughts on this, particularly those
    who have done or are
    working on a C++ implementation of PI.

  • Reported: CPP 1.1 — Tue, 6 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Policy Management in Portable Interceptors

  • Key: CORBA3-14
  • Legacy Issue Number: 3615
  • Status: closed  
  • Source: foxfield-sw.demon.co.uk ( Nick Sharman)
  • Summary:

    (All document refs to ptc/00-04-05)

    Sec. 4.3.7.1 (Object::get_policy) talks about "the Policy as specified in
    the IOR". Policies get translated to IOR components, but AFAIK there's no
    general way that a component can be unscrambled to give a Policy. This
    suggests that we need another interception point, effectively the inverse of
    the existing IORInterceptor (sec. 21.5), that allows an IOR component to be
    converted into a Policy on the client side.

    I suggest something like:

    local interface ReceiveIORInterceptor : Interceptor

    { void establish_policies (in ReceiveIORInfo info); }

    ;

    local interface ReceiveIORInfo

    { CORBA::Policy set_policy (in CORBA::Policy policy); IOP::TaggedComponent get_ior_component (); IOP::TaggedComponent get_ior_component_from_profile ( in IOP::ProfileId profile_id); }

    ;

    and an extra operation add_receive_ior_interceptor in ORBInitInfo.

    ReceiveIORInterceptor::establish_policies provides the opportunity for an
    interceptor to turn IOR components back into Policies, using the
    interceptor's Policy Factories directly or indirectly via
    ORB::create_policy.

    The ORB will call this method on all registered ReceiveIORInterceptor
    objects during or before the first call of Object::get_policy (we needn't be
    more specific - this would allow eager calls on unmarshalling or lazy calls
    within Object::get_policy).

  • Reported: CPP 1.1 — Mon, 15 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

ORBInitInfo needs the ORB

  • Key: CORBA3-9
  • Legacy Issue Number: 3429
  • Status: closed  
  • Source: International Business Machines ( Russell Butek)
  • Summary:

    Portable interceptor implementations need access to the ORB. The presumed
    place to put the ORB would be on ORBInitInfo since at least one
    implementation needs the ORB at initialization time. Is that sufficient?
    Or is it also needed in RequestInfo and IORInfo? My guess is that having
    ORB only on ORBInitInfo is sufficient. All interceptors begin here. If
    the ORB is needed at other points, the implementations can assure that it
    is available where it's needed.

    Since ORB is PIDL and we don't want to pollute the interceptor interfaces
    with PIDL, we have to create IDL access to the ORB, but that's another
    issue.

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

    This issue is a restatement of issue 3403. Merge with issue 3403 and close this issue

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

PI needs the ORB to be available in IDL

  • Key: CORBA3-8
  • Legacy Issue Number: 3403
  • Status: closed  
  • Source: International Business Machines ( Russell Butek)
  • Summary:

    Portable interceptor implementations need access to the ORB. In order to
    accomplish this, the ORB must be defined in IDL There are four
    possibilities that have been opined:

    1. Define the ORB as "native ORB;"

    This puts the ORB into the IDL namespace. However, the ORB is still
    described in PIDL. This doesn't really help us to remove PIDL, some folks
    feel this is a misuse of native, but it would be sufficient for the
    requirements of PI.

    2. Define an IDL wrapper for the ORB, call it proxyORB for now.

    proxyORB would contain exactly the same items that the PIDL ORB does, only
    defined in pure IDL. Advantages: this is a migration step toward getting
    rid of ORB PIDL if we encourage folks to use proxyORB rather than ORB.
    Disadvantages: dual maintenance; lots of work - too much for this FTF?; I
    don't think we know all the ramifications; where do you get a proxyORB?
    from the ORB?

    3. Make the leap and redefine ORB in IDL now.

    This option is similar to option 2, but the IDL is not a wrapper, it's the
    real ORB. Advantages: no dual maintenance; we get rid of ORB PIDL right
    now. Disadvantages: BIG step - too big for this FTF?; lots of work; I
    don't think we know all the ramifications.

    4. Make the ORB a primitive type like TypeCode.

    This seems to be generally undesired. It requires all compilers to change.
    Unless someone really likes this approach, I don't think we should even
    consider it.

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

    Resolve this issue simultaneously with 3772 and close it as soon as 3772 is resolved and closed

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

Question about routing policies

  • Key: CORBA3-7
  • Legacy Issue Number: 3355
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    How are the routing policies e.g.ImmediateSuspend, LimitedPing, UnlimitedPing,
    etc. created. It is not clear that these can be created using the standard
    create_policy operation since these policies are valuetypes that support the
    CORBA::Policy interface.

    Also what are the Policy Type tag values for these policies?

  • Reported: CPP 1.1 — Tue, 22 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

Portable Interceptors: object_to_string, string_to_object

  • Key: CORBA3-6
  • Legacy Issue Number: 3322
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    object_to_string and string_to_object are missing on ORBInitInfo.

  • Reported: CPP 1.1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Resolve in conjunction with 3772 and close this issue when 3772 is resolved

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

Implementing proper handling of CloseConnection

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

    The CORBA 2.3 spec says in chapter 15.7.1:

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

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

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

    Questions:

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

    see above, close, no change

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

Overriding POA policies

  • Key: CORBA3-13
  • Legacy Issue Number: 3609
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    it appears to be impossible to portably attach OTS policies
    to POAs with the machinery that is currently in place. We need a fix for
    that, otherwise OTS ends up getting hamstrung...

  • Reported: CPP 1.1 — Mon, 15 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    close no change

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

Portable Interceptors: 9.2.3 text describing `Arguments'

  • Key: CORBA3-12
  • Legacy Issue Number: 3601
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    The text in section 9.2.3 / page 9-71 describing the
    arguments attribute to ORBInitInfo could use some
    more precise wording. It reads:

    "This attribute contains the arguments passed to ORB_init.
    They may or may not contain the ORB's arguments."

    I take this to mean that any ORB_init arguments that
    applied to the ORB instance being created may not be
    present. All other strings passed to ORB_init will be
    present so initialisation strings can be passed to
    the interceptors through ORB_init.

    With the current text it is possible to think that
    you may not get any of the arguments to ORB_init.

  • Reported: CPP 1.1 — Wed, 3 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

No way to detect that ORB has outstanding deferred synchronous requests

  • Key: CORBA3-2
  • Legacy Issue Number: 2299
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue: There is currently no way to detect that an ORB has outstanding
    deferred synchronous requests. In the DII, this was possible via
    the blocking ORB::get_next_response operation. A mechanism is needed so
    that applications can (for example) shutdown gracefully
    only after all outstanding deferred synchronous operations have
    returned results.

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

    see above

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

constant decls broken

  • Key: CORBA3-1
  • Legacy Issue Number: 1139
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    Summary: When the extended IDL types were added to CORBA, the semantics of IDL
    constant declarations seems to have been broken. In CORBA 2.0 (July
    1995) the third paragraph of section 3.7.2 page 3-18 states:

    "An integer constant expression is evaluated as unsigned long unless
    it contains a negated integer literal or the name of an integer
    constant with a negative value. In the latter case, the constant
    expression is evaluated as signed long. The computed value is coerced
    back to the target type in constant initializers. It is an error if
    the computed value exceeds the precision of the target type. It is an
    error if any intermediate value exceeds the range of the evaluated-as
    type (long or unsigned long)."

    The paragraph following the one quoted above explains the same for
    floating-point constants.

    Unfortunately, CORBA 2.2 has broken this. Section 3.7.2, page 3-20,
    of formal/98-02-01 tells us what to do if types are long, unsigned
    long, long long, unsigned long long, double, and long double, but the
    old text stating how general integer constants and floating point
    constants were evaluated has been completely removed! How should the
    following be evaluated?

    const short S = 1 + 2;

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

    see above

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

scheme name for IORs

  • Key: CORBA3-4
  • Legacy Issue Number: 2785
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The syntax for stringified IORs in section 13.6.6 shows:

    <prefix> = "IOR:"

    The problem is that URL scheme names are supposed to be case insensitive.
    So, "Ior:" or "ioR:" should be allowed to.

    I would suggest to add a footnote to state that case for the scheme name
    is ignored.

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

    Already fixed in CORBA 3.0, close no change

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

issue with ForwardRequest exception in POA

  • Key: CORBA3-3
  • Legacy Issue Number: 2431
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The ForwardRequest exception in the POA specification doesn"t allow the
    servant manager to specify whether the status of the GIOP reply is
    LOCATION_FORWARD or LOCATION_FORWARD_PERM. If an application is designed
    to use ForwardRequest exceptions, then it should be able to state whether
    the new object reference is transient or permanent.

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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