Menu
▾
▴
Re: [Smartfrog-developer] Question on LAZY
|
From: Richard A. <rac...@re...> - 2008-08-06 17:27:54
|
Patrick
Thank you for the detailed clarification on the use of LAZY. This helped
a lot. By 'structured data' I assume that you mean the
ComponentDescriptionImpl which can be used for deploying the component
dynamically when no deployed instance is otherwise available? By 'link',
I assume you mean a reference to an existing deployed component instance
(e.g. RMI stub) or existing attribute value?
Richard
Goldsack, Patrick wrote:
> Richard,
>
> Much of the confusion comes from our mistake in using the same keyword for two purposes, this is a design decision that we regret and are trying to change - we have introduced an alternative keyword and are encouraging people to use the new form and are changing our examples and documentation.
>
> The two uses are as follows:
>
> LAZY references
> And
> LAZY components (we now prefer to use the DATA keyword).
>
> A reference is used to indicate how the value of an attribute is to be found and is normally resolved during language processing (resolution), the LAZY keyword defers resolution to runtime after deployment. One frequent use of this is to obtain RMI references of components that have been deployed as this is only obtainable after deployment, but other uses may be to pick up runtime attributes such as environment variables or maybe finding data or objects through naming services.
>
> In the case of a LAZY (DATA) component, the component is not deployed, but its description is left as structured data to be obtained in the sfResolve call.
>
> The use of the keywords are identified by whether "extends" occurs. Without an extends, it is a lazy link, with an extends it is a lazy component.
>
> X LAZY y; // lazy reference
> Z extends LAZY v; // lazy component
>
>
> looking at the two cases - the hello world is an example of LAZY reference.
>
>
> sfConfig extends Compound {
> g extends Generator {
> messages ["hello"] ;
> printer LAZY ATTRIB p ;
> }
> p extends Printer {
> name "myPrinter" ;
> }
> }
>
> In this case we get a compound with two child components: g and p. The reference printer links to the component p. Since it is LAZY, and refers to a component, the result of an sfResolve call on the printer attribute is the RMI object reference of the deployed component p.
>
> If the printer attribute had not been LAZY, then we would have had roughly the following structure after language processing as printer becomes a copy of p.
>
> sfConfig extends {
> ... // attributes from Compound
> g extends {
> ... // attributes from Generator
> messages ["hello"] ;
> printer extends {
> ... // attributes from Printer
> name "myPrinter" ;
> };
> }
> p extends {
> ... // attributes from Printer
> name "myPrinter" ;
> }
> }
>
> Since g is a Prim (as I recall), and not a Compound, the printer attribute would not become a child component. So when sfResolve is used after deployment to access the printer attribute, the structured data would be returned rather than the RMI reference of p.
>
> Now the LAZY (DATA) component is used to make sure that some structured data in a Compound is not deployed as a child component.
>
> sfConfig extends Compound {
> x extends Prim {...}
> y extends Prim {...}
> z extends DATA Prim {...}
> }
>
> In this case a compound will be deployed with two child components (x and y) and one structured data attribute z. The DATA keyword (previously LAZY) makes sure that the structures remain as data and are not turned to components during deployment.
>
> So looking at your first example (Note I have turned PrimImpl into Prim - the template is called Prim, the parent class for Java is called PrimImpl)
>
> X extends Prim {...}
> Y extends Prim {...}
> Z extends Prim {...}
>
> c extends CompoundImpl {
> sfClass "myCImpl" ;
> x extends X ;
> y extends Y ;
> z extends DATA Z ;
> }
>
> The first question to ask is where the sfConfig attribute is!
>
> If we rewrite to
>
> X extends Prim {...}
> Y extends Prim {...}
> Z extends Prim {...}
>
> sfConfig extends CompoundImpl {
> sfClass "myCImpl" ;
> x extends X ;
> y extends Y ;
> z extends DATA Z ;
> }
>
> You will end up with two components x, y. z will not be deployed but be a copy of the definition of Z.
>
> I hope this has helped, if more clarification do please ask as we are collecting the kinds of questions that are asked and the answers we generate for a FAQ.
>
> Patrick
>
>
> -----Original Message-----
> From: sma...@li... [mailto:sma...@li...] On Behalf Of Richard Achmatowicz
> Sent: 05 August 2008 15:54
> To: sma...@li...
> Subject: [Smartfrog-developer] Question on LAZY
>
> 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
>
|
