[omniORB] omniNames and POA

[jon@totient.demon.co.uk]

>>>>> "Duncan" == Duncan Grisby <dgrisby@uk.research.att.com> writes:

    Duncan> On Sunday 4 February, jon@totient.demon.co.uk wrote:
    >> I've been looking at the src of omniNames (mainly as an example
    >> because it used the persistent lifespan policy)
    >> 
    >> However I am curious as to why it creates 2 POA's and then
    >> activates them? Is this for backward compatibility with an
    >> older version or is there something more subtle going on?

    Duncan> Most of the objects created by omniNames are created in a
    Duncan> normal POA, which has the system id policy. However, the
    Duncan> root naming context has to have the special object key
    Duncan> "NameService", so it is created in the magical
    Duncan> "omniINSPOA", which uses the object id as the object key.

    Duncan> The omniINSPOA is also used for backwards compatibility
    Duncan> with log files created with omniORB 2.x, so it can create
    Duncan> objects with the correct 12-byte object keys.

    Duncan> Cheers,

    Duncan> Duncan.

    Duncan> -- -- Duncan Grisby \ Research Engineer -- -- AT&T
    Duncan> Laboratories Cambridge -- --
    Duncan> http://www.uk.research.att.com/~dpg1 --
Thanks Duncan

Another question : what would be the long way to
create the special object key "NameService" without
using the omniINSPOA.

Another question -> does the RootPOA have an AdapterActivator?

Jon