The directory /opt/www/bruyninckxh2/web/tmp/drutex-5ebb8cacdb292c6b64d119b01ff447f0-1 has been created.

[Bug 520] New: getMethod<...>("name") does not work for remote/ CORBA components

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.

[Bug 520] getMethod<...>("name") does not work for remote/CORBA

For more infomation about this bug, visit

Peter Soetens

<peter [dot] soetens [..] ...> changed:

What |Removed |Added
--------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

--- Comment #1 from Peter Soetens

<peter [dot] soetens [..] ...> 2008-02-27 22:29:47 ---
Fixed on trunk.

$ svn ci -m\"Fix bug #520: getMethod<...>(\\"name\\") does not work for remote/
CORBA components\"
Sending rtt/config/global_setup.cmake
Sending rtt/src/CommandRepository.hpp
Sending rtt/src/DataSourceStorage.hpp
Sending rtt/src/Method.hpp
Sending rtt/src/MethodC.cpp
Sending rtt/src/MethodC.hpp
Sending rtt/src/MethodRepository.hpp
Adding rtt/src/RemoteMethod.hpp
Sending rtt/src/targets/target.in
Transmitting file data .........
Committed revision 28999.

and

$ svn ci -m"Fix bug #520: getMethod<...>(\"name\") does not work for remote/
CORBA components - unit tests."
Sending rtt/tests/corba_test.cpp
Sending rtt/tests/corba_test.hpp
Sending rtt/tests/generictask_test.cpp
Sending rtt/tests/generictask_test.hpp
Sending rtt/tests/generictask_test_2.cpp
Sending rtt/tests/generictask_test_2.hpp
Transmitting file data ......
Committed revision 29000.