Re: Client calling servant with interface as param (attn: Jules Colding)

[Nick_Gianakas sybari com]

On Tue, 2005-01-18 at 09:51 -0500, Nick_Gianakas sybari com wrote:
> interface foo
> {
>    print();
> }
> 
> interface bar
> {
>    print(in foo f);
> }
> 
> So the client gets a reference to the servant interface (bar) and calls 
> print providing a local implementation of foo.  While servicing the 
call, 
> the server calls f.print().

> OK. Seems simple enough... The bar object is incarnated by the server
> and the foo object is incarnated by the client.
Correct.

> If I don't start the ORB in the client (CORBA_ORB_run), the servant gets 
a 
> TRANSIENT exception when it tries to call back into the provided foo 
> interface (f).

> TRANSIENT, if I remember correctly, is normally thrown if an IOR doesn't
> reference a living object, so this is to be expected.
Right.

> If I do start the ORB in the client (in a separate thread), the call to 
> the servant never returns to the client.  The servant never receives it, 

> either.

> So you are saying that the callback call to f.print() (from server to
> client) doesn't get to the client?
Actually, from what I can tell, the initial call never gets to the server 
(from client).  At least not into the servant.

> Have you remembered to activate the POA in the client??
As best I can tell, yes.  I followed one of the examples in the orbit2 
tutorial:
After initializing the ORB, I get the POA by resolving the initial 
reference to the "RootPOA" (CORBA_ORB_resolve_initial_references).
I then activate the manager (PortableServer_POA_get_the_POAManager), then 
activate it (PortableServer_POAManager_activate).

I'm not sure why the example releases (CORBA_Object_release) the POA 
manager immediately after activating it though.

> As said above.. I am currently porting my C++ sample application for
> Brutus into C (ORBit2) with the purpose of identifying technical issues
> before I start on the much harder task of giving Brutus support to
> Evolution. You can take a look when the porting efforts are done and
> tested (in a week or two).
> 
> Anyway, I have identified a few issues with the ORBit2 idl compiler and
> libIDL that might be useful for you. They are all committed to CVS, so
> please checkout HEAD and check the Changelog for the details.
Thanks for all your help.

Any chance you know of a working example which accomplishes what I'm 
trying to do?


Regards,
Nick G.