Re: [Orbit-python-list] RootPOA
- From: Christian Robottom Reis <kiko async com br>
- To: Jason Tackaberry <tack linux com>
- Cc: Orbit-python-list lists sourceforge net, orbit-list gnome org
- Subject: Re: [Orbit-python-list] RootPOA
- Date: Thu, 30 Nov 2000 12:24:35 -0200 (BRST)
On Wed, 29 Nov 2000, Jason Tackaberry wrote:
> I was reasonably sure you couldn't pass NameService to
> resolve_initial_references with ORBit, and a quick perusal of ORBit's
> source shows this to be the case. The name service object only seems to
> be set on calling set_initial_references, which doesn't help much when
> you don't have a reference to the object to begin with.
Apparently you can set an IOR for the NameService in your orbitrc, but I
have yet to see this work. This code fragment in 0.5.3 indicates it does
something when you send NameService on to it:
else if(!strcmp(identifier, "NameService"))
return CORBA_Object_duplicate(orb->naming, ev);
orb->naming being set through naming_ior or naming_addr. I don't know if
this code is actually being used but it is there.
> Fetching a reference to GNOME's name service, at least, is done with
> Gnorba's gnome_name_service_get(). I don't think there is some elegant
I thought the name service IOR for gnome came through X hints.. I can't
use hints as I have a real distributed operation here. However, setting
the IOR through orbitrc or through the commandline would be an initial
solution, though I would have to fill this out manually until the time
came where I'd have persistent object being started up by orbit (if this
ever gets done :-)
I suppose nobody has effectively used orbitrc or argv parameters to poison
NameService so far, however.
Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]