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

Michael Kilburn crusader.mike at gmail.com
Sat Mar 21 20:57:35 GMT 2009


Hi Michael,

> [skipped lengthy description of _this()'s behaviour that tracks
> activations and in case if there is only one activation -- it uses POA of
> that activation to produce a new reference]
>
>
> > - I feel that this (probably helpful) behaviour is not standard-compliant
> --
> > can someone prove that it is not the case?
> Afaik this is in fact standard compliant.
>

Can't find anything in standard that might allow this, quite opposite --
standard clearly says that if object is not a target of 'Current' request --
_defaultPOA is called to get POA used to lookup a reference or activate (in
case of implicit activation), no optionality.
Can you give me a reference that suports your point of view?



> > - I am trying to avoid necessity of overriding _defaultPOA (someone will
> > forget to do it and it will lead to hard-to-find problems). So there any
> way
> > to ensure that all objects get activated in specific POA without this?
> You'll have to call activate on the correct poa explicitly (it shouldn't
> be hard to verify this, assuming you have a reasonable code structure).
> Maybe you should write a get_this helper template that makes sure
> everything is activated the way you want it?!?
>

:-) Our product in constant state of development for last 10? years and will
continue like that for foreseeable future (with developers coming and
leaving). I am pretty much sure that sooner or later one of them will forget
to use a helper or override that function. It is inevitable.


> > - maybe it is possible to 'disable' RootPOA somehow?
> I don't think so + I don't think it would be any good (poas form a
> hierachy)


Well, I see at last one good thing about disabling or killing RootPOA
(assuming you can't change it's policies) -- it will remove necessity of
overriding _defaultPOA() method in every servant if you want all your
servants to belong to different POA :-)

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


More information about the omniORB-list mailing list