[omniORB] omniORB.importIDL causes overwriting of classes

[Joshua Reynolds]

Hey all,
Just came upon some unexpected behaviour when using omniORB.importIDL to 
dynamically compile and import idl in our Python based environment.
Scenario:
had already loaded one normally generated idl file that defined an 
interface say foo.
\\filename: foo.idl
module foo
{
	interface foo
	{
	};
};

in python-space, dynamically loaded an idl file with an interface that 
inherits the foo's interface.
\\ filename: depend.idl
#include <foo.idl>
module depend
{
	interface depend: foo::foo
	{
	};
};

Then ...
dynamically load another module that inherits foo's interface
#include <foo.idl>
module depend2
{
	interface depend2: foo::foo
	{
	};
};


Problem:
Calling omniORB.importIDL("foo.idl")  was regenerating the  code for 
both files.
This is due to line  188 in omni/lib/python/omniORB/__init__.py  ( the 
body of inmport IDL ) that passes inline to the python
backend (this tells the compiler to generate stubs for all #included 
files)  The end result is these two files get smooshed together into one
big "inmemory" file.
The actual problem came trying to create an objectReference for depend.  
it was failing in the _0_foo.foo.__init__(self) call.
Reason:
During the second generation of the foo.idl ( via the 
omniORB.importIDL(depend.idl) call) , all of the _0_ modules are checked 
for existence (via the omniORB.openModule() call (creates a new module 
only if not present.) however the classes redefined in this module 
( with the exact same name space module paths as the ones that are 
already in memory (same genrated code ) are placed in the _0_ module 
( an alias for the actual module) thus overwriting the one already there 
and screwing anything up that inherited from it and wanted to call it's 
superclass constructor.

Our problem arose hen you try to call depend.__init__()  after you 
importIDL(depend2.idl).
There are now two different foo classes defined. the one that depend 
inherited from, and the one that exists as part of the sys.modules and 
was defined in depend2 generated code.

The solution we hacked was to remove the inline arg from the call to 
omniidl in the body of omniORB.importIDL(), but it would be nice to 
expose the ability to toggle that flag through to the clients of 
omniORB.importIDL().
Also I don't know if there should be some sort checking for class 
existence before overwriting them in the module ( I don't see this as 
being much of problem outside of the scope of having these dynamic blob 
files that have everything in them, but it would be nice to know you are 
about to do something probably really bad)

Thanks
--Joshua Reynolds