J
Jeff Frontz
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.
I know that python has introspection that should make it possible to
not have to write (much) code every time an argument changes or a new
method is added [in the IDL]. But I don't understand enough of the
python binding for omniORB (or enough python) to know how to do this
easily (or whether an infrastructure already exists to do this).
I've inherited some code that I'm trying to morph into my test tool.
The problem is that I don't know how much is something that is stock
omniORB python support and how much is homebrew.
From what I'm seeing, it looks like an omniORB CORBA interface appears
in python as a class (that part seems likely 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.
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?
Thanks,
Jeff
[note: this was originally posted at stackoverflow
http://stackoverflow.com/questions/...ine-the-contents-of-a-corba-omniorb-interface
]
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.
I know that python has introspection that should make it possible to
not have to write (much) code every time an argument changes or a new
method is added [in the IDL]. But I don't understand enough of the
python binding for omniORB (or enough python) to know how to do this
easily (or whether an infrastructure already exists to do this).
I've inherited some code that I'm trying to morph into my test tool.
The problem is that I don't know how much is something that is stock
omniORB python support and how much is homebrew.
From what I'm seeing, it looks like an omniORB CORBA interface appears
in python as a class (that part seems likely 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.
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?
Thanks,
Jeff
[note: this was originally posted at stackoverflow
http://stackoverflow.com/questions/...ine-the-contents-of-a-corba-omniorb-interface
]