Re: IOR reference of ORbit2 not recognized by mico

[Hing-Wah Wan <50191914 ee cityu edu hk>]

On Wed, Mar 20, 2002 at 11:48:38AM +0000, Mark McLoughlin wrote:
> Hey,
> 
> On Wed, 20 Mar 2002, Hing-Wah Wan wrote:
> 
> >
> >         Unknown component 0x1
> >        ^^^^^^^^^^^^^^^^^^^^^
> > from the response in the mico mailing list,
> > it seem that mico fail to recognize the IOR because of this unknown
> > component ,bugs?
> 
> 	If mico doesn't recognise a component, it should ignore it.
> There is enough info in the other components for mico to connect to
> the object.
> 

I have no idea,but forwarded is the reply from mico list ,what do you think?

----- Forwarded message from Frank Pilhofer <520065607613-0001@t-online.de> -----

Envelope-to: hingwah@localhost
Delivery-date: Wed, 20 Mar 2002 19:52:13 +0800
From: 520065607613-0001@t-online.de (Frank Pilhofer)
To: Hing-Wah Wan <50191914@uxmail.cityu.edu.hk> 
Cc: mico-devel@mico.org
Subject: Re: [mico-devel] IOR reference generated by ORBit2 not recognized by mico      
Reply-To: Frank Pilhofer <fp@fpx.de>
Mail-Followup-To: Hing-Wah Wan <50191914@uxmail.cityu.edu.hk>,
        mico-devel@mico.org

Hing-Wah Wan wrote:
>
>        I find that the longer stringified object reference generated by
>       ORBit2 is not recognized by mico 2.3.7(test with iordump in
>       mico,which display error message "Illegal object reference"
>       here is one of the example of the stringfied object reference
>       not recoginized:
>                                                              
> bug in mico?                                                 
                                  
 No, bug in ORBit. They forgot to encapsulate code set information.
An analysis is attached. Maybe you want to post it as an ORBit bug
report?

        Frank


--
Frank Pilhofer  ...........................................  fp@fpx.de
It's not just the ups and downs that make life difficult, it's the
jerks. - Alfred E. Neuman

0000: 01 (little endian)
0001: 00 00 00 (padding)
0004: 2b 00 00 00 (length of type_id string)
0008: type_id string
      49 44 4c 3a 6f 6d 67 2e
      6f 72 67 2f 43 6f 73 4e 61 6d 69 6e 67 2f 4e 61
      6d 69 6e 67 43 6f 6e 74 65 78 74 45 78 74 3a 31
      2e 30 00
0033: 00 (padding)
0034: 04 00 00 00 (number of profiles)
                                                              45,1          21%
      first profile:
0038: 00 54 42 4f (profile id 1329746944: ???)
003c: 4c 00 00 00 (length of profile data)
0040: profile data:
      01 01 02 00 05 00 00 00 55 4e 49 58 00 00 00 00 ........UNIX....
      08 00 00 00 68 69 6e 67 77 61 68 00 26 00 00 00 ....hingwah.&...
      2f 74 6d 70 2f 6f 72 62 69 74 2d 68 69 6e 67 77 /tmp/orbit-hingw
      61 68 2f 6c 69 6e 63 2d 32 39 61 31 39 66 35 35 ah/linc-29a19f55
      38 36 32 33 30 00 00 00 00 00 00 00             86230.......
      second profile:
008c: 00 00 00 00 (profile id 0: TAG_INTERNET_IOP)
0090: 34 00 00 00 (length of profile data)
      start of encapsulated data
0094: 01 (little endian)
0095: 01 02 (IIOP Version 1.2)
0097: 00 (padding)
0098: 08 00 00 00 (length of host string)
009c: 68 69 6e 67 77 61 68 00 (host name)
00a4: f6 80 (port)
00a6: 00 00 (padding)
00a8: 18 00 00 00 (length of object key)
00ac: object key
      00 00 00 00
      3b a9 eb 0f 43 98 b0 c5 01 00 00 00 47 f8 e8 40
      33 3a 67 74
00c4: 00 00 00 00 (no components)
      end of IIOP profile encapsulated data
      third profile:
00c8: ca ae df ba (profile id 3135221450: ???)
00cc: 4c 00 00 00 (length of profile data)
00d0: profile data:
      01 01 02 00 26 00 00 00 2f 74 6d 70 2f 6f 72 62 ....&.../tmp/orb
      69 74 2d 68 69 6e 67 77 61 68 2f 6c 69 6e 63 2d it-hingwah/linc-
      32 39 61 31 39 66 35 35 38 36 32 33 30 00 00 00 29a19f5586230...
      18 00 00 00 00 00 00 00 3b a9 eb 0f 43 98 b0 c5 ........;...C...
      01 00 00 00 47 f8 e8 40 33 3a 67 74             ....G..@3:gt
      fourth profile:
011c: 01 00 00 00 (profile id 1: TAG_MULTIPLE_COMPONENTS)
0120: 3c 00 00 00 (length of profile data)
0124: 01 (little endian)
0125: 00 00 00 (padding)
0128: 02 00 00 00 (number of TaggedComponents in MultipleComponentProfile)
012c: 05 00 00 00 (ComponentId 5: TAG_COMPLETE_OBJECT_KEY)
0130: 18 00 00 00 (length of object key)
0134: 00 00 00 00 3b a9 eb 0f 43 98 b0 c5
      01 00 00 00 47 f8 e8 40 33 3a 67 74
014c: 01 00 00 00 (ComponentId 1: TAG_CODE_SETS)

According to "ORB Interoperability Architecture", 01-09-17 p. 13-44,
"Data within the code set component is represented as a structure
of type CodeSetComponentInfo, and is encoded as a CDR encapsulation."

A struct ComponentInfo does follow here:

      ForCharData:
0150: 01 00 01 05 (native_code_set: X/Open UTF-8)
0154: 00 00 00 00 (number of conversion_code_sets: 0)
      ForWcharData:
0158: 09 01 01 00 (native_code_set: UTF-16)
      00 00 00 00 (number of conversion_code_sets: 0)

However, this should be encapsulated, so the data is read as:

0150: 01 00 01 05 (length of encapsulated data)
0154: 00 (big endian)
0155: 00 00 00 (padding)
      ForCharData:
0158: 09 01 01 00 (native_code_set: ??? (because of big endianness))
015c: 00 00 00 00 (number of conversion_code_sets: 0)
      ForWcharData:
0160: (data stream ends)


----- End forwarded message -----