[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:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-07-19 18:46:54
[Download RAW message or body]

On Mon, 19 Jul 1999, Steffen Hansen wrote:

> 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.

Gosh! You're right :-) , I missed that comment in mediator.cc:
//this happens for server not activated by the mediator
:-)
  
> > 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

No, it's no feature of KActivator. I guess it has something do to with the
ServerState in the mediator?
However the activation code of KActivator is actually from the imr_client
(thus the copyright notice) .

> 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.

The reason why I put the tag stuff everywhere around when using KActivator
was that I was *not* able to bind to an repoid without a tag. bind()
simply crashed :-((

I think this is due to the fact that the BOAObjectRestorer template stuff
(KOMAutoLoader) always checks for the correct tag, too, before allocating
a new object.

And IIRC the old IMR code from Torben in KOffice used tags, too. They were
"hidden" though, meaning the client didn't have to specify the tag but
instead the server's name was used everytime and all the
BOAObjectRestorer templates in all KOffice used (and still used) the
servername as tag, too.


Ciao,
 Simon

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