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

[Michael Kilburn]

On Wed, Mar 25, 2009 at 6:28 AM, Duncan Grisby <duncan at grisby.org> wrote:

> > 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.
>

Hmm... According to my understanding of terminology "CORBA object" is a
virtual entity described by an interface in idl file. Servant instance is an
incarnation of CORBA object (i.e. it implements given interface). When
servant implements multiple interfaces -- this is what called "incarnates
multiple CORBA objects". I.e. number of activations have nothing to do with
it. But I could be wrong, of course...


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.
>

All this is confusing and dangerous, even we we asume that there s no
logical problems in standard's wording... I would prefer simple and
straightforward approach -- if not current, then grab default POA, check
policies then return ref or throw.



> > :-) 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.
>

Majority of code probably does not create additional POAs (no POAs -- no
problems).
I do not try to tell that omniORB has to protect me from this, this is
standard's job -- just wanted to know why omniORB's behaviour is different
from what my eyes see in standard -- clearly there is at least one problem
in the document.

-- 
Sincerely yours,
Michael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20090325/952b5b50/attachment.htm