[omniORB] strange behavior of '_this()' method

[Duncan Grisby]

On Friday 20 March, Michael Kilburn wrote:

[...]
> Since our servants usually activated only in one POA and usually already
> activated before possible _this() call -- this code 'saves' us. But there are
> few cases when _this() might be called on non-active object -- and it behaves
> as I feared (i.e. gets activated in RootPOA).
> 
> Now questions:
> - I feel that this (probably helpful) behaviour is not standard-compliant --
> can someone prove that it is not the case?

Like many things, it's a matter of interpretation. _this is defined in
the C++ mapping specification. In the 1.2 version of the mapping, in
section 4.40.2, it says:

  "3. Outside the context of a request invocation on the target object
   represented by the servant, it will return the object reference for a
   servant that has already been activated, as long as the servant is
   not incarnating multiple CORBA objects."

That's exactly what omniORB does.

However, that section then goes on to say

  "This requires the POA with which the servant was activated to have
   been created with the UNIQUE_ID and RETAIN policies. If the POA was
   created with the MULTIPLE_ID or NON_RETAIN policies, the
   PortableServer::WrongPolicy exception is thrown. The POA is gotten by
   invoking _default_POA() on the servant."

Depending on how you read it, that may or may not override the earlier
bit. Once a servant is activated in one or more POAs, talking about the
one returned by _default_POA is rather nonsensical.

I think it could possibly be considered a bug that if a servant is
activated a single in a POA with the MULTIPLE_ID policy, a reference for
the single activation is returned, rather than it throwing an
exception. I do not, on the other hand, think it is a bug that it
returns a reference for the single activation if there is one, in the
case of a POA with the UNIQUE_ID policy, even if _default_POA returns a
different POA. omniORB is definitely not going to change in this
respect. To change it would break an enormous amount of code.

> - is there any way to change RootPOA's policies? (to remove ecessity of
> creating another POA)
> - I am trying to avoid necessity of overriding _defaultPOA (someone will
> forget to do it and it will lead to hard-to-find problems). So there any way
> to ensure that all objects get activated in specific POA without this?
> - maybe it is possible to 'disable' RootPOA somehow?

You can't do any of these things without modifying omniORB, I'm afraid.
One simple thing you could do would be to modify the
PortableServer::ServantBase class in include/omniORB4/poa.h to declare
that _default_POA() is abstract. That way all your servant classes would
have to define it.

> And one unrelated question:
> I have created a ServantManager object and registered it with POA. According
> to standard when object is activated _add_ref() is called nspecified number of
> times. The question is how many times etherealize() method of ServantManager
> should call _remove_ref() when called with remaining_activations = true? It
> works with one call -- but is it guaranteed?

The spec is decidedly unclear on that point, but it must surely be the
intention. If that wasn't the case, application code would have to know
how many times the POA had called _add_ref(), which would be crazy.
Certainly in omniORB you should call it just once.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --