For more infomation about this bug, visit
Summary: getMethod<...>("name") does not work for remote/CORBA
components
Product: RTT
Version: 1.4.0
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: Corba
AssignedTo: orocos-dev [..] ...
ReportedBy: peter [dot] soetens [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0

Created an attachment (id=243)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=243)
Adds full remote method/command invocation support + unit tests

As reported by a user:

Right now, I have a bunch of TaskContext's deployed with the
DeploymentComponent. This all works as expected.

I then tried to export my DeployementComponent object on the network. That
worked fine too and I could see my object on the TAO NameService using
/usr/bin/nslist (tao-utils).
Then, I created a separated (CORBA) client which retrieves a proxy to that
object using the ControlTaskProxy object. The proxy seemed to work OK since I
could retrieve the list of peers (which matched the list of TaskContexts that I
deployed server-side with my DeploymentComponent).

My problem is that I can't do the following:

Method m =
proxy->getPeer("Processor")->methods()->getMethod("doSomeStuff");
m(1);

I get a "No such method" error.

It is my understanding that methods of the peers of a ControlTaskProxy are
dynamically created on the client side meaning that my code should probably
work. Then again, I suppose I missed something obvious.

The 'obvious' thing was that this feature was only partially implemented and
never really finished. The work-around is using a MethodC object:

MethodC m = proxy->getPeer("Processor")->methods()->create("doSomeStuff");

long arg1 = 1;
m.arg( arg1 ); // takes reference to 'arg1'
arg1 = 2;
assert( m.ready() );
m.execute(); // uses '2'.

The real fix is in attachment and adds 'ORO_REMOTING' support for Methods and
Commands. Only methods have been fully unit tested so far, remote commands only
partially.