[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: ImplRepo question (Was: "Re: konqueror - multiple instances" on
From:       Steffen Hansen <stefh () mip ! sdu ! dk>
Date:       1999-07-19 17:37:23
[Download RAW message or body]

On Mon, 19 Jul 1999, Simon Hausmann wrote:

> On Mon, 19 Jul 1999, Steffen Hansen wrote:
> > My test app looks up "FileManager" in the trader and activates the
> > service with KAtivator. I tossed some quick DII code together to actually
> > call a method on the resulting object, but all i get is an 
> > 
> > uncaught MICO exception: IDL:omg.org/CORBA/OBJ_ADAPTER:1.0 (0,
> > not-completed)
> > 
> > So it looks like the mediator or activator code is rather confused about
> > the whole thing. I noticed that konqueror never tells the BOA that it's
> > ready for action (by calling BOA::obj_is_ready() or BOA::impl_is_ready()).
> > Could that be the reason why kded fail to bind to the Konqy object?
> 
> Being a bit more precise now (in contrary to my previous mail :-))
> 
> >From Konqueror's side the BOA connects to the mediator via
> OAMediator::create_obj
> and
> OAMediator::activate_obj
> 
> (See line 619 and 621 in boa.cc)

Actually, the the app contacts the mediator at startup -- in the BOAImpl
constructor (boa.cc: 380). So after the call to create_impl, the mediator
has a correct ImplRec (using the values from the ImplRepository, which
for konqy is set because kded read a .desktop-file and inserted an
entry) and a corrent ServerRec in the "ServerInactive" state.
activate_obj() brings the server in the "ServerActive" state.
 
> The problem is that the actual implementation of these two method looks up
> an mediator-internal server structure (see line 1447 in mediator.cc) and
> raises an assertion if it doesn't exist ( the structure) .
> Obviously it doesn't exist if you issue a plain "konqueror -OAfoo bla" ,

I think it does :)

> it only gets created on a bind() call, "catched" by the mediator impl.
> 
> This is what I read out of the sources, and that tells me that it's not
> possible to really "connect" to the mediators from "outside" kded.

After inserting calls to boa->obj_is_ready() in konqy and kdesktop, i was
able to obtain a reference to their objects through kded. It didn't work
the right way though, because kded started a new konqy for me each time :(
Is that a "feature" of KActivator or where do i have to look? If i
activate the konqy server "by hand" with 
"imr -ORBImplRepoAddr unix:/tmp/kded-<pid> activate Konqueror" it only
activates once -- even if i do it several times. The ImplRepo entry look
like this afterwards:

> imr -ORBImplRepoAddr unix:/tmp/kded-4201 info Konqueror
       server name: Konqueror
   activation mode: shared activation command: konqueror --server
         object #0: IDL:Konqueror/Application:1.0#App
         object #1: IDL:omg.org/CORBA/OAServer:1.0
         object #2: IDL:KOM/Base:1.0
         object #3: IDL:KOM/Component:1.0
         object #4: IDL:KOM/Application:1.0
         object #5: IDL:OpenParts/Application:1.0 

This looks nearly perfect to me, but should #App really be part of the
repoid? Now i can even get a correct object when invoking on the reference
returned by KActivator::activateService(). Kded says:

new connection from unix: 
_repoid: IDL:Konqueror/Application:1.0, _tag:
App creating reference for Konqueror with repoid 
 IDL:Konqueror/Application:1.0 
Incarnating .... 
Incarnating Konqueror with id IDL:Konqueror/Application:1.0 and tag @@@
making new connection to unix:/tmp/kded-4201 
new connection from unix:
binding with tag @@@ and addr unix:/tmp/kded-4201 
could not bind to server: Konqueror
conn closed or broken

It looks like the tag doesn't get encoded/decoded correctly from the ior
on incarnation. My only changes are that i made KAcivator always strip the
#Bla part of the repoid and use Bla as tag if an explicit tag isn't
supplied.

greetings,
-- 
Steffen Hansen email:
stefh@mip.sdu.dk, stefh@imada.sdu.dk, hansen@kde.org 
URL:   http://www.mip.sdu.dk/~stefh
       

[prev in list] [next in list] [prev in thread] [next in thread]