[omniORB] type checking

[Michael Brenner]

Hi,

I'm calling a python server from a java client. Is there a way I can type check
the return values in python, ie assert that they confirm to the out parameters
specified in the IDL, and die gracefully (and with a helful message) if they
don't? Right now, I'm getting org.omg.CORBA.BAD_PARAM errors - which don't give
me any clue about what went wrong.

Cheers,

michael

[Ridgway, Richard (London)]

I use something like this decorator (borrowed from pyExcelerator. I
think I've seen similar but more convoluted example in zope?). Not quite
what you want, but maybe workable.

def returns(t):
def check_returns(f):
def new_f(*args,**kwds):
val = f(*args,**kwds)
assert isinstance(val,t)
return val
return new_f
return check_returns

@returns(str)
def bob():
return "string"

@returns(str)
def bob_not_str():
return 1

bob()

'string'

bob_not_str()

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 5, in new_f
AssertionError



-----Original Message-----
From: omniorb-list-***@omniorb-support.com
[mailto:omniorb-list-***@omniorb-support.com] On Behalf Of Michael
Brenner
Sent: 03 July 2008 17:39
To: omniorb-***@omniorb-support.com
Subject: [omniORB] type checking


Hi,

I'm calling a python server from a java client. Is there a way I can
type check
the return values in python, ie assert that they confirm to the out
parameters
specified in the IDL, and die gracefully (and with a helful message) if
they
don't? Right now, I'm getting org.omg.CORBA.BAD_PARAM errors - which
don't give
me any clue about what went wrong.

Cheers,

michael

_______________________________________________
omniORB-list mailing list
omniORB-***@omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
--------------------------------------------------------

This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
--------------------------------------------------------

[Michael Brenner]

Thanks, Richard. But, you specify the return types by hand, right? Given that
they are already defined in the IDL I had thought there was a way to access them
directly somehow. However, the only thing I have is pthe ython stubs generated
by omniIDL -bpython. And those are very underspecified, so can't really be used
for type checking (I think, but hope to be proven wrong).

Cheers,

michael

Post by Ridgway, Richard (London)
I use something like this decorator (borrowed from pyExcelerator. I
think I've seen similar but more convoluted example in zope?). Not quite
what you want, but maybe workable.
val = f(*args,**kwds)
assert isinstance(val,t)
return val
return new_f
return check_returns
@returns(str)
return "string"
@returns(str)
return 1

Post by Ridgway, Richard (London)
bob()

'string'

Post by Ridgway, Richard (London)
bob_not_str()

File "<stdin>", line 1, in <module>
File "<stdin>", line 5, in new_f
AssertionError
-----Original Message-----
Brenner
Sent: 03 July 2008 17:39
Subject: [omniORB] type checking
Hi,
I'm calling a python server from a java client. Is there a way I can
type check
the return values in python, ie assert that they confirm to the out
parameters
specified in the IDL, and die gracefully (and with a helful message) if
they
don't? Right now, I'm getting org.omg.CORBA.BAD_PARAM errors - which
don't give
me any clue about what went wrong.
Cheers,
michael
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
--------------------------------------------------------
This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
--------------------------------------------------------

[Duncan Grisby]

Post by Michael Brenner
Thanks, Richard. But, you specify the return types by hand, right?
Given that they are already defined in the IDL I had thought there was
a way to access them directly somehow. However, the only thing I have
is pthe ython stubs generated by omniIDL -bpython. And those are very
underspecified, so can't really be used for type checking (I think,
but hope to be proven wrong).

All the information about the expected types is in the generated code.
That's how omniORB can send the BAD_PARAM exceptions you're seeing. You
can get some clue about what was expected by running with
-ORBtraceExceptions 1, which will tell you where in the C++ code of
omniORBpy the exception was thrown, which will allow you to work out
what type it was looking for.

A Python-level decorator that optionally checked things first would be
great, since it would be able to report much clearer errors. Any
volunteers?

Cheers,

Duncan.

[Ridgway, Richard (London)]

In a function on the server this tells you the desired return
parameters: self._omni_op_d[sys._getframe().f_code.co_name][1]

I can't quite put it all together with the decorator as I don't
understand how the omniorbpy typecodes work. A string return is fine for
idl sequence<octet> - but how do I know that?. I can get the typecode of
my returning value, just don't know how to test for equivalence. There's
probably a call hidden away in omniorb, I just can't see it. Duncan?

Richard


-----Original Message-----
From: Duncan Grisby [mailto:***@grisby.org]
Sent: 04 July 2008 18:48
To: Michael Brenner
Cc: Ridgway, Richard (London); omniorb-***@omniorb-support.com
Subject: Re: [omniORB] type checking

Post by Michael Brenner
Thanks, Richard. But, you specify the return types by hand, right?
Given that they are already defined in the IDL I had thought there was
a way to access them directly somehow. However, the only thing I have
is pthe ython stubs generated by omniIDL -bpython. And those are very
underspecified, so can't really be used for type checking (I think,
but hope to be proven wrong).

All the information about the expected types is in the generated code.
That's how omniORB can send the BAD_PARAM exceptions you're seeing. You
can get some clue about what was expected by running with
-ORBtraceExceptions 1, which will tell you where in the C++ code of
omniORBpy the exception was thrown, which will allow you to work out
what type it was looking for.

A Python-level decorator that optionally checked things first would be
great, since it would be able to report much clearer errors. Any
volunteers?

Cheers,

Duncan.

[Duncan Grisby]

Post by Ridgway, Richard (London)
In a function on the server this tells you the desired return
parameters: self._omni_op_d[sys._getframe().f_code.co_name][1]
I can't quite put it all together with the decorator as I don't
understand how the omniorbpy typecodes work. A string return is fine for
idl sequence<octet> - but how do I know that?. I can get the typecode of
my returning value, just don't know how to test for equivalence. There's
probably a call hidden away in omniorb, I just can't see it. Duncan?

The code in omniORBpy that does the type checking is all in C++, mostly
in pyMarshal.cc. There isn't any Python code to do it.

The type descriptors are basically tuple representations of the CORBA
TypeCodes. Exactly what's in each tuple is documented in the comments in
pyMarshal.cc. e.g.:

static void
validateTypeStruct(PyObject* d_o, PyObject* a_o,
CORBA::CompletionStatus compstatus,
PyObject* track)
{ // class, repoId, struct name, name, descriptor, ...

Which shows (with a little interpretation) that in the descriptor tuple
for a struct, there's the Python class, then the repository id, then the
struct name, then a repeating list of member names and type descriptors
for the members. All the tuples start with the TypeCode kind, which
isn't listed in the comments. Simple types with no extra data are
represented as just the integer TypeCode kind, rather than a tuple.

Does that make sense?

Cheers,

Duncan.