Re: [openorb-devel] corbaloc:: bug ?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi Steve,

On Tue, 2002-05-28 at 12:09, Stephen McConnell wrote:
> 
> When creating a corbaloc reference, for example:
> 
>     String url = "corbaloc:iiop:1....@ho...:1234/widget";
>     org.omg.CORBA.Object object;
>     object = orb.string_to_object( url );
> 
> So far so good - if I print out the object ref I get:
> 
>     Binding information for object class org.openorb.CORBA.ObjectStub:ca208
>     IOR #0 (orginal IOR)
>     Published RepoID:
>     Bound profiles: 1
>     Profile #0 endpoint: iiop:1....@ho...:1234
>     Corbaloc Object Key: widget
> 
> However, there is a problem when attempting to go any further.
> Basically the object refernence has no type identifiers which means
> that it is impossible to (a) resolve any type information with a
> function such as _ids(), or (b) narrow the reference to anything
> even if you know the type of the object (because narrow calls
> _is_a( String id ) and that function (in this context) never
> returns (which seems reasonable to class as a bug). It would seem
> to me more resonable for the implementation of the _ids operation
> to attempt to resolve the types based on the endpoint and object
> key.  Which leads me to the question ... (1) are these conclusions
> reasonable - and (2) any ideas on how to resolve and set the type
> ids from the endpoint and key info ?

I can't see any problem !

I started the TNS with the following command:

[mru@ppro NamingService]$ java
    -Dorg.omg.CORBA.ORBClass=org.openorb.CORBA.ORB
    -Dorg.omg.CORBA.ORBSingletonClass=org.openorb.CORBA.ORBSingleton
    org.openorb.tns.Server -print
  Transient naming service activated.
  Corbaloc Reference:
  corbaloc:iiop:1....@pp...:33045/NameService

The attached client app just performs a narrow on the object reference
created from the corbaloc URL above.
The following debug output makes clear that the first call to the server
is the _is_a() method. This is called because no repository id
information is available from the corbaloc URL. The server recognizes
that the object key is not complete and therefore sends a reply with a
LOCATION_FORWARD reply status. When the client ORB receives the reply
it  automatically reissues the request with the new endpoint
information, i.e. the complete IOR of the server object.

However I didn't notice any lock up of the client with the attached
example client.

Hope this helps,

    Michael

[main] [DEBUG] (orb.ldr#2951274): ClientChannel: (iiop)
ppro.home.net:33045 created
Binding information for object class org.openorb.CORBA.ObjectStub:4bfe9d
IOR #0 (orginal IOR)
Published RepoID: 
Bound profiles: 1
Profile #0 endpoint: iiop:1....@pp...:33045
Corbaloc Object Key: NameService

[main] [DEBUG] (orb.ldr#2951274): Resolved initial reference
"CodecFactory" from reference table.
IOR:00000000000000010000000000000001000000000000002C000102000000000E7070726F2E686F6D652E6E65740081150000000B4E616D65536572766963650000000000
[main] [DEBUG] (orb.ldr#2951274): ClientChannel: (iiop)
ppro.home.net:33045 request #2 created
[main] [DEBUG] (orb.ldr#2951274): ClientChannel: (iiop)
ppro.home.net:33045 (33067 -> 33045) opened
[main] [DEBUG] (orb.ldr#2951274): New encodings for output stream set to
[ISO-8859-1] and [null].
[main] [DEBUG] (orb.ldr#2951274): 
------------------------------------------------------
( Sending message ) Displaying a buffer, size = 103
------------------------------------------------------
GIOP.... ...[....  47494F50 01020000 0000005B 00000002
........ ....Name  03000000 00000000 0000000B 4E616D65
Service. ...._is_  53657276 69636500 00000006 5F69735F
a....... ...+IDL:  61000000 00000000 0000002B 49444C3A
omg.org/ CosNamin  6F6D672E 6F72672F 436F734E 616D696E
g/Naming ContextE  672F4E61 6D696E67 436F6E74 65787445
xt:1.0.            78743A31 2E3000
------------------------------------------------------

[Receive Worker for ClientChannel: (iiop) ppro.home.net:33045 (33067 ->
33045)] [DEBUG] (orb.ldr#2951274): 
------------------------------------------------------
( Incoming message ) Displaying a buffer, size = 184
------------------------------------------------------
GIOP.... ...?....  47494F50 01020001 000000AC 00000002
........ ...+IDL:  00000003 00000000 0000002B 49444C3A
omg.org/ CosNamin  6F6D672E 6F72672F 436F734E 616D696E
g/Naming ContextE  672F4E61 6D696E67 436F6E74 65787445
xt:1.0.. ........  78743A31 2E300000 00000001 00000000
...d.... ....ppro  00000064 00010200 0000000E 7070726F
.home.ne t.......  2E686F6D 652E6E65 74008115 0000001B
.OO..?.. ?...POA?  004F4F01 8DDD0D19 EE000000 504F41FE
NameServ _0?.....  4E616D65 53657276 5F30FE00 00000001
.......  ........  00000001 00000020 00000000 00010001
........ ... ....  00000002 0001000F 00010020 00010109
........            00000001 00010100 
------------------------------------------------------

[Receive Worker for ClientChannel: (iiop) ppro.home.net:33045 (33067 ->
33045)] [DEBUG] (orb.ldr#2951274): New codesets for input stream set to
[ISO-8859-1] and [null].
[Receive Worker for ClientChannel: (iiop) ppro.home.net:33045 (33067 ->
33045)] [DEBUG] (orb.ldr#2951274): ClientChannel: (iiop)
ppro.home.net:33045 (33067 -> 33045)request #2 last reply fragment
received
[main] [DEBUG] (orb.ldr#2951274): ClientChannel: (iiop)
ppro.home.net:33045 (33067 -> 33045) request #2 last fragment sent
[main] [DEBUG] (orb.ldr#2951274): ClientChannel: (iiop)
ppro.home.net:33045 created
[main] [DEBUG] (orb.ldr#2951274): ClientChannel: (iiop)
ppro.home.net:33045 request #6 created
[main] [DEBUG] (orb.ldr#2951274): ClientChannel: (iiop)
ppro.home.net:33045 (33068 -> 33045) opened
[main] [DEBUG] (orb.ldr#2951274): New encodings for output stream set to
[ISO-8859-1] and [UTF-16BE].
[main] [DEBUG] (orb.ldr#2951274): 
------------------------------------------------------
( Sending message ) Displaying a buffer, size = 143
------------------------------------------------------
GIOP.... ........  47494F50 01020000 00000083 00000006
........ .....OO.  03000000 00000000 0000001B 004F4F01
.?..?... POA?Name  8DDD0D19 EE000000 504F41FE 4E616D65
Serv_0?. ...._is_  53657276 5F30FE00 00000006 5F69735F
a....... ........  61000000 00000001 00000001 0000000C
........ ........  00000000 00010001 00010109 00000000
...+IDL: omg.org/  0000002B 49444C3A 6F6D672E 6F72672F
CosNamin g/Naming  436F734E 616D696E 672F4E61 6D696E67
ContextE xt:1.0.   436F6E74 65787445 78743A31 2E3000
------------------------------------------------------

[Receive Worker for ClientChannel: (iiop) ppro.home.net:33045 (33068 ->
33045)] [DEBUG] (orb.ldr#2951274): 
------------------------------------------------------
( Incoming message ) Displaying a buffer, size = 25
------------------------------------------------------
GIOP.... ........  47494F50 01020001 0000000D 00000006
........ .         00000000 00000000 01
------------------------------------------------------

[Receive Worker for ClientChannel: (iiop) ppro.home.net:33045 (33068 ->
33045)] [DEBUG] (orb.ldr#2951274): New codesets for input stream set to
[ISO-8859-1] and [UTF-16BE].
[Receive Worker for ClientChannel: (iiop) ppro.home.net:33045 (33068 ->
33045)] [DEBUG] (orb.ldr#2951274): ClientChannel: (iiop)
ppro.home.net:33045 (33068 -> 33045)request #6 last reply fragment
received
[main] [DEBUG] (orb.ldr#2951274): ClientChannel: (iiop)
ppro.home.net:33045 (33068 -> 33045) request #6 last fragment sent
id[0]=IDL:omg.org/CosNaming/NamingContextExt:1.0
id[1]=IDL:omg.org/CosNaming/NamingContext:1.0
Finished !!!!