[omniORB] omniORBpy and module re-opening

[Michele Bini]

This is a multi-part message in MIME format.
--------------020405070206030203000800
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Pre-scriptum: If you are going to compile the attached idl files you 
need to run something like

	omniidl -I. -bpython A/ifA1.idl

I'm using omniORBpy 1.4 (without the available patch, but this shouldn't 
matter AFAIK). I beg your pardon if my example is a mess, but I was 
unable to make a simpler and clearer one.

I have 2 interfaces (ifA1 and ifA2) in IDL module A, each one declared 
in a different idl file. A third interface ifB1 derives from ifA1, so 
ifB1.idl #includes A/ifA1 (BTW, class derivation is not the central 
point here, IDL inclusion and module reopening is).

In the generated ifB1_idl.py the following code:

	import ifA1_idl

correctly imports ifA1 stubs, but then in ifA1_idl this code:

	_0_A = omniORB.openModule("A", "A/ifA1.idl")

in the end does the following:

	sys.modules[current] = newmod

(I slightly edited this last line for the sake of simplicity)

This is ok for ifB1_idl.py, but look at the output of test1.py: ifA2_idl 
is _never_ imported, although I explicitly import A. This should be no 
surprise as, when I import A from test1.py, sys.modules already contains 
"A": omniORB.openModule() added it, but surely it is inconvenient. Just 
to be sure run test2.py: importing A before B fixes the problem.

However troubles are not over. Have a look at test3.py (which, by the 
way, is a simplified example of my _real_ troubles). As sys.modules is 
global, it doesn't matter the syntactical order of imports in python 
source files, but the actual runtime order: importing test3b.py from 
test3.py makes it impossible to correctly import A in test3.py

I also tried placing explicit import ifA2_idl in various places in 
test3.py but, altough something from ifA2_idl is imported in module A, 
some other stuff isn't (ironically the symbol ifA2_idl isn't) and, 
despite this is not exercised by these examples, this messes things up 
and _narrow() doesn't work as expected.

Is this the expected behaviour of omniORBpy? Anybody has a 
workaround/suggestion?

--------------020405070206030203000800
Content-Type: application/octet-stream;
 name="test.tar.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="test.tar.gz"

H4sIAErhTjsAA+2YXWuDMBSGvW1+RUZvtpua70A3BvpHRj8sFawVq4My9t+XqLPtSturaOvO
g6DEgIHj83pi4HvOIUQQraU5E6LV6bnBI5ozLhURinqEUqKYh6X7pXleuStmOcbeJl6soyS6
OO/W/Qcl8ONVQCfxMnH3DEIJUUpcrr9QTf0lk0qb+YwL6mHibkkH/nn9N9tlmUQ4QF9oFKdF
lK9miwjbdwKjkRn7fkXm6HuVgCsq/1nP/svWf665qv1n4H8XHPmPDScRwKqh+gbkwDAJ763/
003/J6D/64LQ5H/Yc/9nqt32f5qSKv+ZgvzvgnGcLpJyGeG3w07gHaHmsxD+bQtDiqc4mE7t
VOgPB0AR7Qo6yfYun2H9v5r/ds9X+y8o4ZX/lIP/XTB+8std7s/j1I/ST5zti/U2RSjeZNu8
MP43FwFCWW6CAC/j/Dl4AeGHgvWf3Y//XOl6/8dh/9cJ1/0PDkEA/g8S6z/v2X/KW/+1EAL6
/w657r/9CfRhdgTtQPW6zI/yYXw2E3LikagL6jYAbv7/ZezXf6kls/4LCf53wnmj3/eKAAAA
AAAAAJf8AHtE6x8AKAAA
--------------020405070206030203000800--