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

[Jules Colding <colding omesc com>]

On Tue, 2005-01-18 at 09:51 -0500, Nick_Gianakas sybari com wrote:
> Hi All,
> 
> I'm trying to implement a C client using ORBit2 which calls a servant and 
> provides another interface as an argument.
> 
> Stripped-down pseudo-IDL:
> 
> 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.

> I have a client and server working using C++ (TAO).
> I'm trying to write a client using C to interact w/ the same C++ server.

Which is exactly what I am doing with Brutus/ORBit2.

> 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.

> 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? Have you remembered to activate the
POA in the client??

A POA which has not been activated yet would keep queuing requests. The
calling process would eventually get a timeout exception. 

> Any ideas?
> 
> Jules Colding:  I noticed a post from you on 11 Jan 2005 Re: "Linking 
> problem with servant implementation files" which posted an IDL example w/ 
> the same semantics (ie. one interface's method took another interface as a 
> param).  Did you implement a client for that example?

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.

Best regards,
  jules