Issue 1539:  OBV C++ problem with "supports" (obv-rtf)
Source:  (, )
Nature:  Revision
Severity: 
Summary: Summary: The OBV spec allows a value to support multiple interfaces. In C++, such
 values
 are specified to derive from the POA skeletons generated from those
 interfaces.
 This presents a potentially intractable problem: skeletons are not designed to
 be inherited together with skeletons for other interfaces because servants do
 not support multiple interfaces. (The Multiple Interface RFP isn"t finished
 yet, right?) The top of page 20-104 of the latest C++ mapping (orbos/98-05-08)
 explicitly says
 

Resolution: 
Revised Text: 
Actions taken:
June 23, 1998: received issue
July 30, 1998: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <vinoski@iona.com>
X-Sender: vinoski@mail.boston.iona.ie
Date: Tue, 23 Jun 1998 17:18:58 -0400
To: obv-rtf@omg.org, issues@omg.org
From: Steve Vinoski <vinoski@iona.com>
Subject: OBV C++ problem with "supports"

The OBV spec allows a value to support multiple interfaces. In C++,
such
values
are specified to derive from the POA skeletons generated from those
interfaces.
This presents a potentially intractable problem: skeletons are not
designed to
be inherited together with skeletons for other interfaces because
servants do
not support multiple interfaces. (The Multiple Interface RFP isn't
finished
yet, right?) The top of page 20-104 of the latest C++ mapping
(orbos/98-05-08)
explicitly says

"Note that the presence of the _this() function implies that C++
servants must
only
be derived directly from a single skeleton class. Direct derivation
from
multiple
skeleton classes could result in ambiguity errors due to multiple
definitions
of
_this(). This should not be a limitation, since CORBA objects have
only a
single
most-derived interface."

ORB implementations often take advantage of this fact and make their
skeletons
contain proprietary helper functions that are used to help dispatch
requests.
These functions are often virtual. When an application developer
mistakenly
tries to use multiple skeletons as base classes for his servant,
compilation
errors result due to ambiguous invocations of identical functions
inherited
from multiple base classes.

For example, skeletons often contain a virtual helper function that
returns
the
repository ID of the most-derived interface that the POA invokes
during
implicit object activation in order to create the object
reference. For this
discussion, we can assume that this function is identical in signature
and
semantics to the DynamicImplementation::_primary_interface
function. If a
value
supporting multiple interfaces inherits from multiple POA skeletons,
the
presence of this function in each skeleton causes ambiguity
errors. The only
way for an application developer to avoid this is to override the
virtual
function in his concrete skeleton class, which of course is not
portable.
Furthermore, there is no way to determine what the return value of the
function
should be -- which of the interfaces being supported should the return
value be
for? Even usage of the _this() function on such a value in application
code
will cause compilation errors.

I see no easy way to fix this.

This might be viewed strictly as an OBV C++ mapping problem, but it
isn't. I
see it as yet another fundamental flaw with the OBV spec -- in effect,
it
introduces support for multiple interfaces by accident, and doesn't
address
all
the necessary issues. Can anyone actually tell me that they realized
that they
were introducing multiple interfaces when they added this feature?

--steve