In the OMG spec the servant_to_id is described as below. If the RETAIN,
NO_IMPLICIT_ACTIVATION an UNIQUE has been set then the pre condition is
valid so we don't get wrong policy. Then we follow the steps, 1 is not
possible, 2 is also not possible, 3 is not possible, so 4 is triggered but
that looks very strange. I think there should be another step says if RETAIN
and UNIQUE and NO_IMPLICIT_ACTIVATION and not active then we get
WrongPolicy. Ok, the servant is not active, but it is more that the policies
This appeared when testing for CORBA/e compact. There RETAIN,
NO_IMPLICIT_ACTIVATION and UNIQUE are the default and without a special
check for CORBA/e we got a ServantNotActive exception instead of the wrong
policy. We could add a check for CORBA/e compact but it looks that the real
issue is in the core spec already.
This operation requires the USE_DEFAULT_SERVANT policy or a combination of
RETAIN policy and either the UNIQUE_ID or IMPLICIT_ACTIVATION policies if
invoked outside the context of an operation dispatched by this POA. If this
not invoked in the context of executing a request on the specified servant
and the policies
specified previously are not present, the WrongPolicy exception is raised.
This operation has four possible behaviors.
1. If the POA has both the RETAIN and the UNIQUE_ID policy and the specified
servant is active, the Object Id associated with that servant is returned.
March 2004 CORBA, v3.0.3: Interfaces 11-43
2. If the POA has both the RETAIN and the IMPLICIT_ACTIVATION policy and
either the POA has the MULTIPLE_ID policy or the specified servant is not
the servant is activated using a POA-generated Object Id and the Interface
associated with the servant, and that Object Id is returned.
3. If the POA has the USE_DEFAULT_SERVANT policy, the servant specified is
default servant, and the operation is being invoked in the context of
request on the default servant, then the ObjectId associated with the
invocation is returned.
4. Otherwise, the ServantNotActive exception is raised.