[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