Are returned objects connected to the ORB?



Hi,

[I've already talked with some of you, skip to the second paragraph if you
know what my problem is]

While working on a Bonobo implementation, I wanted to use other
Bonobo components written using the GNOME/C implementation, to test
interoperability. However, functions that should have returned objects
either created or stored by the component repeatedly returned NULL (even
doing a set/get pair (e.g. Embeddable::set/get_client_site) returned NULL,
not the object I passed to set). The interesting thing is, this does not
happen when both sides use ORBit (otherwise, no GNOME/C Bonobo programs
would work, of course). Since noone was really able to help me, I decided
to investigate it a bit.

However, before I tell you what I've found, let me first put a big fat
DISCLAIMER here: I don't know ORBit. I don't know other ORBs. Heck, I
haven't even used ORBit natively before (only thru the GNOME/C Bonobo
lib). I think this is important to note first, because it is very possible
that I'm entering M-x bullshit-mode now. If I do, please, PLEASE tell me
so, this is my third e-mail about this problem, and I'd be delighted if
someone would at least tell me `dude, you're totally on the wrong track
here'.

Anyway. Using GDB, I set a breakpoint at 
_ORBIT_skel_Bonobo_Embeddable_new_view (one of the functions returning
NULL when called from another ORB), and traced it around a bit. Looking at
its return value (before it's written into the return stream), I became
suspicios seeing it's `connection' value (not that I have the slightest
idea what it should be, it was only its name that got my attention):

$3 = {parent = {interface = 0x40501848, is_pseudo_object = 0 '\000', 
    refs = 2}, orb = 0x808e250, connection = 0x0, 
  object_id = 0x8092cd0 "IDL:Bonobo/View:1.0", profile_list = 0x80551e0, 
  forward_locations = 0x0, active_profile = 0x0, vepv = 0x8092ce8, 
  servant = 0x8092ac8, vepv_size = 9}

Just to have an easy control negative, I took a look at OAF as well, since
OAF's activate_* methods return CORBA objects as well, and those seemed to
work. I broke into _ORBIT_skel_OAF_ActivationContext_activate_from_id and
took a look at the returned object:

(gdb) print *(_ORBIT_retval->res->_u->res_object)
$7 = {parent = {interface = 0x40095848, is_pseudo_object = 0 '\000', 
    refs = 1}, orb = 0x805dd90, connection = 0x8093c68, 
  object_id = 0x808c708 "IDL:Bonobo/Embeddable:1.0", profile_list =
0x805ff48, 
  forward_locations = 0x0, active_profile = 0x808a0a8, vepv = 0x0, 
  servant = 0x0, vepv_size = 0}

Again, this is its state just before it's written into the output stream.
Note how its `connection' value is non-null.

Now that I've done my homework (:)), could someone clarify if the problem
is real, and if I'm on the right track?

Bye,
	Cactus


-- 
   .--= ULLA! =----------------------------.  finger cactus@cactus.rulez.org
   \      http://cactus.rulez.org           \   for PGP public key
    `----------= cactus@cactus.rulez.org =--'
Sok kicsi sokat kicsinál.





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]