[omniORB] Dynamic Skeleton Interface and omniORBpy 2.3

[baileyk at schneider.com]

One can dynamically create servant classes if needed, just using the
dynamic nature of Python itself.  omniORBpy also has a method for
dynamically importing raw IDL source.  For example, in unit test setup code
I can do this

   idltext = \
   """
   module IMR_ObjTest {
      interface Tester {
         string run( in string arg0, out string arg1 );
      };
   };
   """
   mods = omniORB.importIDLString( idltext )
   import IMR_ObjTest, IMR_ObjTest__POA

Unfortunately, the mods variable does not include the "IMR_ObjTest__POA"
module name.  I think it should, but all I get is ["IMR_ObjTest"].
However, both modules get added to sys.modules just fine.

Once the skeleton class is created, you can generate Python code on the fly
to subclass from it and implement all the methods.  There may be a better
way to do the following, but here's an example that has worked for me so
far with omniORBpy...

   servantTypeName="GenericWrapper"
   servantTypeString = """
   class %s( servant_baseClass ):

      def __init__(self, oref, filter):
         self.oref = oref
         self.filter = filter

      def methodWrap( self, opName, args ):
         filtered_args = self.filter.filter_input(self.oref,opName, args)
         result = getattr(self.oref, opName)( *filtered_args )
         filtered_result = self.filter.filter_output(self.oref, opName,
result)
         return filtered_result

   """ % servantTypeName

   servantMethodTemplate = """
      def %(opName)s(self, *args):
         result = self.methodWrap( '%(opName)s', args )
         return result
   """

   def wrapRef( objref, filterObj = ObjRefFilter() ):
      cls = objref.__class__
      clsname = cls.__name__
      if clsname.startswith("_objref_") :
         clsname = clsname[8:]
      mod = cls.__module__ + "__POA"
      exec "import %s" % mod in locals()
      mod = sys.modules[ mod ]
      servant_baseClass = mod.__dict__[ clsname ]
      servantCode = servantTypeString + reduce(operator.add,
          [ (servantMethodTemplate % {'opName':i} )
             for i in objref.__methods__ if not i.startswith("_") ]  )
      print "creating servant class with code:\n%s" % servantCode
      exec servantCode
      servantClass = locals()[servantTypeName]
      servant = servantClass( objref, filterObj )
      return servant

The context here is that I'm trying to wrap a remote object reference with
a servant class that forwards calls to the remote object, but perhaps does
logging/conversion of arguments/return values (done by a filterObj above).
The above gets the skeleton class ( servant_baseClass ) from the object
reference, but could just as well get it from the previous example of
dynamically loaded IDL code.

I suspect the ease of doing the sorts of things I've shown here was a
motivating factor for leaving out the DII/DSI.  Just my guess.

Kendall




                                                                                                                                           
                      Kevin Wooten                                                                                                         
                      <KevinW at rainbowstudios.com>          To:       'David Fugate' <dfugate at nrao.edu>, omniorb-list at omniorb-support.com   
                      Sent by:                             cc:                                                                             
                      omniorb-list-bounces at omniorb-        Fax to:                                                                         
                      support.com                          Subject:  RE: [omniORB] Dynamic Skeleton Interface and omniORBpy 2.3            
                                                                                                                                           
                                                                                                                                           
                      12/09/2003 10:23 AM                                                                                                  
                                                                                                                                           
                                                                                                                                           




omniORBpy's notes also say that DII is not supported; that is dynamic
invocation. DSI is probably included. If you can't import it, try to search
for it in the omniORBpy dir tree. My hunch is that it is not supported.

Cheers,
Kevin

-----Original Message-----
From: David Fugate [mailto:dfugate at nrao.edu]
Sent: Tuesday, December 09, 2003 7:03 AM
To: omniorb-list at omniorb-support.com
Subject: [omniORB] Dynamic Skeleton Interface and omniORBpy 2.3

Hi everyone, I've been trying unsuccessfully to use the
DynamicImplementation class (defined in section 1.5.2 of the Python
Language Mapping, v1.2) which should be in PortableServer.  It looks as
if this has not been implemented in the Python ORB:
    bash-2.05$ python -i
    Python 2.3 (#1, Nov  4 2003, 10:32:32)
    [GCC 3.2.1] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from omniORB.PortableServer import DynamicImplementation
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ImportError: cannot import name DynamicImplementation
    >>> import omniORB.PortableServer
    >>> import PortableServer.DynamicImplementation
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ImportError: No module named DynamicImplementation
    >>>

Looking over omniORBpy's release notes, it states that "interceptors"
are not available to Python code.  Is DynamicImplementation an
interceptor and if not, how is it used?

Thanks in advance for your replies,

David Fugate
National Radio Astronomy Observatory