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

Michael Kilburn crusader.mike at gmail.com
Wed Mar 25 01:24:04 GMT 2009


On Mon, Mar 23, 2009 at 11:17 AM, Duncan Grisby <duncan at grisby.org> wrote:

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


Yes exactly this section I had in mind...



>   "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)



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



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



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


> 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?
>
> Certainly in omniORB you should call it just once.
>

Thanks!

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


More information about the omniORB-list mailing list