Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — All Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA34-304 MAIN_THREAD_MODEL questions CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-305 BiDir GIOP Policy Clarification CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-221 Inconsisten IDL in the Minimum CORBA chapter CORBA 2.4.2 CORBA 3.4 Deferred closed
CORBA34-214 Fixed Types in COM CORBA 2.4.2 CORBA 3.4 Deferred closed
CORBA34-220 CosExternaliazation Service (bug?) CORBA 2.4.2 CORBA 3.4 Deferred closed
CORBA34-179 How does an ORB implement Object::get_policy for PI defined policies? CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-178 Implications of any/valuetype marshalling CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-177 Avoiding RSC/TSC copy on server side CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA25-56 SYNC_WITH_SERVER CORBA 2.4.2 CORBA 2.5 Closed; No Change closed
CORBA25-54 Incorrect example for recursive definitions which can span multiple levels CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA24-185 Definition of TRANSIENT minor code 1 confusing CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-184 IDL format for RepositoryId CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-183 Valuetypes supporting local interfaces are local types? CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-182 #pragma version issue CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-181 Servant deactivation callback? CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-180 DynUnion incomplete CORBA 2.4 CORBA 2.4.2 Resolved closed
CORBA24-179 Format of RMI Hashed Format repid CORBA 2.4 CORBA 2.4.2 Resolved closed
ZIOP-80 Attribute exception definition CORBA 2.4 ZIOP 1.0 Resolved closed
ZIOP-77 INS name ? where do we get them from ? CORBA 2.4 ZIOP 1.0 Resolved closed
CORBA26-74 explicit definition of CCM exceptions mapped from EJB standard exceptions CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-73 Incorrect syntax in Components::Enumeration CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-72 Component port introspection CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-71 "supports" terminology issue for CCM CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-70 CCM: Chapter 66 should be removed CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-69 IDL out parameters can't map to EJB? CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-68 CCM: usage of the MOF profile CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-67 CCM : Session2Context naming CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-65 Components FTF: TypeCodeFactory CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-63 Extended Interface Repository CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-66 CCM : Session2Context and Servants CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-61 Component home interface inheritance CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-64 ComponentIR Interface fixes CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-62 Problems with the Components Notification Event Interface CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-58 Component assemblies do not follow composition pattern CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-59 Component assembly templates CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-60 Component home polymorphism CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-57 Inter-component type semantics unclear CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-55 New component issue: connection failure recovery CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-56 Components, Facets, and Object References Unclear CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-53 grammar rule for home_executor_body contradicts description CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-54 Typo in assembly element paragraph heading CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-52 No Access to event filter form component CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-51 No user access to filterable body in CCM spec. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-49 CCM Events issue CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-50 IDL question concerning CCM CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-47 repository element needed by softpkg DTD CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-48 typo in connections element definition CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-46 description element need to be added to corbacomponent.dtd CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-45 Deployment Object Life Cycles CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-44 Services available for a basic container CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-43 push() versus push_event() CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-42 equivalent interfaces issue CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-41 An assembly is always mono-vendor ??? CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-40 Intent of Components::Events::(un)subscribe to bypass the notif. service ? CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-39 Channel Setup for Emits ports. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-37 ExecutablePlacement definition CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-38 exception raised by Components::Events::subscribe() CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-36 Local push() operation. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-92 Incomplete grammar in section 15.3.4.8 CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-93 Question about corbaname URL CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-91 Indirections with chunking & fragmentation CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-90 GIOP issue : fragmented replies with exceptions CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-88 GIOP is silent about extra data in the Request or Reply body CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-89 In RMI rep Id, when is inclusion of SUID legal? CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-35 simple ELEMENT definition CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-34 range description in CPF files. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA25-51 Incorrect text in 15.4.6.2 CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-50 GIOP 1.1 Fragment problem CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-53 Urgent issue: Alignment of LocateReply body CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-52 Incorrect table in section 15.4 CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-49 tk_indirect CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-46 Fixed point marshalling CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-48 Table 15-2 is missing entry for tk_local_interface CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-45 Null termination of strings CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-47 GIOP 1.2 AddressingDisposition processing on the client side CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-44 Nil return from resolve_initial_references() CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-41 COBRA problem using pragma prefix for modules CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-43 Interpretation of time field in UtcT? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-42 There is no mapping for fixed types in the COM/CORBA mapping CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-40 CORBA 2.4.2 (01-02-01.pdf) 4.2.3.4 shutdown (relevant portion) CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-38 Wither pseudo-objects? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-39 Local interface is-a Object? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-35 get_interface() underspecified CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-37 Missing TypeCode identity CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-33 DII create_request CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-36 Problem with resolution to 4285 and 4306 CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-31 String literal definition incorrect. CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-32 Ambiguity in non_existent CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-34 Typo in UML for POA CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-30 Inconsistent minor code for MARSHAL CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-28 Missing POAManager identity CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-29 Minor code CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-25 Issue: Error in section 4.5.3.2 ORBInitRef CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-26 Cross-reference refers to wrong section CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-27 BAD_OPERATION needs minor code and completion status CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-23 Restrictions on native types CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-22 Clarification about include files and IDL compiler behavior CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-20 3.7.4 Forward Declaration (for interfaces) doesn't mention local CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-21 Definition of NamingContextExt interface in IDL of Appendix A not consisten CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-24 Section 10.5.22.2 what happens when conditions not met CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-19 What is the semantics of the DataInputStream::read_*_array() operations? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-18 #include issue CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-14 ForwardRequest from normal operations CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-15 Inconsistent text for unknown system exception CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-17 DynValueBox::set_boxed_value should also raise InvalidValue CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-12 Type redefinition in derived interface CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-16 misleading wording in 10.5.22.2 Write Interface CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-13 Introduction of identifiers CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-10 core issue: unchecked narrow CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-11 PortableServer::ObjectId CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-9 Container::lookup() ordering requirements CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-6 CORBA::ORB::object_to_string() raising INV_OBJREF or BAD_PARAM CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-8 Section 2.1.7 of CORBA 2.3 and 2.4 CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-5 ServantLocator preinvoke/ postinvoke semantics CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-7 Legal IDL? CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-3 POAManager::deactivate should not mandate ORB::shutdown implementation CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-4 Minor code 2 description for OBJECT_NOT_EXIST not consistent w/ use CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-1 Can a valuetype support multiple non-abstract interfaces via inheritance? CORBA 2.4 CORBA 2.5 Resolved closed
CORBA25-2 POAManager::deactivate does not specify behavior for "reject" CORBA 2.4.1 CORBA 2.5 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-35 CORBA components requires new GIOP version? 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-34 TypeCodes for custom marshaled valuetypes 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-30 Interpretation of defined ServiceConfigurationSyntax constants is incomplet 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-31 Note on page 15-43, OBJECT_FORWARD_PERM CORBA 2.4.2 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-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-25 Stateful boolean causes all CSI mechanisms to operate the same way. 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-24 ORB::shutdown vs. ORB::destroy CORBA 2.4.1 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-22 wchar endianness CORBA 2.4 CORBA 3.0.2 Resolved closed
CORBA3-20 Portable interceptors and invocation timeouts CORBA 2.4 CORBA 3.0.2 Resolved closed
CORBA24-171 wchar alignment in GIOP 1.2 CORBA 2.4 CORBA 2.4.2 Resolved closed

Issues Descriptions

MAIN_THREAD_MODEL questions

  • Legacy Issue Number: 4155
  • Status: closed  
  • Source: Borland Software Corporation ( Andy Cutright)
  • Summary:

    i have a few questions about the POA ThreadPolicy type
    MAIN_THREAD_MODEL.

    first, the 2.4.1 spec (00-11-03), sec 4.2.3.2 , 'perform_work' states,
    "If called by the main thread, this operation performs an
    implementation-defined unit of work; otherwise it does nothing."

    how is a distinguished main thread supposed to be reliably determined?
    i'm not sure we really need to define this. i'd think what we're trying
    to say is that the thread that calls perform_work() is the thread that
    will be used to do the work, and it is up to the application to make
    sure this happens. in section 4.2.3.3, the spec states,
    "For maximum portability an application should call either run or
    perform_work on its main thread."

    to me it seems the intent is to let the application determine what the
    'main thread' is.

    second, what happens if an application calls both run & perform_work?
    and what happens if the application calls run from multiple threads? it
    isn't really clear what the difference in request handling with regard
    to the thread used is between run() & perform_work().

    right now the spec seems to imply through the use of the message loop
    example in section 4.2.3.2 that perform_work is really intended to be
    used to handle situations where a single thread must be used for all
    application activity. now add to that the note on pg 11-12 about using
    the main thread model:
    "Note - Not all environments have such a special requirement. If
    not, while requests will be processessed sequentially, they may not all
    be processed on the same thread."

    my interpretation is that ORB::run would be used in cases where you
    simply want the POAs to be accessed sequentially, but the application
    doesn't care about which thread the implementation uses, but you would
    need to call perform_work to specifically hand the application defined
    main thread to process requests.

    my suggestion (finally ;^) is that we should state perform_work should
    be called, on whichever thread the application likes, if it wants to
    hand a specific thread to the ORB to do work. otherwise, calling
    ORB::run from any thread simply means the implementation is free to
    handle requests for servants associated with main thread model POAs on
    whatever thread the implementation may choose (including a new one), in
    keeping
    with the requirement that the requests be processed on each POA's
    servants sequentially..

    one more question: does it make sense to state that a callback type of
    architecture won't work when using this threading model?

  • Reported: CORBA 2.4.1 — Wed, 17 Jan 2001 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

BiDir GIOP Policy Clarification

  • Legacy Issue Number: 4115
  • Status: closed  
  • Source: Network Associates ( Brian Niebuhr)
  • Summary:

    I am a little confused as to the scope of the BiDirPolicy in the 2.4.1
    specification. Is the BiDirPolicy a POA policy, an ORB policy, or both? In
    section 15.8 paragraph 5 on page 15-55, the specification states:

    "If the client ORB policy permits bi-directional use
    of a connection, a Request message should contain an IOP::ServiceContext
    structure in its Request header, which indicates that this GIOP connection
    is bi-directional."

    but then in section 15.9 paragraph 4 on page 15-59, the specification
    states:

    "In the absence of a BidirectionalPolicy being passed in the
    PortableServer::POA::create_POA operation, a POA will assume a policy value
    of
    NORMAL."

    but then again in the next sentence the specification states:

    "A client and a server ORB must each have a BidirectionalPolicy with a value
    of
    BOTH for bi-directional communication to take place."

    Could someone clarify for me what the intent for the scope of the policy was
    here, and what the rationale behind that decision was? We are currently
    reviewing how to use/fix BiDirIIOP in our submission to the firewall RFP,
    and I would like to understand the issues regarding the scope of the BiDir
    policy.

  • Reported: CORBA 2.4.1 — Tue, 19 Dec 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Inconsisten IDL in the Minimum CORBA chapter

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

    Section 23.14 of the CORBA/IIOP 2.4.1 specification lists the
    complete IDL for a minimumCORBA implementation. However, the text in
    the chapter and the IDL are inconsistent, for example, section 23.4.2
    reads:

    ------------------------------------------------------------------------
    ---------------
    The is_a operation is omitted so as not to introduce a requirement
    either for holding

    detailed type information in the object reference or for getting type
    information over

    the wire. Instead, minimumCORBA relies on design time resolution of type
    checking

    issues.

    The non_existent operation is omitted, because of the design philosophy
    of making

    more decisions statically at design time.

    The create_request operation is omitted, as the Dynamic Invocation
    Interface is

    omitted.

  • Reported: CORBA 2.4.2 — Sat, 3 Mar 2001 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Fixed Types in COM

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

    There is currently no specification for fixed-point types in the COM/CORBA mapping. I'm interested in getting this changed: how can we proceed? better still, is this work already under way??

  • Reported: CORBA 2.4.2 — Fri, 17 Aug 2001 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

CosExternaliazation Service (bug?)

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

    Page 2-7 of the CosExternalization Service Specification (April 2000)
    defines the following interfaces:
    CosStream::Node
    CosStream::Role
    CosStream::Relationship

    A CosStream::Node inherits from the CosStream::Streamable interface and
    therefore is a streamable object – it has an external_form_id attribute
    that enables a FactoryFinder to recreate the object using the
    create_uninitialized operation.

    Unfortunately, the CosStream::Role and CosStream::Relationship interfaces do
    not support the CosStream::Streamable interface and therefore are not
    "streamable;" in particular, there is no standard method to obtain a KEY for
    them when it is time to internalize them.

    Perhaps, I am missing something (it wouldn't be the first time , but
    having them support the Streamable interface would certainly make
    implementation much easier. Might I suggest the following:

    interface Role: CosGraphs::Role, CosStream::Streamable

    { ... }
    interface Relationship: CosGraphs::Relationship, CosStream::Streamable { ... }

    at a minimum this would permit the CosStream::Node internalize_node()
    operation and the CosStream::StreamIO read_graph() operation to use a KEY
    value in the FactoryFinder to instantiate the object, before it is
    internalized.

  • Reported: CORBA 2.4.2 — Mon, 5 Feb 2001 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

How does an ORB implement Object::get_policy for PI defined policies?

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

    The description for Object::get_policy (in the Core, section 4.3.7.1)
    states:

    "The get_policy operation returns the policy object of the specified
    type (see Policy Object on page 4-32), which applies to this object. It
    returns the effective Policy for the object reference. The effective
    Policy is the one that would be used if a request were made."

    For a policy defined by PI, I don't see anyway for the ORB to implement
    this operation correctly, since there isn't any way for it to know how
    to properly resolve any client override policies with the policy
    information stored in the IOR.

    When a invocation is actually in process, the ClientRequestInterceptor
    can use the information available in the ClientRequestInfo interface to
    get the client override and the IOR policy data and do the correct
    resolution before continuing with the request. However,
    Object::get_policy() needs to do the same type of thing, but it has no
    invocation context to do it in.

    I think the same problem also applies to the implementation of
    ClientRequestInfo::get_request_policy().

    I think we need a new interception point to do this work. Something
    like:

    local interface PolicyInterceptor

    { any determine_effective_policy(in PolicyInfo pi); }

    ;

    local interface PolicyInfo

    { readonly attribute Object target; readonly attribute Object effective_target; readonly attribute IOP::TaggedProfile effective_profile; IOR::TaggedComponent get_effective_component (in IOP::ComponentId id); IOP_N::TaggedComponentSeq get_effective_components (in IOP::ComponentId id); }

    ;

    If this turns out to be an acceptable solution, then we should also
    change ClientRequestInfo to:

    local interface ClientRequestInfo : RequestInfo, PolicyInfo

    { ... }

    ;

    and remove the redundant operations.

  • Reported: CORBA 2.4.1 — Sat, 18 Nov 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Implications of any/valuetype marshalling

  • Legacy Issue Number: 4137
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    RE: CCM chapters document [orbrev] 99-10-04, section 61.6.2, page 61-45.
    The document citation indicates that the integrity of the valuetype –
    that is, the received marshalled state – is to be preserved in an
    ORB-mediated operation, even if that valuetype cannot be unmarshalled,
    either partially (truncated) or at all. If this value is then passed to
    another operation, the original marshalled state is to be transmitted.
    This preserves the transmitted object in its entirety, regardless of
    local implementation concerns. This is obviously necessary for bridges
    or event processing, such as through the notification service.

    So the question arises, what happens if you have a partial (truncated)
    unmarshall and the recipient application changes the local state of the
    valuetype through its attributes or local operations? How can/will you
    even know the state was changed? Do you ignore the changes and send the
    originally received marshalled stream, send only the new valuetype even
    though it is a truncation of the original, or "merge" the new values for
    the unmarshalled part followed by the original appended data for the
    truncated part? Should this third option be possible through an
    explicit ORB call – that is, the application is responsible to identify
    the change in state to the ORB? I assume that the semantics of
    "truncatable" must come to include the understanding that data in the
    truncatable portions may not be contextually dependent on the inherited
    parent of the valuetype.

    As a further question, is there a reason why this semantic
    interpretation should not be extended to be a general requirement rather
    than only with respect to transmission of anys? My experience has found
    that passing anys tends to be expensive and is avoided where it can be.
    A more general interpretation permits transmission of a comprehensive
    data structure among intermediate agents that only use (unmarshall) the
    information they need.

  • Reported: CORBA 2.4.1 — Fri, 5 Jan 2001 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

Avoiding RSC/TSC copy on server side

  • Legacy Issue Number: 4169
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    During the interceptor FTF we changed the server-side threading
    requirements such that all server-side points run in the same thread
    as the ServantManager and servant except receive_request_service_contexts.

    We attempted to update 21.4.4.4 "Request Scope vs Thread Scope"
    accordingly but knew we screwed the picture and wording up. So we
    punted to the RTF.

    The main problem with the current wording is that is forces a copy of
    of TSC/RSC before the servant manager and then receive_request are
    called. This is necessary because 21.4.4.5 item 5 says: "The
    receive_request points may modify the RSC, but this no longer affects
    the TSC."

    The only way to make RSC identical to TSC in receive_request with
    respect to reading but also have them be independent with respect to
    writing is to make a copy (which could be optimized to copy-on-write,
    but why?).

    I suggest we just state they are equivalent after
    receive_request_service_contexts.

    Here is a proposed revision to ptc/00-08-06 along these lines.

    Comments?
    Harold

    21.4.4.4 Request Scope vs Thread Scope

    ... On the server-side, the request scope PICurrent is attached to
    the ServerRequestInfo and follows the request processing. It is
    logically equivalent to the thread scope PICurrent after the list of
    receive_request_service_contexts interception points are processed.

    21.4.4.5 Flow of PICurrent between Scopes

    5. The ORB logically makes the RSC equivalent to the server-side TSC
    after the receive_request_service_contexts points are processed and
    before the servant manager is called. This TSC is within the context
    for both the receive_request points, the invocation of the servant
    manager, and the invocation of the target operation.

    The receive_request points are called. These points have access to the
    RSC. Modifying the RSC at this point makes corresponding
    modifications on the TSC. Since these points execute in the same
    thread as the target operation invocation, these points may modify the
    server-side TSC which makes corresponding modifications on the RSC.

    6. After the receive_request points are called, control transfers to
    the server threads which may also read and write this server-side TSC.
    Any modifications to the TSC makes corresponding modifications on the
    RSC.

    7. <No change>

    8. <DELETE THIS ITEM>

    9. The send interception points have access to the RSC (and the
    equivalent TSC) from which they may populate the reply service context
    list. After the invocation result is sent back to the client, the
    server-side RSC is logically destroyed.

    ...

    The picture would also need updating, but let's agree on wording first.

  • Reported: CORBA 2.4.1 — Tue, 23 Jan 2001 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

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

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

SYNC_WITH_SERVER

  • Key: CORBA25-56
  • Legacy Issue Number: 4317
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    On page 22-6, we say for SYNC_WITH_SERVER:

    For a server using a POA, the reply would be sent after invoking
    any ServantManager, but before delivering the request to the target
    Servant.

    What's the motivation for this? Why wait that long? The ServantManager
    may still fail to return a servant for the request, meaning that
    the ORB might as well acknowledge the request before the ServantManager is
    called without losing anything.

    Also, as specified, the receiving ORB has to first run any adapter
    activators. Again, there doesn't seem any point in waiting this long.
    Why can't the receiving ORB simply acknowledge the request as soon as
    it has read the request header off the wire?

  • Reported: CORBA 2.4.2 — Mon, 21 May 2001 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.5
  • Disposition Summary:

    withdrawn by submitter

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

Incorrect example for recursive definitions which can span multiple levels

  • Key: CORBA25-54
  • Legacy Issue Number: 4261
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Incorrect example for recursive definitions which can span multiple levels. I and my IDL compiler are missing an identifier in the following example union for the last struct member.

    union Bar; // Forward declaration typedef sequence<Bar> BarSeq; union Bar switch(long) { // Define forward-declared union case 0: long l_mem; case 1: struct Foo

    { double d_mem; BarSeq nested;// OK, recurse on enclosing type being defined }

    ?identifier missing?; };

  • Reported: CORBA 2.4.2 — Mon, 9 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    This has already been fixed in the previous RTF see orbrev/2001-03-01

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

Definition of TRANSIENT minor code 1 confusing

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

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

    "Request discarded due to resource exhaustion in POA."

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

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

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

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

    Make it so

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

IDL format for RepositoryId

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

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

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

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

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

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

    There are two issues here:

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

    Incorporate changes and close issue.

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

Valuetypes supporting local interfaces are local types?

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

    The semantics for local interfaces states:

    A valuetype may support a local interface.

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

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

    No Data Available

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

#pragma version issue

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

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

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

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

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

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

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

    Incorporate changes and close issue

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

Servant deactivation callback?

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

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

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

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

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

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

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

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

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

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

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

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

    Close no change.

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

DynUnion incomplete

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

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

    union u switch (long)

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

    ;

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

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

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

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

    interface DynUnion : DynAny

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

    ;

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

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

    Add the is_set_to_default_member function with the functionality as described for is_set_to_default_

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

Format of RMI Hashed Format repid

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

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

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

    Clarify as suggested below

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

Attribute exception definition

  • Key: ZIOP-80
  • Legacy Issue Number: 3927
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    In 99-07-01 there was a extention of the atribute definition to enable users
    to define specific exceptions on GET/SET operations. This extension has
    disappear from 99-10-04. What is the reason for it? This extension seems to
    be quite usefull in particular if you consider component configuration
    phase.

  • Reported: CORBA 2.4 — Tue, 3 Oct 2000 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    The attribute changes are contained in the core chapter ptc/99-10-03.

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

INS name ? where do we get them from ?

  • Key: ZIOP-77
  • Legacy Issue Number: 3940
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    In 99-10-04 chapter 62.4.1.4 (The Event Interface) in the paragraph
    describing obtain_channel() and listen() the name passed to these methods
    are supposed to be an INS name. Where do we get them from?

    It seems to me that it should be the port name that should be passed and the
    container job would be to link it with an INS name (that it gets through
    container specific configuration) and then get the corresponding Admin
    interface.

    If this is what is intended we might want to make it more clear in the text.

  • Reported: CORBA 2.4 — Wed, 4 Oct 2000 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Same as issue 3937.

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

explicit definition of CCM exceptions mapped from EJB standard exceptions

  • Key: CORBA26-74
  • Legacy Issue Number: 4540
  • Status: closed  
  • Source: International Business Machines ( Ignacio Silva-Lepe)
  • Summary:

    The CCM exceptions mapped from EJB standard exceptions need to be defined
    explicitly in OMG IDL. The resolution to issue 3182 introduces new CCM
    standard exceptions Components::CreateFailure, Components::FinderFailure
    and Components::RemoveFailure but it does not define them explicitly.

  • Reported: CORBA 2.4.2 — Wed, 29 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Incorrect syntax in Components::Enumeration

  • Key: CORBA26-73
  • Legacy Issue Number: 4529
  • Status: closed  
  • Source: International Business Machines ( Ignacio Silva-Lepe)
  • Summary:

    The use of the state keyword in the Components::Enumeration valuetype,
    introduced by issue 3099 and extended in issue 3418, is not correct
    syntactically. Also, anonymous sequences have been deprecated, so the
    definition of the Components::Enumeration state is incorrect in this sense
    as well.

  • Reported: CORBA 2.4.2 — Fri, 13 Jul 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Component port introspection

  • Key: CORBA26-72
  • Legacy Issue Number: 4412
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The Components::Navigation interface that is implemented by all
    components provides introspection ("generic navigation") capabilities.
    There are lots of use cases for introspection, so I wonder why there
    is introspection for facets, but not for receptacles or event ports.
    I suggest to add such introspection capabilities. All introspection
    features should be alike as much as possible for ease of usage.

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

    see below

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

"supports" terminology issue for CCM

  • Key: CORBA26-71
  • Legacy Issue Number: 4329
  • Status: closed  
  • Source: Object Management Group ( Jon Siegel)
  • Summary:

    . I don't
    think OMG specifications should use a single term in two distinctly
    different ways. The text of the issue starts with the sentence,
    "the Components spec and valuetype spec treat "supports" exactly
    *OPPOSITE* in semantics regarding widening/narrowing." and continues
    for about 3 or 4 paragraphs. Ed's comment should go in there too.

  • Reported: CORBA 2.4.2 — Fri, 18 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

CCM: Chapter 66 should be removed

  • Key: CORBA26-70
  • Legacy Issue Number: 4307
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    Looking at ptc/99-10-04, it is not clear to me which parts of this
    document are intended as normative.

    For example, the introduction to chapter 66, "Component Container
    Architecture", states that the presented design "is not the only
    possible design choice." Consequently, it appears that the entire
    chapter 66 is not intended as normative. However, looking at the
    actual text, a reader might be easily confused into taking aspects of
    the design as normative.

    While this text was helpful in the submission to give readers an
    insight how the submitters might design their implementations, it
    should be removed from the specification, to really give implementors
    the freedom of design choice that was apparently intended with the
    submission.

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

    see below

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

IDL out parameters can't map to EJB?

  • Key: CORBA26-69
  • Legacy Issue Number: 4269
  • Status: closed  
  • Source: Progress Software ( Alan Conway)
  • Summary:

    Section 8.3.1 says "The signatures of the CORBA component operations are mapped to signatures of EJB remote interface methods following the IDL to Java mapping rules."

    As far as I can see, this only works if the IDL signature has no out or inout parameters. The Holder classes for out and inout parameters cannot be used in an EJB interface signature because they need not be Serializable, which breaks the rules for an RMI compliant class. Even if they could the EJB stubs and skeletons would not implement their special return value behavior without modifications to the EJB spec.

    Someone please tell me I've missed something!

  • Reported: CORBA 2.4.2 — Thu, 12 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM: usage of the MOF profile

  • Key: CORBA26-68
  • Legacy Issue Number: 4214
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    The CCM MOF IR draft (ptc/99-10-05) uses UML to denote the MOF model
    of the IR. Without missing elaboration, it is not possible to mentally
    construct the metamodel. For example, the enumeration, primitive, and
    unchangeable stereotypes don't have a well-defined relationship to MOF
    concepts. It seems that the MOF chapter should use the UML MOF profile
    (ad/01-02-29). In addition, it would be desirable if a normative XML
    document that defines the metamodel (following the MOF DTD) is
    provided.

  • Reported: CORBA 2.4.2 — Thu, 1 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM : Session2Context naming

  • Key: CORBA26-67
  • Legacy Issue Number: 4204
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Is there any reason to name the context interface for extended session
    components as Session2Context in module Components::Extended? Why not simply
    SessionContext like in the Basic module?

  • Reported: CORBA 2.4.2 — Fri, 16 Feb 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Components FTF: TypeCodeFactory

  • Key: CORBA26-65
  • Legacy Issue Number: 4140
  • Status: closed  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    The third part of the adopted CCM submission (orbos/99-07-03)
    moves all the create_..._tc operations from the ORB interface
    to a new PIDL interface, CORBA::TypeCodeFactory.

    This change breaks source-compatibility: source code that creates
    typecodes with a pre-CORBA 3.0 ORB will need to be updated to use
    a CORBA 3.0 ORB with such a TypeCodeFactory interface.

    And there is no clear benefit from this update:

    • ORB is still PIDL – it even creates an additional PIDL
      interface.
    • type code kinds are not more extensible (TCKind is still an
      enum)

    I suggest to undo this update, i.e. keep the create_..._tc
    operations on the CORBA::ORB interface.

  • Reported: CORBA 2.4.1 — Tue, 9 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Extended Interface Repository

  • Key: CORBA26-63
  • Legacy Issue Number: 4116
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    I am somewhat surprised over the ExtendedIR interface in 00-11-01.
    I am very aware of problems with extensibility in the Interface Repo-
    sitory. In the past, a lot of problems have been caused because modi-
    fications like InterfaceDef::is_abstract have been worked in and out.
    We certainly desperately need a backwards-compatible Interface Repo-
    sitory.

    This is unachievable with version pragmas, because then a client's
    is_a inquiries with "old" Repository Ids will fail, and the client
    will refuse to talk any further.

    Backward compatibility is instead achieved by not changing data types
    (such as InterfaceDescription) and by not changing the signature of
    existing attributes and operations.

    Adding new types that are used by new operations on existing interfaces
    does not break compatibility, because the client will simply be unaware
    that there are more operations than it knows of (such as describe_inter-
    face_2_3).

    Whether changing interfaces sensible is debatable, surely it's more
    consistent to use derived interfaces instead – this has the least im-
    pact on compatiblity.

    In that light, I wonder whether the proposal in 00-11-01 gets us any
    further. It adds more fixed interfaces in another module, and this new
    ExtendedIR module is just as static as the old ones have been. If any
    further changes were necessary, backwards-incompatible changes were
    just as necessary.

    The proposal in 00-11-01 also adds a lot of unnecessary verbose baggage
    with its use of "extended" everywhere, and its usage of multiple inheri-
    tance from the original interfaces is confusing.

    Yet there is one item from 00-11-01 that I like much better than the
    proposal in 99-10-03, and that is the usage of AbstractInterfaceDef and
    LocalInterfaceDef. I think that's the way to go.

    Therefore, I tend to vote against issue 3233 and its proposed resolution
    in 00-11-01.

    Rather, I propose to go back to the original version instead, and

    • to add AbstractInterfaceDef, LocalInterfaceDef and the related
      container operations
    • to add an AttributeWithExceptionsDef and InterfaceDef::create_
      attribute_with_exceptions and ValueDef::* operations.

    Whether the Interface Repository should be moved to a different module
    should be a separate discussion. I support the idea, but I don't think
    that the implementation should be forced to offer access to the IFR
    using both the CORBA:: and IR:: modules.
    Note that vendors could still offer the old interfaces in their imple-
    mentation.

  • Reported: CORBA 2.4.1 — Tue, 19 Dec 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM : Session2Context and Servants

  • Key: CORBA26-66
  • Legacy Issue Number: 4203
  • Status: closed  
  • Source: Anonymous
  • Summary:

    How to activate servants by only using the Session2Context interface from
    the Extended module? It only offers operations to create references like
    create_ref() and create_ref_from_id() similar to those from the POA but no
    means to activate servants are available in the whole container API!

  • Reported: CORBA 2.4.2 — Fri, 16 Feb 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Component home interface inheritance

  • Key: CORBA26-61
  • Legacy Issue Number: 4080
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    The definition of homes does not permit interface inheritance. It
    appears this is an oversight as the omission seems unreasonable and
    counter-intuitive, especially since homes must follow a parallel
    derivation hierarchy with their component types. I have found cases in
    which a home would expose the same interface as its component in which
    the home subsequently delegates to a specific component instance (even a
    persistent instance) however selected. (The component instance may or
    may not be hidden from the client.) Interfaces are a perfect mechanism
    whereby the operational signatures could be standardized, thus
    eliminating potential errors caused by changing one but not the other.
    This could be accomplished using a supports clause in the inheritance
    specification similar to that of valuetypes.

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

    see below

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

ComponentIR Interface fixes

  • Key: CORBA26-64
  • Legacy Issue Number: 4136
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    While reviewing the ComponentIR interfaces in 00-11-01, I have found
    some problems with it. (These are unrelated to the current discussion
    about the Interface Repository itself.)

    Many interfaces inherit Contained::describe(), which is supposed to
    return information about the element. In the basic IFR, this data is
    designed to contain all possible information about that type. This
    is very convenient, since then a map mapping RepositoryIds to
    Contained::Description contains all of the IFR's information.

    By referring to InterfaceDefs rather than RepositoryIds, the client
    will need to store that association elsewhere, or repeatedly invoke
    the Interface Repository.

    Suggested resolution:

    • In ProvidesDescription, replace
      InterfaceDef interface_type
      with
      RepositoryId interface_type
    • Ditto for UsesDescription
    • In EventDescription, replace
      ValueDef event
      with
      RepositoryId event
    • In ComponentDescription, replace
      ProvidesDefSeq provides_interfaces
      UsesDefSeq uses_interfaces
      EmitsDefSeq emits_events
      PublishesDefSeq publishes_events
      ConsumesDefSeq consumes_events
      with
      ProvidesDescriptionSeq provides_interfaces
      UsesDescriptionSeq uses_interfaces
      EmitsDescriptionSeq emits_events
      PublishesDescriptionSeq publishes_events
      ConsumesDescriptionSeq consumes_events
    • In PrimaryKeyDescription, replace
      ValueDef primary_key
      with
      RepositoryId primary_key
    • In HomeDescription, replace
      PrimaryKeyDef primary_key_def
      FactoryDefSeq factories
      FinderDefSeq finders
      with
      PrimaryKeyDescription primary_key
      OpDescriptionSeq factories
      OpDescriptionSeq finders

    Next, all parts of the "basic" Interface Repository are mutable, but
    most attributes of the Components interfaces are declared as readonly.
    I propose to remove the readonly modifier from

    • ProvidesDef::interface_type
    • UsesDef::interface_type
    • UsesDef::is_multiple
    • EventDef::event
    • ComponentDef::supported_interfaces
    • ComponentDef::base_component
    • ComponentDef::provides_interfaces
    • ComponentDef::uses_interfaces
    • ComponentDef::emits_events
    • ComponentDef::publishes_events
    • ComponentDef::consumes_events
    • PrimaryKeyDef::primary_key
    • HomeDef::base_home
    • HomeDef::managed_component
    • HomeDef::primary_key
    • HomeDef::factories
    • HomeDef::finders

    Last but not least, there seems to be some confusion about Primary Keys.
    When a Home is created with Repository::create_home, a ValueDef should
    be passed, while the terminology seems to dictate a PrimaryKeyDef instead.
    You can get a PrimaryKeyDef using HomeDef::create_primary_key, but that
    would be a chicken-egg scenario.

    Proposed resolution:

    • Change the ValueDef in Repository::create_home to PrimaryKeyDef
    • Move the create_primary_key() operation from HomeDef to Repository
  • Reported: CORBA 2.4.1 — Fri, 5 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Problems with the Components Notification Event Interface

  • Key: CORBA26-62
  • Legacy Issue Number: 4081
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    The CCM standard indicates that all CCM Event functions will delegate to
    the container. Chapter 7 of the CCM Volume 1 further dictates the
    interface the container will provide to the component, called
    Components::Notification::Event, referred to as the "Event Interface"
    hereafter. This interface contains many problems and does not address
    all the required functionality. The problems are listed below:<p>

    • The create_channel() method returns an EventConsumerBase for the
      publisher to use to publish events to the channel. It is not possible
      for the Event Interface to construct a concrete EventConsumerBase,
      specifically the interface defined as
      <publishing_component>EventConsumers::
      <event_type>Consumer (per section 5.6.6 and 5.6.7 giving the
      publisher and emitter IDL expansion). The Event::obtain_channel()
      method has the same problem
    • The subscribe() method implies that the container supplying events
      will hold the supplier proxy that will be used to send events to the
      subscriber’s EventConsumerBase. This is an inefficient model. Also,
      this model is in direct conflict with the listen() method, which
      supports a more efficient model (see next bullet).
    • The standard does not provide any documentation on when a consumer
      would call the listen() method. The standard also does not provide a
      means for the consumer’s component to realise the "csmr_name", the
      name used to find the ConsumerAdmin from the Naming Service [see
      possibly related issue #3940]. Nor does the standard indicate when
      the ConsumerAdmin would have ever been added to the Naming Service.
      It might be possible that this would work for emitters, but it does
      not work for publishers (the standard dictates that a consumer cannot
      distinguish between being connected to an emitter or a publisher).
      This method does imply that the consuming component will have a proxy
      local to its container, separate from the publishing component’s
      container (contradictory to the subscribe() method, see previous
      bullet).
    • The push() method does not provide a means to indicate which channel
      the event should be pushed to see possibly related issue #3928.<p>

    The Event Interface is a local interface ­ that is, the client will
    never see this interface, and so it is possible to hide the use of this
    interface inside the generated code and thus replace the interface.
    Internally we have added a PortManager interface to be used in place of
    the Event Interface. This interface provides better management of the
    Event Channels and it also manages receptacle connections. Two
    interfaces will derive from the PortManager, a TransientPortManager and
    a PersistentPortManager. These two derived interfaces will permit
    connections between components to be managed as defined by the type of
    the container. Where meaningful, this permits the port connections to be
    made persistent as part of the overall state so that connections
    (specifically, notification channels) can be more reliably and robustly
    managed. The CCM2Context::get_event() operation is replaced by
    get_port_manager()

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

    See issue 3937. rejected

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

Component assemblies do not follow composition pattern

  • Key: CORBA26-58
  • Legacy Issue Number: 4077
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    I have noticed that assemblies do not follow the composition pattern.
    Thus, assemblies cannot themselves be used as building blocks for other
    assemblies. I think part of this comes from the fact that installation
    and management of assemblies is mostly "magic" done behind the scenes by
    various installation and support utilities. In order to "reuse" an
    existing assembly, one must copy an existing assembly definition (I
    guess constructed completely by hand) to a new definition, which must
    then be tailored to incorporate the new strategy and pieces. This seems
    counter-intuitive, besides being manually intensive, for if an assembly
    does useful work, why would I want to expose its internal details just
    to take advantage of that usefulness? As pointed out by Mr. Dubois in
    issue 3939, because all of that "magic" is not specified by various
    formal interfaces, it is highly likely approaching certainty that
    assemblies will only work for the particular vendor on which they were
    built. Since I believe the intention was to promote interoperability in
    general and as much code automation as possible for components in
    particular, it would seem that we want to restrict the "magic" by taking
    the formalisms behind assemblies to another level.<p>

    I suggest that, just as a <i>composition</i> exists to tie a component,
    its home, and various configuration properties together, we can create
    for the CIDL grammar productions for an <i>assembly</i> to tie multiple
    compositions together. Subsequently, an assembly could be treated as a
    composition, to be used by other assemblies, only exposing selected
    facets or events from its constituent entities. I think there are a
    number of advantages to this approach: (1) It solves certain semantic
    ambiguities with assemblies, for instance whether facets, receptacles,
    and events are private or public to the assembly. (2) The assembly
    implementation, its XML, and its relation to its constituents and home,
    can be generated automatically from the CIDL description [we have been
    working on this extensively]. Our approach is to use an assembly
    exactly like a composition, as the realization of a component and home
    definition. Our research efforts imply that all of the assembly
    component and home code can be automatically generated - no user
    tailoring will be needed. (3) Because the assembly now acts as a
    component (composition), it can be reused by other assemblies without
    knowledge of its internal structure. (4) Activation of an assembly
    appears the same as for any other component; it merely requires formal
    specification of previously undefined interfaces to accomplish it, thus
    promoting portability and interoperability. (5) The assembly
    "deployment magic" becomes exposed through the interfaces above, thus
    removing several of the deployment tools and servers/services identified
    in the specification. The only real drawbacks I see are the complexity of the assembly
    productions (we can really get out of control with this) and that
    assemblies now have an actual code base rather than being "magical
    creatures" managed by the deployment tools. I guess these are both
    two-edged swords. There might be a run-time footprint change for all of
    these extra interfaces, but those had to be lying around in other places
    anyway.

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

    rejected

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

Component assembly templates

  • Key: CORBA26-59
  • Legacy Issue Number: 4078
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    In a complex distributed environment, the implementation of highly
    available and highly reliable services requires redundant placement of
    software components in all their manifestations. Assemblies provide a
    nice, convenient way of specifying the deployment and activation of
    components and the connections that relate them for a particular
    purpose. Now, for various reasons and Fault Tolerant CORBA
    notwithstanding, in corporate reality this sequence and specification
    will occur in multiple places in basically identical fashion. About the
    only thing that changes are the host names and their network addresses;
    everything else from the hardware configuration to the size of the disk
    drives and file systems is (and inherently must be) exactly the same
    among all deployments. This, for example, is one technique to support
    geographic site failover.

    My question is, has anyone thought of a two or more stage XML process,
    one in which the package or assembly composition and deployment XML is
    specified as a template or configurable, parameterized entity, and
    another where the parameters have been substituted for "finalization"?
    This can occur at two distinct points in the life-cycle: one set of
    substitutions occurring when an artifact is deployed (installed?) on the
    various computer systems involved, and another when the home [and
    possibly individual instances] of the artifacts are activated
    (instantiated?) to run on those computer systems. My work in the
    telecom and defense industries has show that deployment of anything is
    rarely a singleton event; there are always redundancies, replications,
    and backups to take into account. Templates seem to provide a nice
    solution to all of the manual editing required.

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

    rejected

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

Component home polymorphism

  • Key: CORBA26-60
  • Legacy Issue Number: 4079
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    See the CORBA Component Specification, orbos/99-07-01, and Persistent
    State Service issue #4074. Is there any reason why homes cannot support
    (manage) multiple component types? This seems like a perfect case for
    polymorphism; the only time you really need a new home type is when you
    change the behavior or have some other incompatibility. Is it possible
    to do instances of homes, one per component type (perhaps instances of
    components acting as managers for other components)? I simply do not
    understand why these are one-to-one with parallel but distinct
    derivations. I realize the requirements were to maximize code
    generation, but I don't see that this is a conflict.

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

    rejected

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

Inter-component type semantics unclear

  • Key: CORBA26-57
  • Legacy Issue Number: 4075
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    The semantics of components of a particular type (session, entity)
    residing in a compatible container type that access components of a
    different type residing in a corresponding but different compatible
    container type are unclear. Are there any expected or preferred
    combinations? Are any disallowed or discouraged? See, for example, the
    discussion under issue 4025 on automated recovery. In his replies, Mr.
    Dubois seems to assume that entity components create transient (service
    or session) components but not the reverse. In the telecommunications
    domain, however, a session object may share access to an entity, and
    then create additional entities based on external events, even though
    the session itself is not persistent. Could someone please articulate
    the possibilities and their utility (or lack thereof)?

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

    rejected

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

New component issue: connection failure recovery

  • Key: CORBA26-55
  • Legacy Issue Number: 4025
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The CCM does not describe the behavior of the system in case of various fault situations. In particular, this issue only concerns itself with the recovery mechanisms of event subscriptions or facet receptacles that were automatically established through an assembly. While it is outside the scope of the CCM to describe general fault behavior, it is felt that recovery mechanisms (or their absence) should be explicitly identified for connections automatically built between ports. Otherwise, why go to the trouble of building them, since error detection and recovery wrappers would be needed around any use of them?

    The following scenario highlights the various situations. It assumes that the components are deployed in separate processes on different platforms so that one of the two components remains operational despite failure or inaccessibility of the other. The scenario primarily deals with the recovery of an interface provided by Component X and used by Component Y. Appropriate questions related to event channels are also given where applicable. Event channels are themselves more difficult because the notification services adds yet another object to the set that may fail during the scenario.

    Scenario: Component X declares that it provides an interface A. Likewise, Component Y declares that it uses interface A. (Or, X emits or publishes event A to which Y subscribes.) Instances of the components are combined through an assembly. Now, the assembly description indicates that a connection is to be built between X and Y. That is, the descriptor defines connections in which a connection element defines the association. Said element’s providesport acquires X’s facet A and assigns that through the usesport to Y’s interface receptacle. (For events, read these as emitsport or publishesport and subscribesport.)

    The following questions arise:

    When does the connection take place, during assembly construction or on reference to the port’s receptacle inside Y? That is, is this immediate or lazy initialization? When are event channels created or attached? Can the producer delay creation or attachment until a push() operation? Can the consumer accomplish the creation? Can an m:n emitter to consumer notification matrix be built? (The specification is unclear on this.)
    What happens if the interface reference to A cannot be acquired because (1) X has failed or is inaccessible, (2) X fails during the get operation, or (3) X returns a nil reference?
    What happens during run-time when Y invokes an operation on A and:
    The application server process containing X has terminated (COMM_FAILURE returned)?
    Derived valuetype arguments cannot be marshalled (MARSHALL/BAD_PARAM returned)?
    The underlying object supporting A in X has been deleted (INV_OBJREF returned)?
    An unexpected application error occurs (UNKNOWN returned)?
    With respect to error detection and recovery:
    How does one indicate the set of objects that can detect the error? Possible objects are Y, Y’s home, Y’s container, X’s container, X’s home, the assembly, an independent third party.
    How does one indicate the set of objects that can recover the error?
    How does one indicate whether the error should be detected?
    How does one indicate whether recovery should be attempted?
    How does one indicate the recovery strategy, especially if there are several objects that can recover the error?
    If the strategy has multiple fallback conditions, should this logic be placed into a single object or should it be given as a precedence-ordered list?
    Where should this information be specified: IDL, CIDL, or XML?
    What are the implications when the components have different type and container semantics?
    Let component X be transient and component Y be an entity. If component X fails, can a new X be safely created for its corresponding Y?
    Assume a new X was created and the old X still exists but became inaccessible. Can the old X be detected and one of the X’s be deleted [dismissed] after the old X is again accessible?
    Assume a request to X completes successfully in X but fails during the reply to Y. Can the operation be retried or the previous results retransmitted, either on the old X after recovery or on a new X?
    In these questions, what happens if X is an entity and Y is transient?
    In these questions, what happens if Y aborts rather than X?

    Ideally, it would be nice if either the IDL extensions or the CIDL constructions permitted specification of an error recovery wrapper around access to a receptacle (or event channel). This could actually work as a general mechanism for any component and not just components grouped in an assembly. The wrapper would be a specialized object implemented specifically in the context of the component or assembly that provided the desired error detection and recovery behavior. It would be a proxy similar to a stub: it would have the same interface as the target object to which it delegates. Errors would be caught (as described) and recovered automatically, if possible. This includes the initial reference to an object, which would now be built or acquired dynamically at run-time rather than semi-statically at assembly instantiation. Multiple inheritance, in languages that support it, would be very useful in standardizing proxy behavior. The component DTD could be used to specify desirable run-time operation and associated characteristics.

  • Reported: CORBA 2.4.1 — Tue, 7 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

Components, Facets, and Object References Unclear

  • Key: CORBA26-56
  • Legacy Issue Number: 4073
  • Status: closed  
  • Source: Anonymous
  • Summary:

    See the CORBA Components specification, orbos/99-07-01, chapters 5, 6,
    7, and 9. The semantics, life cycle, and mechanisms behind components,
    facets, "regular" objects, and their related object references is weakly
    specified. In particular, it is not clear how a component interacts
    with a container to generate an object reference to a facet, especially
    a facet in a secondary segment. The description of component
    identifiers indicates that the component object id, the facet number,
    and the segment number are used to generate the facet's object reference
    (or perhaps only the ObjectId), but the sequence of operations is not
    given. It appears that not all the necessary methods have been formally
    specified, nor are the code generation examples adequate for this
    siutation.

    Consider the following IDL:

    interface A {};
    component C

    { provides A a_facet; A get_another_A(); }

    ;

    What is the life-cycle of the A object returned as the provided facet?
    Is it limited to the life-cycle of the component? Is the member
    operation returning an object of the same type as a provided facet
    permitted? Should this return the same object as the facet? If not, is
    the life-cycle of this extra object limited to the life-cycle of the
    component? Should such objects be considered facets, even if not
    explicitly declared such (which, please note, provides the equivalent of
    the deprecated "provides multiple" capability)? What information needs
    to be encoded in its object reference, especially for component
    dependency? How will the context for this be established, and are any
    additional interfaces or operations required to accomplish this?

  • Reported: CORBA 2.4.1 — Tue, 21 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

grammar rule for home_executor_body contradicts description

  • Key: CORBA26-53
  • Legacy Issue Number: 4011
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In ptc/99-10-04 on page 15 the grammar rule of home_executor_body in chapter
    60.7 "Home Executor Definition" contains bars implying alternatives. These
    bars have to be removed to match the subsequent description.

  • Reported: CORBA 2.4 — Wed, 1 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Typo in assembly element paragraph heading

  • Key: CORBA26-54
  • Legacy Issue Number: 4024
  • Status: closed  
  • Source: Anonymous
  • Summary:

    See the CORBA Components Model specification, orbos/99-07-01, paragraph
    10.6.2.52, page 10-365. See also the DTD appendices document, orbos/99-08-05.

    The title of this paragraph heading is incorrect. The element is "usesport",
    not "usingcomponent". It has occasionally been hard to find the description
    because of this textual error.

  • Reported: CORBA 2.4.1 — Tue, 7 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

No Access to event filter form component

  • Key: CORBA26-52
  • Legacy Issue Number: 3998
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    As the CCM spec is not giving any mean (or very little) to fill in the
    filterable body part, no services are provided for a component to set its
    event filters when sending or receiving events.

    This seems to be a very usefull service to me for application such as:

    • limiting the number of events emitted by a component based on a config
      parameter (like messages with priority > config value can go out, other are
      discarded. when the config value change at runtime the filter could also
      change.
    • filtering events received from a notification channel.

    I agree that these 2 function could be achieve by user code in the component
    but it means that unecessary events are passed between components and the
    netwok load and CPU load is higher than necessary.

    I guess the point I am trying to make is that using the notification service
    without using filters and/or filterable body doesn't seem to make a lot of
    sense.

    What is the intend of the sepc on this issue?

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

    See issue 3938. rejected

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

No user access to filterable body in CCM spec.

  • Key: CORBA26-51
  • Legacy Issue Number: 3997
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    The CCM spec seems to have make the choice to prevent the component
    implementor to fill in the filterable body part of a structured event sent
    to the a notification channel.

    What are the reasons of this choice?

    2 remarks:

    • The filtrable body part of a structured event seems to be the most usefull
      part of the event. Not using it (or leaving it to the container to fill in
      from obscure sources) doesn't seem to make a lot of sense.
    • Other standard bodies (like T1M1.5) are using the filterable body part of
      the event and are making the remainder of the boby (where the EventBase
      derived value type should be put) optional and unnecessary.

    Any comment/explanation of the choice is welcome.

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

    See issue 3938. rejected

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

CCM Events issue

  • Key: CORBA26-49
  • Legacy Issue Number: 3993
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I was researching the CCM Event Corba 3 to Corba 2.3 mappings in
    chapter 5 of Volume I, and found that the resulting interfaces did not
    permit a consumer to subscribe to a publisher because the interface
    type returned by the get_consumer_<name>() does not match the
    subscribe_<name)() parameter. I am not sure if I made a mistake when
    mapping the 3.0 to 2.3 idl or if it is a problem in the standard. I
    also provide an alternative that might work, though I'm sure it will
    need some work.

  • Reported: CORBA 2.4 — Tue, 24 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    Resolved by reference/clarification to 3746

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

IDL question concerning CCM

  • Key: CORBA26-50
  • Legacy Issue Number: 3996
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I have the following question (problem). The Corba Component Model Spec
    (volume 1) defines the following :
    module CORBA_3 {
    module Components {
    interface Events

    { ... }

    ;
    ...
    module Events

    { ... }

    ;
    };
    };

    So the word 'Events' is used for defining an interface and a module!! Is
    this correct IDL, because ther JavaORB idl-compiler nor the ORBACUS
    idl-compiler is able to compile such idl.

  • Reported: CORBA 2.4 — Sat, 21 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

repository element needed by softpkg DTD

  • Key: CORBA26-47
  • Legacy Issue Number: 3986
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    in 99-08-05 the softpkg DTD is missing the "repository" element
    specification. It could be copied from corbacomponent DTD.

    <!ELEMENT repository
    ( ins

    objref
    link
    ) >
    <!ATTLIST repository
    type CDATA #IMPLIED >
  • Reported: CORBA 2.4 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

typo in connections element definition

  • Key: CORBA26-48
  • Legacy Issue Number: 3987
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    in 99-08-05 the componentassembly DTD has a typo in the "connections"
    element definition. "connecthome" should be spelled "connecthomes"

    <!ELEMENT connections
    ( connectinterface

    connectevent
    connecthomes
    extension
    )* >
  • Reported: CORBA 2.4 — Tue, 24 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

description element need to be added to corbacomponent.dtd

  • Key: CORBA26-46
  • Legacy Issue Number: 3985
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    in 99-08-05, the corbacomponent DTD is missing the "description" element
    specification. It should be the same as the other DTDs and can be copied
    from them

    <!ELEMENT description ( #PCDATA ) >

  • Reported: CORBA 2.4 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Deployment Object Life Cycles

  • Key: CORBA26-45
  • Legacy Issue Number: 3982
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The description of the life cycle and system dynamics of the various
    objects that contribute to component deployment and execution is
    incomplete. From an implementation perspective, there are many run-time
    objects involved that contribute to, or are required for, the overall
    operation of a component. But the CCM does not adequately show the
    interrelationships among such objects. Even the most rudimentary
    implementation depends on the assumptions hidden behind these
    interrelationships.

    The following questions need to be addressed in order to build a
    portable implementation:

    1. Deployment support services:

    • What is the life cycle of the support services needed to create an
      Assembly object?
    • Do these already need to be executing in, known to, or exposed by one
      or more servers?
    • How are these services contacted in a dynamic environment?
    • Is this structure equivalent to the TINA DPE concepts?
    • What is the life cycle of the Assembly object itself?
    • When and how is an Assembly object deleted?

    2. Application servers, containers, homes, components:

    • What is the exact life cycle of these various objects?
    • The specification identifies how component instances are created. How
      are they deleted?
    • When and how is a home removed from a container?
    • When and how is a container removed from an application server?
    • When and how is an application server terminated?

    3. Related or referenced objects:

    • What is the life cycle of event channels?
    • Does the life cycle of objects vary if they are "private" to an
      assembly?
    • When and how are event subscriptions released from their publisher or
      emitter?
    • When and how are objects "registered" with the naming service or
      trader unregistered?

    A full and representative life cycle description of the run-time objects
    denoted above is necessary to understand the dynamic system model and
    its inherent limitations. This will be critical for systems that must
    exhibit very high reliability and availability. There appear to be many
    assumptions, particularly with respect to the deployment tools, that
    affect recovery operations from fault conditions. These must all be made
    explicit. Thus, the CCM description should include a comprehensive state
    transition model. This may be documented as cooperating or nested state
    machines for the various pieces.

  • Reported: CORBA 2.4 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Services available for a basic container

  • Key: CORBA26-44
  • Legacy Issue Number: 3977
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The CCM describes the services available for a basic container as being
    one of two sets: security, transactions, and naming or security,
    transactions, and persistence. Could someone please describe the exact
    services available to basic containers and the particular semantics for
    each? Are these differences related to one set for the component home
    and the second set for the instance?

  • Reported: CORBA 2.4 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

push() versus push_event()

  • Key: CORBA26-43
  • Legacy Issue Number: 3955
  • Status: closed  
  • Source: Anonymous
  • Summary:

    See the CORBA Components Model specification, orbos/99-07-01, section
    5.6, pages 5-84 through 5-89, approximately.
    Could someone clarify the push() and push_event() operations, their
    purposes, and their interaction, if any. There is no description
    whatsoever of the relationship between the push() and push_event()
    operations, even though push_event() is declared in the
    inherited Components::EventConsumerBase. The producing component
    invokes its push() operation, which then performs any peculiar
    formatting to the event before transmission to the underlying channel
    through its container. It is unclear when, if ever, the push_event()
    operation will be invoked. A text search of the document reveals the
    operation appears only in the interface definition and its immediate
    descriptive paragraphs.

    Would a better model be to use push_event() as the interface to and from
    the container? (Perhaps this should be independent operations,
    produce_event() and consume_event()?) On the producer side, let push()
    perform any component specific formatting of the event before passing
    the [now modified] event on to push_event(). This latter interacts with
    the container to send the event to the event channel, as
    described. (Most push() implementations will do nothing to the event.
    This could be provided as a default generated implementation.) On the
    consumer side, push_event() will be invoked by the container as part of
    event delivery. The push_event() operation performs type checks, as
    described, before it invokes the consumer agent’s push() operation. This
    process correctly handles the semantics and permits suitable places to
    intercept or override event processing.

  • Reported: CORBA 2.4 — Mon, 16 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

equivalent interfaces issue

  • Key: CORBA26-42
  • Legacy Issue Number: 3954
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The equivalent interfaces as described within the document result in type mismatches when code is built to implement the functions generated from the CIDL component specification. That is, you cannot assign a consumer to a subscriber because the interfaces are parallel derivations and not an inheritance compatible derivations. The code prototypes must be changed to overcome this problem. We have tried three different approaches, but the one that seems to work best has the most impact to the IDL revisions.

  • Reported: CORBA 2.4 — Mon, 16 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    Resolved by reference/clarification to 3746/ duplicate

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

An assembly is always mono-vendor ???

  • Key: CORBA26-41
  • Legacy Issue Number: 3939
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    Because the interfaces between the Assembly and the
    container/componentServer/servantActivator is not defined, these ones have
    to be vendor specific.

    Because the ExecutorSegmentBase and the HomeExecutorBase are not specified a
    component is always container specific.

    As a result an assembly provided by one vendor can only speak to
    container/componentServer/servantActivator provided by the same vendor and
    the container can only run (even in Java???) components that have
    specifically ported to it.

    The conclusion is that it is not possble to build an asembly that combine
    components build on different CCM platform. All of the component have to be
    ported to a single CCM platform.

    Is it what is intended?

  • Reported: CORBA 2.4 — Thu, 5 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Intent of Components::Events::(un)subscribe to bypass the notif. service ?

  • Key: CORBA26-40
  • Legacy Issue Number: 3938
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    a component wants to publish an event. So, it calls
    Components::Notification::Event::create_channel(). The container contact the
    (remote) Notification service, create a dedicated channel, connect to it and
    return an EventConsumerBase to be used by the component to push any event to
    the channel. Each time the push() method is called on the EventConsumerBase
    it will create a structured_event and push it to the notification channel.

    Now, another component (in another container/memory space/system) wants to
    receive these events. So it calls Components::Event::subscribe() on the
    first component passing a reference to an EventConsumerBase. The component
    internally calls Components::Notification::Event::subscribe() passing the
    remote EventConsumerBase reference. So now the container has to create a
    (local) strutured_push_consumer and connect it to the channel it has
    created. By doing this any event that it send to the channel will be bounced
    back to it so that it can then push them to the (remote) EventConsumerBase
    that have subscribed to the publish port.

    This scenario doesn't seem right to me because the notification service is
    then useless as all events are bounced back to the publisher. The container
    could just call the push() method on each registered EventConsumerBase.

    What seems to be really needed is a way to pass the reference to the
    NotificationAdmin back to the second component so that the second component
    can then subscribe through its own container to the Notification channel.

    Another possiblity would be that the subscribe call accept a (remote)
    strutured_push_consumer as parameter instead of the EventConsumerBase.

    The last solution is that the publisher port is not designed to work with
    the notification service but on its own.

    I am certaimly missing something!!!!!

    Could you explain how it is supposed to work?

  • Reported: CORBA 2.4 — Thu, 5 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected, see above

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

Channel Setup for Emits ports.

  • Key: CORBA26-39
  • Legacy Issue Number: 3937
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    I found 2 (possibly) contradictory statement in 99-10-04 for "emits" ports.

    1) in 62.4.1.2 The Event Interface

    EventConsumerBase obtain_channel (in string supp_name, in EventHeader hdr)
    raises (InvalidName);

    The obtain_channel operation is used by the component to obtain an
    EventConsumerBase which it can use to push events. This operation
    corresponds to an emits declaration in component IDL. The supp_name string
    identifies an Interoperable Naming Service (INS) name which is used to
    identify the SupplierAdmin to be used by CORBA notification. The name is
    associated with the SupplierAdmin thorough container specific configuration
    data. The obtain_channel operation may optionally specify the EventHeader
    required by CORBA notification which will be used for all events pushed to
    this channel. If hdr is present, it is prefixed to all events pushed to this
    channel. If not, it is defaulted as described in Section 66.4, "Event
    Management Integration," on page 66-252. If the supp_name is not recognized,
    the InvalidName exception shall be raised.

    2) in 66.4.2 Transmitting an event

    . channel lookup - for emitted events, this is the channel configured for
    general use at container start-up, for published events, this is the channel
    established by the container for the purpose of pushing this event type.

    Section 62.4.1.2 seems to imply that there can be a different event channels
    for each emit port while 66.4.2 seems to imply that there is only one event
    channel shared by all emits ports.

    What means "general use"?

    What is the truth/intent?.

    Could you make things clear?

    I certainly preffer 1)

  • Reported: CORBA 2.4 — Thu, 5 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

ExecutablePlacement definition

  • Key: CORBA26-37
  • Legacy Issue Number: 3929
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    In the componentAssembly DTD the executablePlacement is defined as follow:

    <!ELEMENT executableplacement
    ( usagename?
    , componentfileref
    , componentimplref
    , invocation?
    , destination?
    , extension*
    )>
    <!ATTLIST executableplacement
    id ID #REQUIRED
    cardinality CDATA "1" >

    It seems to me that the DTD should not enforce the componentimplref as this
    might depend on the deployment And there is no reason the assembler should
    know where the executable is going to be deployed. For example the
    componentimplref should be different between a Solaris, a Linux or an NT
    placement.

    Therefore I would propose to make componentimplref optional (as it is in
    homePlacement) and change the executablePlacement definition to:

    <!ELEMENT executableplacement
    ( usagename?
    , componentfileref
    , componentimplref?
    , invocation?
    , destination?
    , extension*
    )>
    <!ATTLIST executableplacement
    id ID #REQUIRED
    cardinality CDATA "1" >

  • Reported: CORBA 2.4 — Tue, 3 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

exception raised by Components::Events::subscribe()

  • Key: CORBA26-38
  • Legacy Issue Number: 3930
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    The exception raised by Components::Events::subscribe() doesn't include the
    Components::ExceededConnectionLimit exception raised by the
    subscribe_source_name() 2.3 equivalent interface.

    It should be added.

  • Reported: CORBA 2.4 — Tue, 3 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Local push() operation.

  • Key: CORBA26-36
  • Legacy Issue Number: 3928
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    When the component implementor wants to emits an event it has to use the
    push() operation from the local Event interface.

    It is not clear how the container will manage to discriminate the event and
    select the channel this event need to be send to.

    Nothing prevent a component to define several publisher and several emitters
    and nothing force the events to be of different types on all of these
    channels.

    So either the spec is not clear enough on this process or the local push
    method is missing some a parameter (like the emitter/publisher port name) to
    help the container do his job.

  • Reported: CORBA 2.4 — Tue, 3 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

Incomplete grammar in section 15.3.4.8

  • Key: CORBA26-92
  • Legacy Issue Number: 4339
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    In orbrev/01-03-01:

    Production rule two at the end of this sections has a comment that it
    should include all IDL types, but in actuality is missing "long long",
    unsigned long long" and "long double".

    Suggest we add these to the production rule in question.

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

    No Data Available

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

Question about corbaname URL

  • Key: CORBA26-93
  • Legacy Issue Number: 4342
  • Status: closed  
  • Source: Raytheon ( Craig Rodrigues)
  • Summary:

    I have an interoperability question regarding the
    corbaname URL in the CORBA 2.4.2 specification and would appreciate
    clarification.

    In 13.6.7.3, it states that for a corbaloc URL which
    uses IIOP, if the port number of the endpoint is
    not specified, then the IIOP profile should default
    to port 2809 which is specified by IANA as the corbaloc
    port.
    eg.
    corbaloc:iiop:myhost.com/SomeKey

    In 13.6.7.5, the corbaname URL is described.
    If a corbaname URL is specified for IIOP, but the port
    number is omitted, should the ORB assume that the
    root naming context will be on port 2809 of the host
    specified?

    eg.
    corbaname:iiop:myhost.com:3000#path/obj

    will look for the root naming context on port
    3000 of myhost.com.

    eg.
    corbaname:iiop:myhost.com#path/obj

    Should this look to port 2809 for the root
    naming context?

  • Reported: CORBA 2.4.2 — Fri, 8 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above

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

Indirections with chunking & fragmentation

  • Key: CORBA26-91
  • Legacy Issue Number: 4328
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    When chunking and fragmenting, it is possible for a chunk length to be
    inserted between the indirection tag and indirection offset.
    Implementations must be careful to compute the indirection offset
    correctly both when writing and reading to avoid errors.

    For interoperability, we should elminate this possibility. From an
    implementation point of view, the code for handling this special case
    should already be there. Please see the original message (see
    attachment) for a detailed description of the problem scenario and two
    implementation possibilities.

    Proposed resolution:

    Elminate the possibility of chunk lengths between indirection tag and
    indirection offset by changing the following paragraph in CORBA formal
    00-11-03 15.3.4.6.

  • Reported: CORBA 2.4.2 — Fri, 25 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

GIOP issue : fragmented replies with exceptions

  • Key: CORBA26-90
  • Legacy Issue Number: 4289
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    Let us assume that the server has sent a few reply fragments. But before sending all the reply
    fragments, an exception occurs (say while marshalling the response).
    What does the server and the client (which has already seen reply fragments) do ?

    Just to note, notice that if the same problem happens while the client is in the midst of sending
    request fragments, the client can choose to send a CancelRequest message to intimate the server.

    Since there are various possible behaviours for the client and server, the GIOP specification needs
    to clarify the standard behaviour, in order for different implementations to remain interoperable.

    One possible behaviour :

    The server could send back a seperate response (containing the exception with
    CompletionStatus.COMPLETED_YES). The client on receipt of the new reply, and noticing the fact that
    another reply with the same requestId is pending, could discard the pending reply and process the
    latest reply.

    Another behaviour :

    The client could simply timeout the request and discard any new reply streams (with the same
    requestId), and raise an exception with CompletionStatus.COMPLETED_MAYBE.

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

    This issue is resolved by the resolution to issue 4273.

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

GIOP is silent about extra data in the Request or Reply body

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

    The specification does not say whether extra data after the invocation
    parameters in a Request or Reply body is ignored or considered an
    error. For interoperability purposes, the spec should require one or
    the other.

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

    see below

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

In RMI rep Id, when is inclusion of SUID legal?

  • Key: CORBA26-89
  • Legacy Issue Number: 4280
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    In formal 00-11-03 10.6.2 in the discussion of the serial version UID in
    the RMI hashed format, the spec defines the repository ID format as

    RMI: <class name> : <hash code> [ : <serialization version UID> ]

    and says

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

    The Java to IDL spec ptc-00-01-06 1.3.5.7 says

    "The syntax of the repository ID is the standard OMG RMI Hashed format,
    with an initial “RMI:” followed by the Java class name, followed by a
    hash code string, followed optionally by a serialization version UID
    string."

    Questions:

    1) Is it legal to include the serial version UID in the repository ID
    even when it is equal to the hash code? (Alternatively: Is it legal
    for an ORB to throw an exception/fail if the hash code and serial
    version UID in the repository Id are the same?)

    2) If it is not legal to include the serial Version UID in the
    repository ID when equal to the hash code, what should an ORB do?

    Discussion:

    Other than it not harming anything to include the SUID, there are rare
    cases that the same Java class compiled with different compilers can
    result in different default serial version UIDs, so it would be wise to
    explicitly specify the serialVersionUID field even in the first version
    of a class. If it is legal to always include the serial version UID
    part of the repository ID, ORBs with classes from two different
    compilers would still be able to interoperate.

  • Reported: CORBA 2.4.2 — Mon, 23 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

simple ELEMENT definition

  • Key: CORBA26-35
  • Legacy Issue Number: 3926
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    I have a question about the property.dtd file provided with the CCM spec.

    in this file "simple" is described as follow:

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , defaultvalue?
    ) >

    This seems to indicate that a "simple" element has to have a value in the
    file. Therefore it is not clear how usefull is the optional "defaultvalue"
    field. It also means that if the component or assembly provider wants to
    provide the CPF files with the CCD and CAD files it has to put values into
    them instead of just setting the default value. Obviously the best thing to
    do would be to repeat the default value into the value but it seems strange
    to me. The point is that if there is a default value provided the value
    doesn't seem to be mandatory.

    Also, in a way similar to the CAD file, where placement information are
    added at deployment time, we may want to enable the component/assembly
    provider to provide CPF skeleton files together with the CCD files and
    skeleton CAD files. In this case the "simple" element may not contain any
    "value".

    I propose to replace this definition with:

    <!ELEMENT simple
    ( description?
    , value?
    , choices?
    , defaultvalue?
    ) >

    Any thought

  • Reported: CORBA 2.4 — Mon, 2 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

range description in CPF files.

  • Key: CORBA26-34
  • Legacy Issue Number: 3925
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    The definition for "choices" is as follow in the properties.dtd file:

    <!ELEMENT choice ( #PCDATA ) >
    <!ELEMENT choices ( choice+ )

    knowing that the PCDATA for choice is supposed to hold one possible value
    for the "simple" if I am right

    I believe this is missing a bit of descriptive power. In case you want to
    specify a range of 100 values you will have to give the 100 different values
    each in its own "choice" element. It is very verbose !!!

    We could add a range ELEMENT to the DTD as follow:

    <!ELEMENT range (value, value)>

    We could then change the choices ELEMENT as follow:

    <!ELEMENT choices ( range | choice )+>

    Any thought.

  • Reported: CORBA 2.4 — Mon, 2 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Incorrect text in 15.4.6.2

  • Key: CORBA25-51
  • Legacy Issue Number: 4309
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    15.4.6.2, "LocateReplyBody" says:

    In GIOP version 1.0 and 1.1, Locate reply bodies are marshaled into
    the CDR encapsulation of the containing Message immediately following
    the Reply Header. In GIOP version 1.2, the Reply Body is always
    aligned on an 8-octet boundary. The fact that GIOP specifies the
    maximum alignment for any primitive type is 8 guarantees that
    the ReplyBody will not require remarshaling if the Locate Reply
    Header are modified.

    The final sentence doesn't make sense because the LocateReply header is
    a fixed-length header and therefore can't possibly cause remarshalling.

    I suggest to delete the final sentence of this para.

  • Reported: CORBA 2.4.2 — Wed, 16 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see resolution of Urgent Issue 4314

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

GIOP 1.1 Fragment problem

  • Key: CORBA25-50
  • Legacy Issue Number: 4299
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There is nothing in the specification that explicitly states whether the
    data in the body of a GIOP 1.1 Fragment message is marshalled relative
    to the Fragment header or relative to the unfragmented message as a
    whole.

    The restriction in GIOP 1.2 that all fragments but the last must have a
    multiple of 8 bytes, and the careful padding of the GIOP 1.2 Fragment
    header to 16 bytes both strongly suggest that GIOP 1.1 fragments should
    be marshalled only relative to the fragment header.

    Proposed Resolution:

    In section 15.4.9, right after the paragraph that reads:

    "A primitive data type of 8 bytes or smaller should never be broken
    across two
    fragments."

    add the following paragraph:

    In GIOP 1.1, the data in a fragment is marshalled with alignment
    relative to its position in the fragment, not relative to its position
    in the whole unfragmented message.

  • Reported: CORBA 2.4.2 — Fri, 11 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Accept proposal above

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

Urgent issue: Alignment of LocateReply body

  • Key: CORBA25-53
  • Legacy Issue Number: 4314
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    In CORBA 2.3, a GIOP 1.2 LocateReply message made no requirements as to
    the alignment of the LocateReply body. This meant that the LocateReply
    body needed to be aligned only on a 4-byte boundary. With the resolution
    for issue 2521, published with CORBA 2.4, the spec was changed to require
    alignment of the LocateReply body on an 8-byte boundary.

    The change is incompatible with the CORBA 2.3 definition because the receiver
    must know where to look for the ReplyBody in the the byte stream following
    the message header. (The LocateReply header is 12 bytes long, so changing
    the alignment rules means that the LocateReply body has to start at offset 12
    for CORBA 2.3, but has to start at offset 16 for CORBA 2.4.)

    The change in alignment did not result in a version change of GIOP,
    despite the incompatibility, so it appears that the change is simply illegal.

    There are already deployed products that use the CORBA 2.3 alignment
    rule; therefore, we cannot deploy a CORBA 2.4 compliant product without
    breaking interoperability with already deployed CORBA 2.3 compliant products.

    So, I'd like to request that we back out the change and continue to
    permit a LocateReply body to be aligned on a 4-byte boundary. There was
    never any need to change the alignment of the LocateReply body anyway because
    a LocateReply header has fixed length and, therefore, cannot ever cause
    remarshaling of the body due to a size change in the header. In other
    words, the motivation quoted in the spec for the 8-byte alignment rule
    isn't founded on fact, and the change should never have been made in the first
    place. (See issue 4309 for details.)

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

    No Data Available

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

Incorrect table in section 15.4

  • Key: CORBA25-52
  • Legacy Issue Number: 4311
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The table on page 15-31 (Table 15-3 "GIOP Message Types and Originators")
    is in error. For CloseConnection, it shows that only the server can
    send this message but, in GIOP 1.2, either client or server can send
    the message, as detailed in 15.5.1 and 15.4.7.

    Also. in 15.4.7, we have:

    In GIOP version 1.2 both sides of the connection may send
    the CloseConnection message.

    That should be "must", not "may".

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

    see above

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

tk_indirect

  • Key: CORBA25-49
  • Legacy Issue Number: 4294
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    I don't understand why tk_indirect isn't allowed as a top-level typecode.
    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 tk_indirect 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 tk_indirect cannot refer to any TypeCode outside
    the scope of its enclosing top-level TypeCode. However, I don't think this
    restriction needs to apply to a top-level TypeCode. We have made this
    change experimentally without any adverse effects and we have discovered that
    using tk_indirect for all the top-level foo TypeCodes after the first one can
    speed up some common scenarios by at least a factor of 5 on end-to-end
    measurements. There seems to be no downside to making this change.

    I would therefore like to propose the following change to the section headed
    "Indirection: Recursive and Repeated TypeCodes" within section 15.3.5.1:

    Change the first bullet from:

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

    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.

    If this change finds favour, then we need to work out how it can be brought
    into GIOP without causing problems interoperating with older ORBs that insist
    on the stronger restriction of the current spec. This could perhaps be
    added to the "wish list" for GIOP 1.3.

  • Reported: CORBA 2.4.2 — Fri, 4 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Close this issue and add it to the GIOP wish list

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

Fixed point marshalling

  • Key: CORBA25-46
  • Legacy Issue Number: 4198
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    I have a query about the intended marshalling format for Fixed. Is the
    sending ORB always required to transmit the number of digits specified
    in the IDL, or is it permitted to transmit fewer if there are leading
    zeros?

    Consider transmitting 123.45 as fixed<6,2>. Is the ORB permitted to
    transmit

    12 34 5c

    or must it send the leading zero (plus another zero to pad the first
    octet):

    00 12 34 5c

    In both cases, the receiving ORB knows it is expecting a scale of 2,
    and the sign half-octet tells it where the digits end, so it can
    correctly unmarshal the value as 123.45.

    The discussion of issue 3431 suggests that the first option is not
    permitted, and leading zeros must always be sent. However, the 2.4
    GIOP spec makes no mention of how many digits should be sent. The
    specification should be clarified to either explicitly permit or
    explicitly forbid stripping of leading zeros.

  • Reported: CORBA 2.4.2 — Wed, 7 Feb 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Close with clarification revision

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

Table 15-2 is missing entry for tk_local_interface

  • Key: CORBA25-48
  • Legacy Issue Number: 4242
  • Status: closed  
  • Source: Floorboard Software ( Yvonne Biggar)
  • Summary:

    Add the missing entry with the same information as tk_objref.

  • Reported: CORBA 2.4.2 — Tue, 27 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    add the missing table entry with the same information as tk_objref

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

Null termination of strings

  • Key: CORBA25-45
  • Legacy Issue Number: 4113
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    Section 15.3.2.7 of the CORBA 2.3 spec, which describes the CDR encoding
    of strings, includes the following sentence in the first paragraph:

    "Both the string length and contents include a terminating null."

    It is not clear from this whether exactly one terminating null is required,
    or whether more than one null can be included, with the string being terminated
    by the first null.

    Since IDL strings cannot include nulls (see 3.10.3.2: "OMG IDL defines the string
    type string consisting of all possible 8-bit quantities except null"), any
    additional nulls following the first terminating null cannot be part of the
    string, and it therefore seems reasonable to ignore them.

    Proposed Resolution:

    Change the above sentence in section 15.3.2.7 to:

    "Both the string length and contents include at least one terminating null."

    Also make the same change to the corresponding sentence in the third paragraph
    of section 15.3.2.7 describing GIOP 1.1 wide strings.

  • Reported: CORBA 2.4.1 — Fri, 8 Dec 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    To close with clarification revision

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

GIOP 1.2 AddressingDisposition processing on the client side

  • Key: CORBA25-47
  • Legacy Issue Number: 4213
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    If the server ORB sends back a NEEDS_ADDRESSING_MODE reply to the client indicating the prefered
    addressing disposition, then is the client ORB required to 'cache' the prefered addressing
    disposition per object reference, and use it for further requests to the server ?

  • Reported: CORBA 2.4.2 — Wed, 28 Feb 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    to close without revision

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

Nil return from resolve_initial_references()

  • Key: CORBA25-44
  • Legacy Issue Number: 4532
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The spec doesn't say whether or not resolve_initial_references() is allowed
    to return nil. Clearly, it doesn't make sense for it to do that – we
    should say so in the spec.

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

    see below

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

COBRA problem using pragma prefix for modules

  • Key: CORBA25-41
  • Legacy Issue Number: 4395
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Please have a look at the news article below. Basically, the problem is
    that we don't say in the spec what has to happen if I try to give
    conflicting prefixes/IDs/versions to a module (which can happen if a module
    is reopened).

    My feeling is that we should deal with this the same way as for forward
    declarations, that is, force the compiler to emit a diagnostic. I think
    we should also add a note that this can't be enforced by the compiler
    under all circumstances because of separate compilation.
    > Orbacus distribution contains following IDL file.
    >
    > > #pragma prefix "omg.org"
    > >
    > > module CosNaming
    > > {
    > > typedef string Istring;
    > >
    > > struct NameComponent
    > >

    { > > Istring id; > > Istring kind; > > }

    ;
    > > };
    > >
    > > #pragma prefix "ooc.com"
    > >
    > > module CosNaming
    > >

    { > > typedef string Ostring; > > }

    ;
    >
    > And here the error message of IDL to Visual Basic compiler.
    >
    > orbacusnaming.idl:16(8): Attempt to assign a different prefix
    > to a forward-declared identifier
    > orbacusnaming.idl:3(8): Position of the first identifier definition

    The error message is misleading becuase there is no forward-declared
    identifier here. But the compiler has a point – something strange is
    going on there...

    > I look in the CORBA specification and found that modules do have
    > repository ids.

    Absolutely.

    > > Forward-declared constructs (interfaces, value types, structures,
    > > and unions) must have the same prefix in effect wherever
    > > they appear. Attempts to assign conflicting prefixes
    > > to a forward-declared construct result in a compile-time
    > > diagnostic. For example:
    > [...]
    >
    > And what about reopened modules?

    This part of the spec simply doesn't apply because it talks about
    forward-declared things only.

    > Which repository id do they
    > have if someone use different prefix statements? I think
    > they can have only one because the IFR of CORBA allows only
    > one (if the repository version is equal).

    Yes. The spec isn't really clear on this point. Here is your example
    once more, simplified to the bare bones:

    #pragma prefix "X"
    module M

    { typedef string foo; }

    ;

    #pragma prefix "Y"
    module M

    { typedef string var; }

    ;

    The spec simply does not address this problem, so we have a hole. Thinking
    about it, there are two possible interpretations:

    1) Module M gets a prefix "X" initially. Then, when the prefix
    changes to "Y" and the compiler sees M for the second time,
    it could just ignore the prefix for M because M has the prefix
    "X" already.

    2) The compiler could notice that M previously got prefix "X"
    and then complain when it sees M for the second time because
    it would get a conflicting prefix.

    For forward-declared things, the spec applies the philosophy that
    the prefixes must not change. Seeing that a reopened module is somewhat
    similar to a forward declaration (because the same definition can be seen
    more than once), I'd be inclined to amend the spec to say that the prefix
    for a module must not change.

    For cases where the compiler can actually detect this, we can even force
    a diagnostic. However, as for forward-declared things, this is not always
    detectable by the compiler. In particular, if the reopened module is
    reopened in different source files and the two source files are compiled
    separately, there is no way for the compiler to detect that the module
    is getting a different prefix in each source file. If the generated code
    from the two files is linked into the same binary, you should at least
    get a multiple definition error. But if the code for the two files ends
    up in different executables, there is no way to detect the error at all
    and you will get strange things happening at run time.

    As far as the ORBAcus IDL is concerned, I think it needs fixing. The second
    prefix pragma should be inside the module, to avoid the conflict:

    #pragma prefix "omg.org"

    module CosNaming
    {
    typedef string Istring;

    struct NameComponent

    { Istring id; Istring kind; }

    ;
    };

    module CosNaming

    { #pragma prefix "ooc.com" typedef string Ostring; }

    ;

    > Is my IDL2VB compiler again buggy or the Orbacus IDL file
    > or the CORBA specification not clear?

    Well, a little bit of all three I'll raise an issue with the core RTF.

    > I recently solve all founded bugs in IDL2VB and it compiles now
    > all examples of syntax chapter in CORBA spec and find
    > all errors. CORBA is to difficult for humans...

    That's why we use compilers for IDL instead of humans

  • Reported: CORBA 2.4.2 — Sun, 24 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Clarify as described below

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

Interpretation of time field in UtcT?

  • Key: CORBA25-43
  • Legacy Issue Number: 4468
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    in the absence of an RTF for the time service, I'm sending this to the
    core RTF. (You could argue that this is a core issue anyway, since
    the core depends on the time service for messaging.)

    What is the interpretation of the time and tdf fields in a UtcT?

    The spec shows:

    struct UtcT

    { TimeT time; // 8 octets unsigned long inacclo; // 4 octets unsigned short inacchi; // 2 octets TdfT tdf; // 2 octets // total 16 octets. }

    ;

    For TimeT, the spec says:

    TimeT represents a single time value, which is 64 bits in size, and
    holds the number of 100 nanoseconds that have passed since the base
    time. For absolute time the base is 15 October 1582 00:00.

    For UtcT, the spec says:

    UtcT defines the structure of the time value that is used
    universally in this service. The basic value of time is of type
    TimeT that is held in the time field. Whether a UtcT structure
    is holding a relative or absolute time is determined by its history.
    [...]
    The tdf field holds time zone information. Implementation must
    place the time displacement factor for the local time zone in this
    field whenever they create a UTO.

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

    see below

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

There is no mapping for fixed types in the COM/CORBA mapping

  • Key: CORBA25-42
  • Legacy Issue Number: 4441
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There is no mapping for fixed types in the COM/CORBA mapping. Why has this been omitted? Is there a submission underway?

  • Reported: CORBA 2.4.2 — Tue, 31 Jul 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Close with answers to the qestions raised, as given above under Resolution

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

CORBA 2.4.2 (01-02-01.pdf) 4.2.3.4 shutdown (relevant portion)

  • Key: CORBA25-40
  • Legacy Issue Number: 4392
  • Status: closed  
  • Source: Anonymous
  • Summary:

    CORBA 2.4.2 (01-02-01.pdf) 4.2.3.4 shutdown (relevant portion): "If the wait_for_completion parameter is TRUE, this operation blocks until the shut down is complete. If an application does this in a thread that is currently servicing an invocation, the BAD_INV_ORDER system exception will be raised with the OMG minor code 3, since blocking would result in a deadlock."

    But does this mean that things will be as if the operation has not been called (suggested by the name of the exception raised?), or will they be as if the operation had been called with wait_for_completion FALSE (seems more appropriate)? Or should the implementation decide, and should it just use an appropriate completion code? In this case, is COMPLETION_MAYBE allowed? Letting the implementation decide puts a higher burden on the developer, though, if s/he wants to write portable code, so that developer may decide to just program for the current implementation...

    This question has additional relevance for me because I'm implementing an ORB.

  • Reported: CORBA 2.4.2 — Fri, 29 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Clarify that BAD_INV_ORDER is raised in this case with COMPLETED_NO

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

Wither pseudo-objects?

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

    the terms "pseudo-object", "pseudo-interface", and "PIDL" appear in many
    places in the spec. However, there does not appear to be a definition
    of what these things actually are anywhere in the spec. Now, for many years
    now, I've been telling people that PIDL objects differ from normal ones
    in the following ways:

    • They don't inherit from Object.
    • They can't be invoked via the DII.
    • They don't have definitions in the IFR.
    • They can't be passed as arguments to remote operations
      (except for TypeCode).
    • They may have special mapping rules.

    I know that, once upon a time, when I first wrote these points into a CORBA
    training course, I didn't just make them up – I found them in the spec.
    However, I'm damned if I can find them now. I looked in the 2.0 spec as
    well as the 2.4.2 spec to no avail. Can someone help me out?

    At any rate, we should add the definition somewhere because, write now,
    we have lots of free-floating terms in the spec.

    On a related note, by searching for "pseudo", I found a few places where
    it is stated that "pseudo-objects do not have object references". That
    seems to be wrong. After all, we pass these things across (local) interfaces
    by reference (instead of by value) and, at the language mapping level,
    pseudo-objects have references that are indistinguishable from any other
    reference. We should correct this.

  • Reported: CORBA 2.4.2 — Fri, 29 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

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

Local interface is-a Object?

  • Key: CORBA25-39
  • Legacy Issue Number: 4388
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    For local interfaces, we seem to have internal inconsistencies in the spec.
    For one, it is not clear whether or not a local interface implicitly inherits
    from Object. There is one sentence in the spec that seems to imply that
    there is implicit inheritance from object, on page 3-23 of the 2.5 draft
    (http://doc.omg.org/ptc/1-6-10):

    Any attempt to marshal a local object, such as via an unconstrained
    base interface, as an Object, or as the contents of an any, or to
    pass a local object to ORB::object_to_string, shall result in a
    MARSHAL system exception with OMG minor code 4.

    This implies that I can at least try to pass local object as CORBA::Object,
    which implies that local interfaces do indeed implicitly inherit from Object.

    But then, a bit further down, it says:

    The is_a, get_interface, get_domain_managers, get_policy,
    get_client_policy, set_policy_overrides, get_policy_overrides, and
    validate_connection pseudo-operations, and any DII support
    pseudo-operations, may result in a NO_IMPLEMENT system exception
    with minor code 3 when invoked on a reference to a local object.

    "May result in a NO_IMPLEMENT system exception"? I would suggest "shall"!

    But, more seriously, I can't call is_a() on a local interface. In turn,
    that seems to imply that I can't narrow a local interface either, but
    narrowing is clearly necessary in the presence of inheritance for local
    interfaces.

    It seems that local interfaces must inherit from Object. After all,
    it would be difficult to see, for example, how resolve_initial_references
    can return a reference to the Root POA if it were otherwise... But then,
    if local interfaces do inherit from Object, It doesn't make sense to
    prohibit calling is_a() on them.

    Related to that then is the question of "What is the repository ID of
    a local interface?" Given that they can be narrowed, it would seem that
    they must have repository IDs. (Although, you could argue that narrowing
    is to be achieved via some mechanism other than repository IDs – that
    would also permit is_a() not to be supported and would make narrowing
    an issue that is specific to each language mapping.)

    But the inheritance issue seems serious – if something doesn't inherit
    from Object, I can't return or pass it as an Object, but we are doing
    just that for local objects.

    I think this will require some careful thought. We don't want to find
    ourselves in yet another maze of twisty little passages, all different,
    as we did with pseudo-objects...

  • Reported: CORBA 2.4.2 — Fri, 29 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

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

get_interface() underspecified

  • Key: CORBA25-35
  • Legacy Issue Number: 4335
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the text for get_interface() says:

    An operation on the object reference, get_interface, returns an object
    in the Interface Repository, which provides type information that may
    be useful to a program. See the Interface Repository chapter for a
    definition of operations on the Interface Repository. The
    implementation of this operation may involve contacting the ORB
    that implements the target object.

    This does not say what should happen if I call _get_interface() and

    • the interface repository isn't running,
    • the interface repository is running and can be reached, but
      doesn't contain an entry for the object's interface.

    Looking at the INTF_REPOS exception, we have:

    An ORB raises this exception if it cannot reach the interface
    repository, or some other failure relating to the interface
    repository is detected.

    This would indicate that, if the repository isn't running, the client should
    get INTF_REPOS. However, we have no idea what should happen if the repository
    is in fine shape, but no entry exists for the interface.

    Since an unpopulated interface repository is very much the same thing as
    no interface repository at all, I would like to flag both scenarios as an
    error.

    Proposal: add the following sentence to the end of 4.11.3.22:

    If the interface repository is not available, get_interface() raises
    INTF_REPOS with minor code 1. If the interface repository does not
    contain an entry for the object's (most derived) interface,
    get_interface() raises INTF_REPOS with minor code 2.

    Update the minor code table in 4.11.4 accordingly.

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

    Make the suggested change and the additional change suggested in the archive

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

Missing TypeCode identity

  • Key: CORBA25-37
  • Legacy Issue Number: 4386
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Steve's and my book contains a bit of code that pretty-prints a TypeCode.
    (See page 704ff, in particular, 709-711.) No big deal – just write
    a recursive function that does a depth-first traversal of a TypeCode tree
    and prints things out, except for one thing: recursive types.

    For recursive types, the code has to be careful not to get trapped in
    infinite recursion. In essence, this means that the pretty-printer has to
    remember which TypeCodes it has already seen and end the recursion if it gets
    to a TypeCode that was printed previously. This is where we run into
    problems because there is no legal way to do this:

    • I cannot rely on the repository ID in the TypeCode to determine
      TypeCode identity because the repository ID for structs and
      unions is optional prior to GIOP 1.2, but recursion happens
      via structs and unions. (A GIOP 1.2 implementation may interoperate
      with a GIOP 1.0 or 1.1 implementation and still end up sending
      TypeCodes without repository IDs.)
    • The code in the book uses is_equivalent() to determine whether
      it has seen a TypeCode previously. However, doing this is
      completely illegal (even though it happens to work with most
      ORBs) because:
    • is_equivalent() does not provide object identity.
    • TypeCode is a pseudo-object, and pseudo-objects do
      not inherit from CORBA object. This means that TypeCode
      doesn't even have an is_equivalent() operation that I
      could call.

    So, as far as I can see, there is no compliant way to reliably and portably
    determine TypeCode identity and, as a result, I can't ever reliably parse
    a TypeCode...

    I can see several solutions for this problem, all with different drawbacks:

    1) Add an identity() operation of some kind to TypeCode.

    An ORB that receives a TypeCode would have to make sure that
    it generates a unique ID for each TypeCode. But that's not
    all that easy to implement – in particular, if we have an
    older TypeCode where all the optional bits are missing, we
    can't reliably establish object identity for a TypeCode.
    (Only structural comparison is possible.)

    2) Add an identity() operation to TypeCode, but have the TypeCode's
    identity generated at the sending end instead of the receiving
    end.

    Major drawbacks: the identity would have to large because it
    needs to be globally unique (e.g. a UUID) and it would change
    the marshaling of TypeCodes.

    3) Add is_equivalent() and hash() operations to TypeCode.

    This might break existing ORB implementations because a lot
    of ORBs seem to inherit from Object for TypeCode and other PIDL
    objects, even though they shouldn't.

    4) Make PIDL objects implicitly inherit from CORBA::Object.

    Note that making the repository ID mandatory is impossible because we
    can't legislate for existing GIOP 1.0 or 1.1 implementations...

    On a related note, we seem to have further problems with the idea that
    PIDL objects don't inherit from CORBA::Object. For example, in the C++ mapping,
    pseudo-objects such as TypeCode, ORB, etc. can be passed as Object_ptr
    (for example, to CORBA::is_nil()). This really means that the C++ mapping
    (and possible mappings for other languages) are completely in conflict
    with the core spec...

    My feeling is that option 4 is really the least-intrusive one. But I'm
    not sure that I fully understand all the ramifications of making that change.

  • Reported: CORBA 2.4.2 — Thu, 28 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

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

DII create_request

  • Key: CORBA25-33
  • Legacy Issue Number: 4331
  • Status: closed  
  • Source: Anonymous
  • Summary:

    CORBA 2.4.1 final, Section 7.2.1 (create_request), page 7-7, last
    paragraph reads:

    "If the name of an implicit operation that is not invocable through DII
    is passed to create_request with a "_" prepended, create_request shall
    raise a BAD_PARAM standard system exception".

    This does not specifies the minor code for the exception.

  • Reported: CORBA 2.4.2 — Fri, 1 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

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

Problem with resolution to 4285 and 4306

  • Key: CORBA25-36
  • Legacy Issue Number: 4385
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Please take a look at the resolution of issues 4285 and 4306 in
    > ptc/2001-06-08 - the RTF report that is up for recommendation to adopt
    > at this upcoming meeting, and see if they do not fix these problems.
    > 4285 fixes the BAD_OPERATION problem most definitely. 4306 seems to fix
    > the OBJ_ADAPTER problem too, although slightly differently from how you
    > suggest. If these fixes address the problem that you raise in your
    > message, could you please ask Juergen to not create an issue?I didn't CC issues, so I don't think Juergen will create an issue (at least,
    that was the intent). My apologies for the duplication. However, looking
    at 4285 once again, I think there may be a problem:

    In order to return something that means "ServantManager returned wrong
    servant type", I think the ORB core has to insert an active check
    at the point where the servant manager returns. If it doesn't, it will
    either get an unmarshaling error or return a BAD_OPERATION exception with
    some other minor code when it detects that the operation isn't in the
    function pointer table for the servant. In the latter case, the ORB won't
    know anymore why the operation is missing (for example, it could also
    be missing because the client used the DII to invoke a non-existent operation.)

    I am also not sure whether BAD_OPERATION is really the correct exception to
    use. To me, BAD_OPERATION tells the client "you invoked an operation that
    doesn't exist". If we give this exception to the client when it invokes
    an operation that's perfectly good, that's highly misleading because the
    actual problem isn't with the client, but with the servant manager.

    So, I think that using OBJ_ADAPTER, as I suggested, would be better.

    For the resolution to 4306, I think we also have something that is suboptimal.
    That's because minor code 2 say "Servant not found" in table 4-3. But
    I don't see how this is possible. Basically, a servant manager isn't allowed
    to return a null servant. If it can't find the servant, it's supposed to
    throw a system exception. So, a servant manager that returns null is simply
    broken and needs to be recoded. 4306 (by using "Servant not found" as
    the explanation of minor code 2) is misleading, because that condition simply
    can't happen.

    So, without trying to create a procedural mess, could we reconsider the
    resolution to these two issues, maybe for the next vote?

  • Reported: CORBA 2.4.2 — Sat, 23 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Fix inconsistency as described below

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

String literal definition incorrect.

  • Key: CORBA25-31
  • Legacy Issue Number: 4320
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    The following from the CORBA 2.4.1 specification.
    3.2.5.2 Character Literals
    A character literal is one or more characters enclosed in single quotes,
    as in ’x.’
    Character literals have type char.
    A character is an 8-bit quantity with a numerical value between 0 and
    255 (decimal).

    3.2.5.4 String Literals
    A string literal is a sequence of characters (as defined in Section
    3.2.5.2, “Character
    Literals,” on page 3-9) surrounded by double quotes, as in “...”.

    The above statements together implies that a string literal may contain
    embedded NULL characters. That is incorrect. The definition of string
    literals must explicitly eliminate NULL.

    Proposal:
    Revised text:

    Section 3.2.5.4 String Literals

    replace this first paragraph
    A string literal is a sequence of characters (as defined in Section
    3.2.5.2, “Character
    Literals,” on page 3-9) surrounded by double quotes, as in “...”.

    with
    A string literal is a sequence of characters (as defined in Section
    3.2.5.2, “Character
    Literals,” on page 3-9), with the exception of the character with
    numeric value 0, surrounded by double quotes, as in “...”.

  • Reported: CORBA 2.4.2 — Mon, 21 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make it so

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

Ambiguity in non_existent

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

    Section 4.3.5.1 non_existent last paragraph says:

    Probing for object non-existence may require contacting the ORB that
    implements the
    target object. Such an attempt may fail at either the local or the
    remote end. If non-existent
    cannot make a reliable determination of object existence due to failure,
    it
    raises an exception in the calling application code. This enables the
    application to
    distinguish among the true, false, and indeterminate cases.

    This does not define what exception gets thrown in the indeterminate
    case. I picked TRANSIENT, but COMM_FAILURE or NO_RESPONSE may also be
    valid choices.

    Proposal:

    Change the sentence in last paragraph of section 4.3.5.1:
    If non-existent cannot make a reliable determination of object existence
    due to failure, it
    raises an exception in the calling application code.

    to:
    If non-existent cannot make a reliable determination of object existence
    due to failure, it
    raises a TRANSIENT with XX minor code in the calling application code.

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

    close, no change

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

Typo in UML for POA

  • Key: CORBA25-34
  • Legacy Issue Number: 4333
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The UML diagram on page 11-49 uses "the_manager" in two places. This
    should be "the_POAManager".

    In one place, it uses the attribute "the_servant_manager". No such attribute
    exists.

  • Reported: CORBA 2.4.2 — Mon, 4 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make the suggested corrections

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

Inconsistent minor code for MARSHAL

  • Key: CORBA25-30
  • Legacy Issue Number: 4310
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    on page 3-23 of section 3.7.6.1, first bullet point, we find:

    Local types cannot be marshaled and references to local objects
    cannot be converted to strings. Any attempt to marshal a local
    object, such as via an unconstrained base interface, as an Object,
    or as the contents of an any, or to pass a local object to
    ORB::object_to_string, shall result in a MARSHAL system exception
    with OMG minor code 2.
    ^^^^^^^^^^^^^^^^
    However, the minor code table, page 4-59, section 4.11.4 shows:

    MARSHAL 1 Unable to locate value factory.
    2 ServerRequest::set_result called before
    ServerRequest::ctx when the operation IDL contains a
    context clause.
    3 NVList passed to ServerRequest::arguments does not
    describe all parameters passed by client.
    4 Attempt to marshal Local object.

    This is inconsisent – the text requires minor code 2, but the table
    requires minor code 4.

    I would suggest to update the first bullet of 3.7.6.1 to require minor code 4,
    in line with what is shown in the table.

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

    Make it so

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

Missing POAManager identity

  • Key: CORBA25-28
  • Legacy Issue Number: 4297
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the current way of dealing with POAManager objects is less than satisfactory.
    Consider:

    interface POA

    { // ... POA create_POA( in string adapter_name, in POAManager a_POAManager, in CORBA::PolicyList policies ) raises(AdapteraAlreadyExists, InvalidPolicy); readonly attribute POAManager the_POAManager; }

    ;

    The problem here is twofold:

    • There is no way to get at the list of all existing POA managers,
      at least not easily; I have to either keep a list myself,
      or I have to traverse the POA tree and build the list as I go.
    • POA managers have no identity. There is no name or other piece
      of state that would allow me to distinguish one POA manager from
      another.

    The second problem is the more serious one because POA managers are used
    to control the behavior of one or more transport endpoints. Most ORBs
    permit configuration control over transports. For example, it is usually
    possible to configure things such as which protocols/transports should
    be associated with a POA manager, how many protocols/transports should
    be associated, at what address/port the transport controlled by a
    POA manager should listen for requests, what timeouts to apply, etc, etc...

    Currently, ORBs have to resort to proprietary means to attach such
    configuration information. For example, in ORBacus, we use a proprietary
    POA manager factory that permits a name to be attached to a POA manager.
    That name then is used as a hook to attach configuration information
    to POA managers, so we can do things like configure port numbers, etc.

    I'd like to improve the spec such that it becomes possible to control
    identity for POA managers through a standard API. The thoughts are:

    • Add a POAManagerFactory interface that allows
    • creation of POA managers
    • listing of existing POA managers
    • searching for POA managers by name
    • Add an id() accessor to POAManager that returns the name

    For creation of POA managers, a CORBA::PolicyList can be passed into
    the call in addition to the POA manager name. That policy list would permit
    configuration of POA managers through a defined API (even though the
    actual policies that apply would still be proprietary).

    These changes would be completely backward-compatible, so no existing
    code breaks.

  • Reported: CORBA 2.4.2 — Wed, 9 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see below

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

Minor code

  • Key: CORBA25-29
  • Legacy Issue Number: 4306
  • Status: closed  
  • Source: Anonymous
  • Summary:

    "If a ServantManager returns a null Servant (or the equivalent in a language mapping) as the result of an incarnate() or preinvoke() operation, the POA will return the OBJ_ADAPTER system exception with standard minor code 3 as the result of the request."

    Should that be minor code 2 rather than 3? I couldn't find any other reference to OBJ_ADAPTER minor code 2 and the description makes more sense for this condition.

  • Reported: CORBA 2.4.2 — Mon, 14 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Yes the minor code in this case should indeed be 2. Make it so

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

Issue: Error in section 4.5.3.2 ORBInitRef

  • Key: CORBA25-25
  • Legacy Issue Number: 4275
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    Section 4.5.3.2 says:
    <ObjectURL> can be any of the URL schemes supported by
    CORBA::ORB::string_to_object (Sections 13.6.6 to 13.6.7 CORBA 2.3
    Specification).

    Couple of problems w/ this. Shouldn't the reference be Section 13.6.10
    of this spec. Also, the ObjectURL specifications in chapter 13 include a
    "rir" protocol which obviously makes no sense for ORBInitRef.

    Proposal:

    Replace first sentence of last paragraph of section 4.5.3.2 from:

    <ObjectURL> can be any of the URL schemes supported by
    CORBA::ORB::string_to_object (Sections 13.6.6 to 13.6.7 CORBA 2.3
    Specification).

    to

    <ObjectURL> can be any of the URL schemes supported by
    CORBA::ORB::string_to_object (Section 13.6.10), with the exception of
    the corbaloc URL scheme with the rir protocol (i.e. corbaloc:rir:...).

  • Reported: CORBA 2.4.2 — Tue, 17 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Fix as suggested above

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

Cross-reference refers to wrong section

  • Key: CORBA25-26
  • Legacy Issue Number: 4276
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The second paragraph of "3.10.1.7 Any Type" uses a cross-reference to explain the concept of the TypeCode in an Any value. This cross-reference refers to section 3.10, which is useless.

    Suggestion: Change this cross-reference to read as follows: '(see Section 10.7, "Type Codes", on page 10-51)'

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

    Fix as suggested

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

BAD_OPERATION needs minor code and completion status

  • Key: CORBA25-27
  • Legacy Issue Number: 4285
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    "This indicates that an object reference denotes an existing object,
    but that the object does not support the operation that was invoked."

    This text does not specify a minor code nor a completion status.

    Section 11.3.4.1 (last paragraph) says:

    "If the ServantManager returns the wrong type of Servant, it is
    indeterminate when that error is detected. It is likely to result in a
    BAD_OPERATION with standard minor code 5 or MARSHAL exception at the
    time of method invocation."

    This implies that 4.11.3.13 should specify a '5' for the minor code.

    A specific minor code for this case is necessary since BAD_OPERATION
    may be raised in other contexts (e.g., IDL->Java mapping for union,
    Any, any extraction, ...).

    I am not sure why it says '5' in 4.11.3.13. Is this minor code
    specified somewhere else that I'm missing?

    Assuming that this is underspecified I would suggest:

    1. assigning a minor code for the case discussed in 4.11.3.13,

    2. making sure that 11.3.4.1 is in sync with that assignment,

    3. specifying a completion status of COMPLETED_NO (since there is no
    way anything could be completed since the call never makes it out of
    the skeleton into the servant).

  • Reported: CORBA 2.4.2 — Thu, 26 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

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

Restrictions on native types

  • Key: CORBA25-23
  • Legacy Issue Number: 4264
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    The new text in 3.10.5 states: "Native type parameters are permitted
    only in operations of local interfaces or valuetypes". However, 11.4
    states that:
    a) Servant is a native type, and
    b) that it is used on the POA::get_servant operation, and
    c) that POA is not a local interface
    (Taking POA as an arbitrary example here; other POA interfaces show
    the same problem). Does that mean that CORBA 2.5 will be inconsistent?

  • Reported: CORBA 2.4.2 — Tue, 10 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

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

Clarification about include files and IDL compiler behavior

  • Key: CORBA25-22
  • Legacy Issue Number: 4262
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I think it would be nice to mention something about code generation in
    section 19.5.22.2. People seem to either expect that the compiler will
    generate code for everything, or that it will generate code only for
    things that are not in included files. The following might help to clear
    this up:

    "Note that whether a particular IDL compiler generates code for included
    files is an implementation-specific issue. To support separate
    compilation, IDL compilers may not generate code for included files, or
    do so only if explicitly instructed."

  • Reported: CORBA 2.4.2 — Tue, 10 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Insert the sugested text in section 3.3

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

3.7.4 Forward Declaration (for interfaces) doesn't mention local

  • Key: CORBA25-20
  • Legacy Issue Number: 4241
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 3.7.4 doesn't mention local as a legal prefix for an interface
    forward declaration.

    Proposal 1:

    Change the sentence:

    "The syntax is: optionally the keyword abstract, followed by the keyword
    interface, followed by an <identifier> that names the interface."

    to:

    "The syntax is: optionally either the keyword abstract or the keyword
    local, followed by the keyword interface, followed by an <identifier>
    that names the interface."

    Proposal 2:

    Just strike the sentence entirely, since it is redundant.

  • Reported: CORBA 2.4.2 — Tue, 27 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make the recommended change in Proposal 1

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

Definition of NamingContextExt interface in IDL of Appendix A not consisten

  • Key: CORBA25-21
  • Legacy Issue Number: 4246
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The definition of the NamingContextExt interface in the IDL of Appendix A is not consistent with the definition in section 2.5.4.

    Specifically,

    1. The Appendix A version has an extra operation: resolve_context

    2. In Appendix A, there is an extra exception type in the raises clause of the resolve_str operation: AlreadyBound

  • Reported: CORBA 2.4.2 — Thu, 29 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

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

Section 10.5.22.2 what happens when conditions not met

  • Key: CORBA25-24
  • Legacy Issue Number: 4266
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    What happens when someone attempts to set the mode attribute while not
    adhering to the restrictions spelled out?

    We should say what happens if these conditions
    aren't met. Furthermore, a oneway method can't have exceptions.
    I suggest:

    • add a new row to the BAD_PARAM block in Table 10-1 (p.10-10):

    Exception Minor Code Explanation

    BAD_PARAM N Attempt to define a oneway
    operation with non-void result,
    out or inout parameters or
    exceptions

    • Add a similar entry to table 4.3 (p.4-61).
    • Change the last para of 10.5.22.2 to read:

    "The mode attribute can be set to OP_ONEWAY only if the result is
    TC_void, all elements of params have a mode of PARAM_IN, and the
    list of exceptions is empty. If the mode is set to OP_ONEWAY
    when these conditions do not hold, a BAD_PARAM exception is
    raised with minor code N."

    This is perhaps rather large to be a friendly ammendment. I'm
    happy to vote YES to the current resolution, which is still a
    useful change, and raise this for next time. I can't discuss
    further in this round, as I'm on vacation for a week from this
    evening.

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

    see above

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

What is the semantics of the DataInputStream::read_*_array() operations?

  • Key: CORBA25-19
  • Legacy Issue Number: 4233
  • Status: closed  
  • Source: Floorboard Software ( Yvonne Biggar)
  • Summary:

    The CORBA::DataInputStream abstract valuetype has operations like:

    void read_boolean_array( inout BooleanSeq seq,
    in unsigned long offset,
    in unsigned long length);

    However, the spec says nothing about whether the provided sequence must
    already have sufficient length to satisfy the offset+length or whether
    the operation will extend the sequence to fit.

  • Reported: CORBA 2.4.2 — Fri, 23 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Clarify that the operations are expected to extend the sequence to fit

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

#include issue

  • Key: CORBA25-18
  • Legacy Issue Number: 4226
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    A minor issue with section 3.3 of the 2.4 specification:

    "... Text in files included with a #include directive is treated as
    if it appeared in the including file. ..."

    That is not true since, as we find out in chapter 10, included files
    behave specially with regard to assigning repository identifiers.

    e.g. in

    // a.idl
    #pragma prefix "foo"
    interface bar {};

    the repository id of bar is IDL:foo/bar:1.0, but in

    // a.idl
    #pragma prefix "foo"
    #include "b.idl"

    // b.idl
    interface bar {};

    it is just IDL:bar:1.0.

  • Reported: CORBA 2.4.2 — Tue, 20 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

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

ForwardRequest from normal operations

  • Key: CORBA25-14
  • Legacy Issue Number: 4176
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    interface Foo

    { void op() raises(PortableServer::ForwardRequest); }

    ;

    What happens if a client invokes op() and op() throws ForwardRequest?
    Is this received by the client as a locate forward or does the client
    simply receive the exception?

    The spec doesn't say either way. However, thinking about how all this is
    implemented, I strongly suspect that current implementations will simply
    marshal the exception back to the client instead of sending a locate forward
    reply.

    Personally, I think that's how it should be. If it werent, we'd have to
    insert additional code into the user exception processing path to deal
    with this special exception (which would probably set a bad precedent).

    I'd suggest to amend the spec to state that ForwardRequest has the effect
    of causing a locate forward reply only if thrown from preinvoke() and
    incarnate() and is otherwise just a normal exception.

  • Reported: CORBA 2.4.1 — Fri, 26 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate change and close issue

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

Inconsistent text for unknown system exception

  • Key: CORBA25-15
  • Legacy Issue Number: 4189
  • Status: closed  
  • Source: IONA ( Mark Spruiell)
  • Summary:

    In document 01-01-01, there are the following paragraphs which seem
    contrary to one another regarding the minor code to be used when an
    ORB receives an unrecognized system exception.

    4.11.2
    Vendors may define non-standard system exceptions, but these exceptions are
    discouraged because they are non-portable. A non-standard system exception, when
    passed to an ORB that does not recognize it, shall be presented by that ORB as an
    UNKNOWN standard system exception. The minor code and completion status from
    the unrecognized exception shall be preserved in the UNKNOWN exception.

    15.3.5.5 Exception
    Exceptions are encoded as a string followed by exception members, if any. The string
    contains the RepositoryId for the exception, as defined in the Interface Repository
    chapter. Exception members (if any) are encoded in the same manner as a struct.
    If an ORB receives a non-standard system exception that it does not support, or a user
    exception that is not defined as part of the operation's definition, the exception shall be
    mapped to UNKNOWN, with standard minor code set to 2 for a system exception, or
    set to 1 for a user exception.

  • Reported: CORBA 2.4.2 — Sat, 3 Feb 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

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

DynValueBox::set_boxed_value should also raise InvalidValue

  • Key: CORBA25-17
  • Legacy Issue Number: 4224
  • Status: closed  
  • Source: IONA ( Mark Spruiell)
  • Summary:

    As with other DynAny operations that accept an Any parameter,
    the set_boxed_value operation should be capable of raising
    InvalidValue.

    Proposal:

    • In sections 9.2 and 9.12, add InvalidValue to the raises clause for
      set_boxed_value
    • In section 9.12, replace the text describing set_boxed_value with the
      following:

    "The set_boxed_value operation replaces the boxed value with the specified
    value. If the type of the passed Any is not equivalent to the boxed type,
    the operation raises TypeMismatch. If the passed Any does not contain a
    legal value, the operation raises InvalidValue. If the DynBoxedValue
    represents a null valuetype, it is converted to a non-null value."

  • Reported: CORBA 2.4.2 — Fri, 16 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make it so

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

Type redefinition in derived interface

  • Key: CORBA25-12
  • Legacy Issue Number: 4170
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The discussion for issue 3525 shows that it is legal to redefine a type
    in a derived interface, as in

    interface B

    { typedef string S; }

    ;
    interface D : B

    { typedef long S; }

    ;

    However, I don't think that this legality is obvious from the text. On
    page 3-52, it says that "inheritance causes all identifiers defined in
    base interfaces to be visible in derived interfaces." Then, on page
    3-56, it is said that "once a type has been defined anywhere within
    the scope of a module, interface or valuetype, it may not be redefined
    except within the scope of a nested module or interface."

    Since B::S is not "defined" but only "visible" in D, and D is not a
    nested interface but a derived interface, there seems to be a gray
    area.

    Proposed resolution:

    Edit the first paragraph of 3.15.3 (Special Scoping Rules for Type
    Names) on p 3-56 to read:

    "Once a type has been defined anywhere within the scope of a module,
    interface or valuetype, it may not be redefined except within the
    scope of a nested module, interface or valuetype, or within the
    scope of a derived interface or valuetype."

    Edit the following example to include, after interface A, but before
    the erroneous redefinition of ArgType,

    interface B : A {
    typedef long ArgType; // OK, redefined in derived interface
    struct S

    { // OK, redefined in derived interface ArgType x; // x is a long A::ArgType y; // y is a string }

    ;
    };

  • Reported: CORBA 2.4.1 — Tue, 23 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make the suggested change clarifying the inheritance case

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

misleading wording in 10.5.22.2 Write Interface

  • Key: CORBA25-16
  • Legacy Issue Number: 4217
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The mode attribute can only be set to OP_ONEWAY if the result is TC_void and all
    elements of params have a mode of PARAM_IN.

    which might be taken to mean that the mode attribute must be set to
    OP_ONEWAY if the signature is as described. A better wording might be

    The mode attribute can be set to OP_ONEWAY only if the result is TC_void and all
    elements of params have a mode of PARAM_IN.

    This was brought to my attention by an email question I received today, from
    someone who thought he understood CORBA oneway semantics until he
    read that sentence - then he became confused.

  • Reported: CORBA 2.4.2 — Fri, 2 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    make it so

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

Introduction of identifiers

  • Key: CORBA25-13
  • Legacy Issue Number: 4171
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    I cannot seem to come to grips with the introduction of identifiers
    by their use in a nested scope. The example on page 3-54 reads
    (simplified)

    module Inner1

    { typedef string S1; }

    ;

    module Inner2

    { typedef Inner1::S1 S2; // Inner1 introduced typedef string inner1; // Error }

    ;

    The text goes on to explain that the above construct introduces the
    identifier "Inner1", while using the absolute name, "::Inner1::S1"
    in the typedef wouldn't. Therefore, the following code would be
    legal:

    module Inner2

    { typedef ::Inner1::S1 S2; // Inner1 not introduced typedef string inner1; // legal }

    ;

    I fail to see the rationale in this. Also, this is not in sync with
    the Interface Repository, which cannot even detect that the first
    example is illegal, because it never sees relative names.

    My proposed resolution would be to get rid of "introduced names"
    altogether and to declare the above example legal.

  • Reported: CORBA 2.4.1 — Tue, 23 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Close no change

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

core issue: unchecked narrow

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

    CORBA Core should state that language mappings providing a narrowing mechanism
    are also required to provide an 'unchecked narrowing'-mechanism.

    The original CORBA Messaging specification (orbos/98-05-05) specifies an
    unchecked narrow operation that has not been changed by any Messaging RTF.
    'unchecked narrowing' is not an issue of a single language mapping. Therefore,
    it would be good if this was formulated in the CORBA Core as a general
    requirement for any language mapping.

    The originally adopted CORBA Messaging specification, orbos/98-05-05, had an
    explanatory paragraph for this purpose:

    '3.3.7 Note on Asynchrony and Narrowing of Object References
    Many programming languages map IDL interfaces to programming constructs that
    support inheritance. In those language mappings (such as C++ and Java) that
    provide
    a mechanism for narrowing an Object reference of a base interface to a more
    derived
    interface, the act of narrowing may require the full type hierarchy of the
    target. In this case, the implementation of narrow must either contact an
    interface repository or the target itself to determine whether or not it is
    safe to narrow the client’s object reference. This requirement is not
    acceptable when a client is expecting only
    asynchronous communication with the target. Therefore, for the appropriate
    languages
    this specification adds an unchecked narrow operation to the IDL mappings for
    interface. This unchecked narrow always returns a stub of the requested type
    without
    checking that the target really implements that interface. If a client narrows
    the target to an unsupported interface type, invoking the unsupported
    operations will raise the system exception CORBA::BAD_OPERATION.'

    However, the semantics of the above have obviously not made it into CORBA 2.4.

  • Reported: CORBA 2.4.1 — Fri, 19 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

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

PortableServer::ObjectId

  • Key: CORBA25-11
  • Legacy Issue Number: 4165
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    I propose that ObjectId be changed from:

    typedef sequence<octet> ObjectId;

    to:

    typedef CORBA::OctetSeq ObjectId;

    This shouldn't cause any existing code to break. However, currently
    PortableInterceptor::ObjectId (needed so that the PI module doesn't
    depend on the PortableServer module) isn't directly assignable to
    PortableServer::ObjectId which means additional copying that doesn't
    seem necessary. It also reduces the code-size of the ORB somewhat
    (since a sequence type can be removed from the core).

  • Reported: CORBA 2.4.1 — Sat, 20 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

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

Container::lookup() ordering requirements

  • Key: CORBA25-9
  • Legacy Issue Number: 4152
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    In the Interface Repository, Container::contents() and describe_contents()
    do not seem to have any restrictions on ordering. However, these seem to
    be necessary for interoperability, so that a dynamic bridge that tries to
    find out about a Value by using Container::contents (dk_ValueMember, 0)
    does the right thing.

  • Reported: CORBA 2.4.1 — Tue, 16 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Add language to require preservation of order of elements in IR as shown below

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

CORBA::ORB::object_to_string() raising INV_OBJREF or BAD_PARAM

  • Key: CORBA25-6
  • Legacy Issue Number: 4128
  • Status: closed  
  • Source: Progress Software ( Eoghan Glynn)
  • Summary:

    There appears to be a contradiction in CORBA 2.4.1 (00-11-07) as to
    whether CORBA::ORB::object_to_string() should raise INV_OBJREF or
    BAD_PARAM when an invalid string is passed.

    Here's where I see a contradiction in the spec:

    CORBA 2.4.1: "4.11.3.6 INV_OBJREF
    This exception indicates that an object reference is internally
    malformed. For example, the repository ID may have incorrect syntax or
    the addressing information may be invalid. This exception is raised by
    ORB::string_to_object if the passed string does not decode correctly."

    This explicitly specifies that INV_OBJREF is thrown if a non-decodable
    stringified IOR is passed to string_to_object().

    On the other hand the table:
    CORBA 2.4.1: "4.11.4 Standard Minor Exception Codes ...
    BAD_PARAM ...
    7 string_to_object conversion failed due to bad scheme name.
    8 string_to_object conversion failed due to bad address.
    9 string_to_object conversion failed due to bad bad schema specific
    part.
    10 string_to_object conversion failed due to non specific reason."

    indicates that BAD_PARAM/10 should be raised for non-specific
    string_to_object failures, contradicting 4.11.3.6 above.

    Is this simply an editing issue in that 4.11.3.6 has not yet been
    updated to take cognizance of 4.11.4? I propose that 4.11.3.6 is updated
    to allow BAD_PARAM to be raised on string_to_object failures where the
    problem lies in the string content.

  • Reported: CORBA 2.4.1 — Tue, 19 Dec 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above, Close issue, already fixed

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

Section 2.1.7 of CORBA 2.3 and 2.4

  • Key: CORBA25-8
  • Legacy Issue Number: 4135
  • Status: closed  
  • Source: Object Management Group ( Jon Siegel)
  • Summary:

    Section 2.1.7 of CORBA 2.3 and 2.4 (and presumably all earlier
    versions) concludes with the sentence

    Object-oriented programming languages, such as C++ and Smalltalk,
    do not require stub interfaces.

    I suspect that this is a relic of some prehistoric age when early
    OMG folk imagined that OO languages would handle some stub stuff
    via language mechanisms. Since this has not turned out to be the
    case, the sentence should be excised.

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

    incorporate change and close issue

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

ServantLocator preinvoke/ postinvoke semantics

  • Key: CORBA25-5
  • Legacy Issue Number: 4117
  • Status: closed  
  • Source: Borland Software Corporation ( Andy Cutright)
  • Summary:

    the 2.4 specification states that 'preinvoke and postinvoke operations
    are always called in paris in response to any ORB activity...' the spec
    details in particular the case of what happens when preinvoke is called
    when processing a GIOP Locate message: postinvoke is called subsequent
    to calling preinvoke.

    if the preinvoke raises an exception, what is the expected behavior?
    should postinvoke be called if preinvoke raises a system exception or
    ForwardRequest? are there any situations in which postinvoke would not
    be called following a call to preinvoke?

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

    Clarify the expected behavior if preinvoke raises an exception

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

Legal IDL?

  • Key: CORBA25-7
  • Legacy Issue Number: 4132
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    Is the following legal IDL?

    module M
    {
    abstract interface I

    { string s(); }

    ;

    valuetype V supports I

    { private string s; }

    ;
    };

    Our interpretation of the spec is that it is legal but we have been informed
    that some other IDL compilers consider it an error.

  • Reported: CORBA 2.4.1 — Wed, 20 Dec 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see below

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

POAManager::deactivate should not mandate ORB::shutdown implementation

  • Key: CORBA25-3
  • Legacy Issue Number: 4034
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    Section 11.3.2.6 has a paragraph that states:

    If the ORB::shutdown operation is called, it makes a call on deactivate
    with a
    TRUE etherealize_objects parameter for each POA manager known in the
    process;
    the wait_for_completion parameter to deactivate will be the same as the
    similarly
    named parameter of ORB::shutdown.

    Shouldn't this be reworded to not require an explicit call to
    deactivate(but only the effect). Also, since ORB::shutdown already does
    the equivalent of destroy on the POAs shouldn't the order of these
    operations be specified. I also think they should be specified in the
    text for ORB shutdown rather than here.

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

    Right, make it so

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

Minor code 2 description for OBJECT_NOT_EXIST not consistent w/ use

  • Key: CORBA25-4
  • Legacy Issue Number: 4037
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    I was looking at the spec to amend 4033 to not use up a new minor code but
    noticed this text for minor code 2 under OBJECT_NOT_EXIST:

    POAManager::incarnate failed to create POA.

    This is clearly not consistent with its use under the TRANSIENT POA Lifespan
    Policy description (I also found other inconsistent uses, detailed below).

    There are two things that need fixing here. The first one is probably
    straightforward.
    1. The minor code allocated for 4033 must be used in the text for TRANSIENT
    Lifespan Policy in section 11.3.7.2

    2. POAManager::incarnate is not a valid operation at all.
    I found references to OBJECT_NOT_EXIST with minor code 2 in the following
    places:

    A - Section 11.2.6, paragraph 2

    The adapter activator has the opportunity to create the required POA. If it
    does not, the client receives the
    OBJECT_NOT_EXIST exception with standard minor code 2.

    B - Section 11.2.6
    If the POA has the NON_RETAIN policy or has the RETAIN policy but didn't
    find a
    servant in the Active Object Map, the POA takes the following actions:
    Bullet 3

    • If t he USE_OBJECT_MAP_ONLY policy is in effect, the POA raises the
      OBJECT_NOT_EXIST system exception with standard minor code 2.

    C - 11.3.3.2 unknown_adapter
    If the operation returns TRUE, the ORB will
    proceed with processing the request. If the operation returns FALSE, the ORB
    will
    return OBJECT_NOT_EXIST with standard minor code 2 to the client.

    D - 11.3.3.2 unknown_adapter
    If the parent of a nonexistent POA does not have an
    associated adapter activator, the ORB will return the OBJECT_NOT_EXIST
    system
    exception with standard minor code 2.

    E - 11.3.7.6 Request Processing Policy
    USE_ACTIVE_OBJECT_MAP_ONLY - If the Object Id is not found in the
    Active Object Map, an OBJECT_NOT_EXIST system exception with standard
    minor code 2 is returned to the client.

    Cases A, C and D hint that minor code 2 should actually say "Could not
    create or locate POA" or something to that effect. Cases B and E should
    really be using another minor code ("Could not locate object in AOM?").

  • Reported: CORBA 2.4.1 — Tue, 14 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    incorporate change and close issue

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

Can a valuetype support multiple non-abstract interfaces via inheritance?

  • Key: CORBA25-1
  • Legacy Issue Number: 4003
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.4 specification is not clear about whether a valuetype can
    support multiple non-abstract interfaces via inheritance. Here is an
    example:

    interface I1 {};

    interface I2 {};

    valuetype V1 supports I1 {};

    valuetype V2: V1 supports I2 {};

    Is V2 legal?

    I see three possible resolutions to this issue:

    1. Make V2 illegal. A valuetype may not support a non-abstract
    interface if any of its base valuetypes supports a non-abstract
    interface. This is a pretty simple rule, but I think it is far too
    restrictive, and can get in the way of some cases where supporting
    multiple interfaces could be genuinely useful.

    2. Make V2 legal. Since we have clarified (assuming that the proposed
    resolution of 3589 passes, which it appears it will) that valuetypes
    that support an interface are not synonymous with an object reference
    that uses that valuetype as a servant, I don't see any actual core
    issues that break the object model. Also, my inspection of the language
    mappings does not reveal any problems on that front either.

    3. Make V2 illegal, but make it legal if I2 inherited from I1. The
    rule would be that a valuetype can support a non-abstract interface only
    if that interface is derived (directly or indirectly) from all other
    non-abstract interfaces that are supported by base valuetypes. This
    allows the use of the ladder inheritance pattern, which I think is very
    useful in this case:

    interface I1 {};

    valuetype V1 supports I1 {};

    interface I2 {};

    valuetype V2 supports I2 {};

    interface I3 : I1, I2 {};

    valuetype V3 : V1, V2 supports I3 {};

    Of these three posible resolutions, I prefer #2, since I don't see any
    practical implementation problems, so the restriction in #3 is really
    not necessary.

  • Reported: CORBA 2.4 — Fri, 27 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see below

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

POAManager::deactivate does not specify behavior for "reject"

  • Key: CORBA25-2
  • Legacy Issue Number: 4033
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    This is the first issue I found w/ POAManager::deactivate definition.

    The spec states in section 11.3.2.6, paragraph 1.

    Entering the inactive state causes the associated POAs to reject
    requests that have not
    begun to be executed as well as any new requests.

    However, there is no definition of what "reject" means. What does the
    client see in this case?

    Proposal:

    Add to the paragraph:
    When a request is rejected, an OBJECT_NOT_EXIST system exception with
    standard minor code XX is returned to the client.

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

    The proposal proved to be too controversial. So suggest close no change

  • 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

wchar alignment in GIOP 1.2

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

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

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

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

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

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

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

    Close with revision

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