CORBA24 — ORB mediation for servant managers, references for servant managers?

Two questions:

1) Are calls to operations on servant managers mediated by the ORB?

2) Is it legal to export the object reference for a servant manager
to another process?

For question 1, the answer would appear to be no. Here is why:

Page 11-17:

Inactive state

When a POA manager is in the inactive state, the associated POAs
will reject new requests. [...] If the client is co-resident in
the same process, the ORB could raise the OBJ_ADAPTER system
exception, with standard minor code 1, to indicate that the
object implementation is unavailable. [...]

If the transition into the inactive state is a result of calling
deactivate with an etherealize_objects parameter of

• TRUE - the associated POAs will call etherealize for
  each active object associated with the POA once all
  currently executing requests have completed processing
  (if the POAs have the RETAIN and USE_SERVANT_MANAGER
  policies). If a servant manager has been registered for
  the POA, the POA will get rid of the object. If there
  are any queued requests that have not yet started
  executing, they will be treated as if they were new
  requests and rejected.

If calls to servant managers were to be ORB-mediated, the calls to
etherealize() cannot possibly be dispatched because the corresponding
servant manager is already in the inactive state. The only logical conclusion
I can see is that calls to servant managers are not mediated by the ORB.

I think the spec should be updated to state this.

For question 2, the answer would also appear to be no:

Exporting a reference to a servant manager outside my own address space
makes no sense whatsoever. Here a servant manager offers either
incarnate() and etherealize(), or it offers preinvoke() and postinvoke().
These are the only operations that are possible (apart from operations
on Object). If it were possible to export a reference to a servant
manager to another address space, there is nothing the receiver of
the reference could do with it (other than call operations on Object).
That's because incarnate(), etherialize(), and preinvoke use a native
type (servant). postinvoke() doesn't use a native type, but
accepts a parameter of type POA, so postinvoke cannot be invoked
remotely either (because POA is locality constrained and its
reference cannot be marshaled).

So, it appears clear that export of servant manager references should be
illegal and flagged the same way as an attempt to export a POA manager
reference.

The spec currently says this about servant managers:

A ServantManager object must be local to the process containing
the POA objects it is registered with.

Contrast this with POA managers, for which the spec says:

A POAManager object must not be exported to other processes,
or externalized with ORB::object_to_string. If any attempt is
made to do so, the offending operation will raise a MARSHAL
system exception. An attempt to use a POAManager object with
the DII may raise the NO_IMPLEMENT exception.

To me, it looks like we should say the same thing for servant managers as
for POA managers.

And, by the same reasoning, I think it also must be said for the
AdapterActivator interface: it doesn't make sense to marshal a reference
for an adapter activator because the only operation (unknown_adapter) has
an in parameter of type POA, which cannot come from a remote location.

Merge into Issue 4264 and close this with the resolution of 4264.