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

[Duncan Grisby]

On Wednesday 25 March, Michael Kilburn wrote:

[...]
>       "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.
> 
> I see no point in checking number of activations then... (activations_.size()
> == 1)

That's essential for the "as long as the servant is not incarnating
multiple CORBA objects" bit.

>     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.
> 
> I would say second part does not override anything -- it just specifies how
> that new reference should be created, i.e.:
> - call _defaultPOA()
> - check policies
> - throw or duplicate a reference
> 
> though here is some amount of confusion -- which POA they refer to in "This
> requires the POA with which the servant was activated to have"? if this is POA
> where object is already activated -- it does not make sense in case if object
> is activated in multiple POAs. If they mean _defaultPOA() -- they worded it
> rather bad.

"The POA with which the servant was activated" clearly means just what
it says -- if I activate a servant in a particular POA, that is the POA
in which it is activated, regardless of what the servant's _default_POA
method might return.

In this code

  servant = new MyServantClass();
  mypoa->activate_object(servant);

Which POA is the servant activated in?  Clearly it's activated in
mypoa. Nobody has to ask what the servant's _default_POA method returns
to answer that question.

Now if I do

  myobj = servant->_this();

Clearly my servant has a single activation in a single POA, so
(according to the rules quoted above) the call to _this() returns a
reference corresponding to that activation in that POA.

>     Once a servant is activated in one or more POAs, talking about the
>     one returned by _default_POA is rather nonsensical.
> 
> I see nothing nonsensical about this behaviour -- since given object is not a
> target of the current request and user (instead of properly duplicating
> existing reference) tries to create new reference without specifying POA --
> default one will be used.

I think the confusion is around the intention of the _this() method.
_this() is not intended to return *a* reference corresponding to a
servant, it's intended to return *the* reference corresponding to a
servant. i.e. the one single reference that makes sense for a servant.
If a servant is activated once in one POA, that is clearly the reference
you want. If a servant is activated multiple times (regardless of
whether in just one POA or multiple POAs), there is no single correct
reference to return, so _this() throws an exception.

It's only in the case that a servant is not activated at all that the
question of "which POA?" arises. If you have to ask "which POA?", then
the answer is the one returned by _default_POA(). That's why it's called
default -- it's the one to use if you don't have any other POA to
choose.

>     omniORB is definitely not going to change in this
>     respect. To change it would break an enormous amount of code.
> 
> :-) I knew it... I bet this enormous amount of code has the same problem we do
> -- if for some reason _this() is called on deactivated object it will be
> (unexpectedly) activated in the RootPOA.

Yes, but it's not omniORB's job to protect you from all bugs in
application code. There is plenty of code out there that looks just like
the simple example I've used above, and that is trivially correct.

Cheers,

Duncan.

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