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