Re: [Smartfrog-developer] Question on LAZY

[Richard A. <rac...@re...>]

OK. How about I try to answer my own question. Here is the helloworld 
example:

sfConfig extends Compound {
g extends Generator {
messages ["hello"] ;
printer LAZY ATTRIB p ;
}
p extends Printer {
name "myPrinter" ;
}
}

Although the printer subcomponent of g is declared as LAZY, it also has 
a value assigned to it, via the ATTRIB p expression. This refers to an 
instance of component Printer *which has been allocated* in the same 
compound configuration. So when GeneratorImpl starts up, it can use the 
statement

Printer printer = (Printer) sfResolve(printerRef) ;

to obtain an RMI stub to that existing Printer instance, and so there is 
no need to dynamically deploy an instance.

I suppose dynamic deployment only applies if we need to deploy a 
component which has not been deployed in any other part of the smart 
frog configuration.

Richard

Richard Achmatowicz wrote:
> Hello
>
> I'm not quite clear on the use of LAZY in SF component descriptions.
>
> 1. My understanding was that using the LAZY keyword with a sub-component 
> causes that sub-component to be parsed but not deployed.
> e.g.
> X extends PrimImpl {...}
> Y extends PrimImpl {...}
> Z extends PrimImpl {...}
>
> c extends CompoundImpl {
>   sfClass "myCImpl" ;
>    x extends X ;
>    y extends Y ;
>    z extends LAZY Z ;
> }
> Again, from what I understand so far (possibly incorrect), x and y will 
> be parsed, deployed and their lifecycles synchronized, whereas  z will 
> be parsed  but not deployed. In order for it to be deployed, myCImpl 
> needs to retrieve the  ComponentDescriptionImpl  for z and  use 
> sfCreateNewChild  to  deploy an instance of  z. This instance will have 
> a lifecycle, but that lifecycle will not be synchronized with the 
> lifecycles of x and y. (c.f. SmartFrog tutorial, section 10, Dynamic 
> Deployment).
>
> 2. Given this, I was having a look through the HelloWorld example where  
> a Generator component contains a Printer component as a LAZY subcomponent:
> Generator extends Prim {
>  sfClass ""GeneratorImpl" ;
>  frequency 10 ;
>  messages ["a", "b"] ;
>  // printer LAZY ... ;
> }
>
> The GeneratorImpl class accepts a Printer  object instance which is  
> obtained by a  call to sfResolve:
> Printer printer = (Printer) sfResolve(printerRef) ;
>
> In looking at the GeneratorImpl implementation, given that it accepts a 
> LAZY component, I was expecting to find some code in which the 
> ComponentDescriptionImpl was retrieved and a child component allocated, 
> as in the dynamic deployment example. However, I didn't find such code.  
> Now i'm wondering why, given that a LAZY component is parsed  but not 
> deployed.
>
> I suppose my questions are:
> (i) why is the dynamic deployment pattern not used in the HelloWorld case
> (ii) who is deploying the Printer component
> (iii) what is the recommended manner in which to deal with components 
> which include LAZY subcomponents
>
> Richard
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Smartfrog-developer mailing list
> Sma...@li...
> https://lists.sourceforge.net/lists/listinfo/smartfrog-developer
>