Are returned objects connected to the ORB?
- From: ERDI Gergo <cactus cactus rulez org>
- To: gnome-components-list gnome org
- Subject: Are returned objects connected to the ORB?
- Date: Wed, 28 Jun 2000 16:31:19 +0200 (CEST)
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]