[omniORB] NS registration procedure question

Duncan Grisby duncan at grisby.org
Mon Nov 21 12:53:02 GMT 2005


On Sunday 20 November, Sean Parker wrote:

>   I have several servers I connect to the Name Service.
>   Let's call them B and C which extend type A:
> 
>                   A
>                  / \
>                 B   C
> 
>   Both impls of B and C are registered with the NS as impls
> of B and C respectively. When in B, I get C's ref from the
> NS, I have no problem narrowing to an 'A' but when I narrow
> to a 'C' it gives a nil reference. 

The naming service is not involved in type checking and narrowing.
Whatever the problem is, it has nothing to do with the naming service.
All the naming service does is map names to object references.

The types of interfaces are named with "repository ids". For your
interface C, the repository id is IDL:C:1.0.

Object references embed a repository id, naming an interface they
support. Normally, it is the most-derived interface. So, when your C
object reference is registered in the naming service, it would normally
have the repository id IDL:C:1.0 embedded in it.

Now, when you come to narrow the object reference you get from the
naming service, the target type (IDL:C:1.0) is compared with what's
inside the object reference. If they match, the narrow succeeds
immediately. I would expect that to happen in your case.

If the types do not match, but the ORB knows the types are compatible,
as would be the case of narrowing a C reference to A, again the narrow
will succeed.

If the ORB does not know whether the types match, it performs a remote
call to the object to ask it, calling its _is_a() method. The remote
object replies true or false, and the narrow therefore succeeds or
fails, depending on whether the object really does support the interface
or not.

Notice that the naming service is not involved in any of this.

So, to understand why your narrows are failing, we need to know what
repository ids are in the object references, and why the repository ids
are not matching. Run your code with command line arguments of
-ORBtraceLevel 25 -ORBtraceInvocations 1. That will print lots of
debugging, including information about the types of object references.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --



More information about the omniORB-list mailing list