[omniORB] How to pass sequence<any> as parameter from Python
Joel Wagner
Joel.Wagner at veritas.com
Mon Apr 12 18:10:17 BST 2004
Alex,
You were right. Some of the more tedious data structures I'm using were not
being constructed thoroughly enough. Looks like you have to explicitly
initialize all members of an IDL struct (I guess I was expecting 0's or
empty strings for the ones I didn't explicitly initialize but I understand
why that might not be a good thing). Also, any arrays of an IDL struct must
be initialized with a Python list that is the exact length of the array.
These initialization errors were pretty easy to see for the small example
structs I started out with. It was a bit more difficult to track down for
the larger data structures used by the real server.
Thanks for your help.
Joel
-----Original Message-----
From: Alex Tingle [mailto:alex.omniorb at firetree.net]
Sent: Monday, April 12, 2004 1:13 PM
To: Joel Wagner
Cc: omniorb-list at omniorb-support.com
Subject: Re: [omniORB] How to pass sequence<any> as parameter from Python
Joel,
Joel Wagner <Joel.Wagner at veritas.com> wrote:
> When I tried using the omniORB Python client against a TAO C++ server
> I'm back to getting BAD_PARAM_WrongPythonType. I am able to
> successfully call between the omniORB Python client and the TAO C++
> server using other data types, just having trouble with sequence<any>.
>
> Turning on some of the trace flags I see the following interesting
> info:
>
> omniORB: Invoke 'Execute' on remote:
> key<0x14010f0052535461c57a4067500e00020000000100000003000000>
> omniORB: throw BAD_PARAM from pyMarshal.cc:421
> (NO,BAD_PARAM_WrongPythonType)
> Traceback (most recent call last):
> File "./mdm_query_machine", line 92, in ?
> resp, out_any_seq = databaseview.Execute(0x02000000L,
> in_any_seq)
> File "/home/jwagner/omnitest/mdmapi_idl.py", line 169, in
> Execute
> return _omnipy.invoke(self, "Execute",
> _0_Veritas.MDM.DatabaseView._d_Execute, args)
> omniORB.CORBA.BAD_PARAM: Minor: BAD_PARAM_WrongPythonType,
> COMPLETED_NO.
Is the client code identical in the two scenarios? This error looks like
it's happening before the request is dispatched to the server, so it should
fail the same way whether the server is omniORB, TAO or whatever.
You can confirm this by turning the trace level right up and watching for
the outgoing message. Or try the same client code against a dummy server
written in Python.
If I'm right, then the fact that the server is TAO this time is a red
herring - you are just constructing one or more of your Anys incorrectly.
If I'm wrong and the problem is between omniORB & TAO, then you could look
at omniORB's lowest common denominator (lcd) mode. That might help
interoperability. There are other -ORB options that might help too - check
out the documentation.
-Alex Tingle
More information about the omniORB-list
mailing list