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

[Michael]

I totally agree with Nigel, in six years of using CORBA I never wrote a
server application that didn't create its own POAs. No offense, but
quite frankly I think that argument is flawed ("we are the only ones
writing complicated software and one day it will hit us"). This is
exactly why you need coding guide lines. So, if you're concerned that
people will break code by using _this in the wrong way, enforce the
usage of a wrapper function that throws when _this is called on an
inactive object. Make that an inline function and the performance
penalty will be neglectable. You can then include a check for "_this" in
your QA process (e.g. grep "_this" *.C *.h). Quite simple. It's pretty
much like every piece of code, people will make mistakes, as a project
leader/manager it is your responsibility to define best practices and
setup a QA process. Especially in C++ it's all about your people not
doing stupid things (like enforcing use of smart pointers, RAII
principle etc.). Developers will always find ways to break code. Did you
ever consider using a different Middleware/RPC solution, because the
CORBA C++ mapping is pretty complicated (once you master it it's simple,
but from my experience training people is a nightmare)? I would never
again setup a project based on CORBA if I knew that many developers will
have to maintain the codebase.

just my 2 cents :)
michael

Nigel Rantor wrote:
> 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
> 
> 
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list