The Borland Application Server 4.5.1 sends the following GIOP request with the object key "NameService" from a corbaloc URL:

47 49 4f 50 01 02 00 00 00 00 00 60 00 00 00 96 GIOP...........?
03 00 00 00 00 00 00 00 00 00 00 0b 4e 61 6d 65 ............Name
53 65 72 76 69 63 65 00 00 00 00 06 5f 69 73 5f Service......is.
61 00 00 00 00 00 00 01 56 49 53 03 00 00 00 00 a.......VIS.....
00 00 00 28 49 44 4c 3a 6f 6d 67 2e 6f 72 67 2f ....IDL.omg.org.
43 6f 73 4e 61 6d 69 6e 67 2f 4e 61 6d 69 6e 67 CosNaming.Naming
43 6f 6e 74 65 78 74 3a 31 2e 30 00 Context.1.0.

This results in a OBJECT_NOT_EXIST exception for the following reason:

iiop/ORB process line 257:

ServerSubcontract sc =
   subcontractRegistry.getServerSubcontract(request.getObjectKey());

core/SubcontractRegistry line 126

A WireObjectKeyTemplate (used for foreign ORBs) is being used, so it checks the INSObjectKeyMap with the object key of "NameService".

In CosNaming/TransientNameService, the INSObjectKeyMap entry for NameService maps to the normal GenericPOAServerSC.

Then, in GenericPOAServerSC dispatch around line 88

        ObjectKeyTemplate oktemp = okey.getTemplate() ;
        int sId = oktemp.getServerId() ;

sId will always be -1 since WireObjectKeyTemplate always returns -1 for the Server ID. Thus, the request fails.

This will probably work for foreign ORBs that send a LocateRequest since iiop/ORB locate does some INS related handling with getINSReference. However, the INS spec ptc-00-08-07 13.6.7.4 notes that a corbaloc server implementation must be capable of handling GIOP Request as well as LocateRequest messages targeted at the URL.

Since we haven't had any testing with foreign ORBs before the Connectathon, this was not discovered earlier.