Re: Question on LAZY

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: smartfrog-developer-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:smartfrog-developer-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Richard Achmatowicz
Sent: 05 August 2008 15:54
To: smartfrog-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
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
Smartfrog-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/smartfrog-developer

-------------------------------------------------------------------------
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=/