AW: [omniORB] activate_object_with_id Returns None

Thu Apr 24 17:10:57 BST 2008

Hi Michael,

when you try out the corbaloc approach, make sure the following is true:

1.	the servant gets activated in omniINSPOA with a defined object
id string, TestIntf in my example 
2.	omniINSPOA's POAManager is activated
3.	the server listens on a defined endpoint, :::12345 in my
example, which is equivalent to giop:tcp:localhost:12345
4.	the client uses exactly the same endpoint and object id string
in it's corbaloc reference, here corbaloc:iiop:localhost:12345/TestIntf
5.	obvious, but: client narrows it's object reference to the same
interface that the servant implements.

Cheers

Clemens

________________________________

Von: omniorb-list-bounces at omniorb-support.com
[mailto:omniorb-list-bounces at omniorb-support.com] Im Auftrag von Marco
Ferreira
Gesendet: Donnerstag, 24. April 2008 15:29
An: omniorb-list at omniorb-support.com
Betreff: Re: [omniORB] activate_object_with_id Returns None

Hello Michael.

First, I'm using Python to implement this server.

Michael wrote: 

Hi Marco,

didn't really follow the thread, but

Marco Ferreira wrote:

	Thanks for all the replies.

	I have tried different ways to get to the result I want, but the
problem
	pressists.

	Needed result: to be able to contact the corba objects through
corbaloc
	URI's

	Solution one:
	    Use the omniINSPOA POA
	Problem:
	    Can't get the client to touch the objects (OBJECT_NOT_EXIST)

Did you try sth like this?

CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);

PortableServer::POAManager_var pman = rootpoa->the_POAManager();
PortableServer::LifespanPolicy_var lifespan2 =
rootpoa->create_lifespan_policy(PortableServer::PERSISTENT);
PortableServer::IdAssignmentPolicy_var assign =
rootpoa->create_id_assignment_policy(PortableServer::USER_ID);

CORBA::PolicyList policy_list;
policy_list.length(2);
policy_list[0] = PortableServer::LifespanPolicy::_duplicate(lifespan2);
policy_list[1] = PortableServer::IdAssignmentPolicy::_duplicate(assign);

CORBA::Object_var obj = orb->resolve_initial_references("omniINSPOA");
PortableServer::POA_var omniINSPOA=PortableServer::POA::_narrow(obj);

MyImpl* m = new MyImpl();
PortableServer::ObjectId_var myId =
PortableServer::string_to_ObjectId("SomeObjectId")
omniINSPOA->activate_object_with_id(myId, m);

pman = omniINSPOA->the_POAManager();
pman->activate();
orb->run();

Then start the server using a fixed endpoint:
startmyserver -ORBendPoint giop:tcp:127.0.0.1:11173

and access it through a corbaloc uri:
corbaloc::127.0.0.1:11173/SomeObjectId

On my searches I have came across the solution you just suggested, thing
is 

PortableServer doesn't have any method by the name "string_to_ObjectId".
I'd think it's missing cause it's useless on python?

Anyway, i did try something like that, but client always got
object_not_exist.

Using omniMapper, here part of it:
IncBaseServiceObjKey
IOR:010000001e00000049444c3a496e636f676e69746f2f42617365536572766963653a
312e30000000010000000000000064000000010102000e00000031302e3133382e313034
2e39310015dc0e000000feb16a0f48000053c50000000000000002000000000000000800
00000100000000545441010000001c000000010000000100010001000000010001050901
01000100000009010100

And here's what omniMapper daemon outputs:
omniORB: Server accepted connection from giop:tcp:10.138.104.91:44786
omniORB: AsyncInvoker: thread id = 2 has started. Total threads = 3
omniORB: Scavenger task execute.
omniORB: AsyncInvoker: thread id = 3 has started. Total threads = 3
omniORB: giopWorker task execute.
omniORB: Accepted connection from giop:tcp:10.138.104.91:44786 because
of this rule: "* unix,ssl,tcp"
omniORB: inputMessage: from giop:tcp:10.138.104.91:44786 118 bytes
omniORB: 
4749 4f50 0100 0100 6a00 0000 0100 0000 GIOP....j.......
0100 0000 0c00 0000 0100 0000 0100 0100 ................
0901 0100 0100 0000 0100 0000 1400 0000 ................
496e 6342 6173 6553 6572 7669 6365 4f62 IncBaseServiceOb
6a4b 6579 0600 0000 5f69 735f 6100 0000 jKey...._is_a...
0000 0000 1e00 0000 4944 4c3a 496e 636f ........IDL:Inco
676e 6974 6f2f 4261 7365 5365 7276 6963 gnito/BaseServic
653a 312e 3000                          e:1.0.
omniORB: Dispatching remote call '_is_a' to: key<IncBaseServiceObjKey>
(active)
Mapping `IncBaseServiceObjKey' to
IOR:010000001e00000049444c3a496e636f676e69746f2f42617365536572766963653a
312e30000000010000000000000064000000010102000e00000031302e3133382e313034
2e39310015dc0e000000feb16a0f48000053c50000000000000002000000000000000800
00000100000000545441010000001c000000010000000100010001000000010001050901
01000100000009010100
omniORB: Implementation of '_is_a' generated LOCATION_FORWARD.
omniORB: sendChunk: to giop:tcp:10.138.104.91:44786 172 bytes
omniORB: 
4749 4f50 0100 0101 a000 0000 0000 0000 GIOP............
0100 0000 0300 0000 1e00 0000 4944 4c3a ............IDL:
496e 636f 676e 6974 6f2f 4261 7365 5365 Incognito/BaseSe
7276 6963 653a 312e 3000 0000 0100 0000 rvice:1.0.......
0000 0000 6400 0000 0101 0200 0e00 0000 ....d...........
3130 2e31 3338 2e31 3034 2e39 3100 15dc 10.138.104.91...
0e00 0000 feb1 6a0f 4800 0053 c500 0000 ......j.H..S....
0000 0000 0200 0000 0000 0000 0800 0000 ................
0100 0000 0054 5441 0100 0000 1c00 0000 .....TTA........
0100 0000 0100 0100 0100 0000 0100 0105 ................
0901 0100 0100 0000 0901 0100           ............
omniORB: Server connection refcount = 1
omniORB: Server connection refcount = 0
omniORB: Server close connection from giop:tcp:10.138.104.91:44786

		Solution two:
		    Use omniMapper to map the object names to correct
IOR's
		Problem:
		    When client contacts the corbaloc URI, omniMapper
stays on some kind
		of infinite loop with return LOCATION_FORWARD

	Same problem imho, the location_forward is created because of
object_not_exist

		I've tried your example Fischer, and some more while
googling, and they
		all work.
		Mine just seems to want to be left alone in the corner
:|

		_______________________________________________
		omniORB-list mailing list
		omniORB-list at omniorb-support.com

http://www.omniorb-support.com/mailman/listinfo/omniorb-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20080424/7884a4bb/attachment-0001.htm