CORBA 3.0 NO IDEA Avatar
  1. OMG Issue

CORBA3 — Messaging Poller generation is broken for interfaces with multiple inherite

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

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

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

    Proposed resolution:

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

    module Messaging {
    abstract valuetype Poller : CORBA::Pollable

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

    ;
    };

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

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

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

    ;

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

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

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

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

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

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

    valuetype AMI_StockManagerPersistentPoller : AMI_StockManagerPoller

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

    ;

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

    Make the changes recommended in the archive

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