AW: [omniORB] activate_object_with_id Returns None

Thu Apr 24 18:39:30 BST 2008

Hi Marco,

take a closer look at activate_object_with_id.

The first parameter must be an object id string, the second one a
servant object (a python object).

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 17:29
An: Michael
Cc: omniorb-list at omniorb-support.com
Betreff: Re: [omniORB] activate_object_with_id Returns None

Sorry, I can't do that since it's corporate material.

I've re-written my code again to handle the omniINSPOA, here's a sample
of the code:

    poa = orb.resolve_initial_references("omniINSPOA")
    poa._get_the_POAManager().activate()

    base_service_inst = BaseService_i(poa, client_orb)
    (...)
    log.debug("Activating objects:")
    for servant in interface_inst_list:
        log.debug(" ...%s"% servant)
        poa.activate_object_with_id(servant,
interface_inst_list[servant])

    # Block for ever (or until the ORB is shut down)
    orb.run()

Issues:

*	The server .py uses optparse to handle command line options
(like debugging), so i can't use that "-ORBendPoint :::12345".

	Do i really need to set it? If so, is there another way to do
so?

*	I still can't touch server objects:

	>>> obj =
orb.string_to_object("corbaloc::127.0.0.1/IncBaseServiceObjKey")
	>>> obj = obj._narrow(interface.Incognito.BaseService)
	omniORB: Invoke '_is_a' on remote: key<IncBaseServiceObjKey>
	Traceback (most recent call last):
	  File "<stdin>", line 1, in <module>
	  File "/usr/lib/python2.5/site-packages/omniORB/CORBA.py", line
667, in _narrow
	    return _omnipy.narrow(self, dest._NP_RepositoryId)
	omniORB.CORBA.TRANSIENT: Minor: 0x41540002, COMPLETED_NO.

Michael wrote: 

Hi Marco,

could you provide your source code (stripped down IDL and python code).
Would make this a
lot easier. Which versions of omniorb are ou using (4.1.2 and py 3.2?)

You're right about string_to_objectid - it's not needed in python, you
can just pass
strings as objectids.

cheers
michael

Marco Ferreira wrote:

	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

------------------------------------------------------------------------

	_______________________________________________
	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/f3c4f576/attachment-0001.htm