[omniORB] Using python to dynamically divine the contents of a
CORBA (omniORB) interface
Duncan Grisby
duncan at grisby.org
Fri Jan 20 18:18:38 GMT 2012
On Mon, 2012-01-16 at 00:09 -0500, Jeff Frontz wrote:
> I'm trying to write a self-maintaining test tool that can be used from
> the command line against a server via CORBA (omniORB). To start, I'd
> be happy with a tool that could describe the interface(s) that the
> server implements (e.g., essentially regenerating the IDL that defined
> the interfaces to begin with). From there, I'd grow it into something
> that could accept parameters, make the CORBA call, and print the
> results.
Assuming you have the IDL, it would probably be easier to start from the
IDL rather than trying to introspect the generated Python code. You
might like to look at the omniidl documentation:
http://omniorb.sourceforge.net/omni41/omniidl.html
[...]
> >From what I'm seeing, it looks like an omniORB CORBA interface appears
> in python as a class (that part seems likely standard).
It's part of the standard that for interface I, there's a Python
class-like thing named I, but there is not much else required in the
standard.
> The methods of
> said interface appear as members of this class--they are each tuples
> with naming that appears to be the method name from the IDL prefixed
> with _d_. The input parameters for a given interface method are
> described by said method's first tuple element; the second element
> describes the return values. Each element is another tuple of tuples,
> with each describing a successive parameter.
That's an omniORBpy implementation detail. It is unlikely to change in
future, but it could do.
> I'm hoping this reflects the implementation of omniORBpy. Assuming
> that it does, are there well-defined routines for
> interrogating/manipulating these interface class objects?
The data is there for omniORBpy's own purposes. It's not intended to be
used by other things, although there is nothing that would stop you. As
an implementation detail of omniORBpy, there's no stand-alone
documentation of the data. It's only documented inside the omniORBpy
source, in a combination of the IDL compiler back-end and the C++ code
that makes use of the type descriptor tuples.
Perhaps you could give an example of the kinds of things your code needs
to do?
Cheers,
Duncan.
--
-- Duncan Grisby --
-- duncan at grisby.org --
-- http://www.grisby.org --
More information about the omniORB-list
mailing list