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

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

;
};

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

;

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

;

Make the changes recommended in the archive