Re: [Smartfrog-developer] Detached components.

[Guillaume M. <gui...@ya...>]

> Glenn Hisdal wrote:
> > Hello,
> > 
> > After modifying my SLP advertiser and locator for
> SF components, I 
> > remembered that it is possible to detach a
> component.
> > If I got this right, a detached component is
> removed from its parent and 
> > put in the root process. The component will still
> be fully usable.
> > However, if a component is advertised by its
> canonical name or Reference 
> > object, and later detached, it will no longer be
> found by other 
> > components using SLP as the reference will be
> wrong.
> > Using the RMI stub to advertise the component, as
> I did in the 
> > beginning, will of course work.
> > 
> > I am thinking that perhaps it is better to switch
> back to using the RMI 
> > stub since that will always work.
> > Any thoughts on this ?
> 
> I like the idea of names, as they survive things
> like restarts, and have 
> human readability in there.
>
> Could components readvertise themselves after they
> change their parenting?

I was thinking along the same line. First cumbersome
solution, and that would work only if the advertised
component is a compound, override the
sfParentageChanged() method for either the
PrimAdvertiser (if it is a child of the component that
detaches itself), or a specific component that would
have been deployed has a child of the detaching
component, with a link to the advertiser. 
The detaching compound will call of its children's
sfParentageChanged() method, and that's where you
could trigger a service advertisement update ...
 
Probably also you could write some SFHook to catch the
sfDetach?  This hook would be created by the prim
advertiser and keep track of all registered components
? Patrick, Julio, anything possible around this ?

Guillaume



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail