omniORB's NamingService

[Sai-Lai Lo]

Jörg Narr <jnarr@Comsys.DoFN.DE> writes:

> I did the following: I bound the server with a special name like aaa*
> where * is a unique number to a NamingContext. Before this 
> I look up the context for other servers with aaa and a unique number to
> retrieve their IOR's respectively their object implementation.
> Unfortunately I often got stringified IOR's I couldn't find in the
> omninames*.log file (with grep) and so calls to the retrieved 
> objects failed. My question now is: Can anybody tell me what the numbers
> IOR:*1 <ID> <KIND> <ncontext|nobject> IOR:*2 in the log-file
> are? 

It is not a good idea to try to decode what is in omninames*.log. Why not
getting the same information though the proper interface of the naming
service? 


> I saw that the first (*1) second (*2) IOR are different. When I
> print out the retrieved object with
> orb->object_to_string(retrieved_object) I get another IOR I can't find
> in the log-file, too.

To satisfy the alignment requirements of CDR, there are padding bytes
inside an IOR. These bytes are not initialised and are ignored by any
compliant ORB. Given 2 IORs that refers to the same object, the padding
bytes in the IORs may differ. The stringified form of an IOR is a hex dump
of an IOR and includes the padding bytes. Therefore, the stringified
version of 2 IORs may differ even if they are referring to the same object.

Regards,

Sai-Lai

-- 
E-mail:         S.Lo@orl.co.uk          |       Olivetti & Oracle Research Lab
                                        |       24a Trumpington Street
Tel:            +44 223 343000          |       Cambridge CB2 1QA
Fax:            +44 223 313542          |       ENGLAND