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

[Nigel Rantor]

Michael Kilburn wrote:
> 
> 
> On Wed, Mar 25, 2009 at 6:28 AM, Duncan Grisby <duncan at grisby.org 
> <mailto: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...

Hi Michael, I've been lurking this discussion.

A Servant may handle requests for multiple different Object instances. 
This is what it means for a Servant to incarnate multiple Objects. It 
has nothing to do with the number of different CORBA IDL interfaces that 
a Servant implements.

For example you can use a ServantManager to always provide the exact 
same Servant for every request, irrespective of the actual object 
requested. Depending on what you're trying to achieve this can be very 
useful.

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

This seems to be a difference of opinion then. I agree with Duncan's 
interpretation of the standard. Can you explain why the above does not 
seem straightforward to you?

>      > :-) 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 disagree with this. I can't recall a CORBA app where I've not created 
at least one of my own POAs, simply becasue the default policy on the 
RootPOA is normally not what you want.

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

As above, I think this is opinion then. You interpret the spec one way. 
Other people interpret it in a different way. How about checking out 
other vendor's implementations/interpretations?

Regards,

   Nigel