Re: Update lifecycle moved into Primimpl and CompoundImpl

There is indeed an error in the explanation.

By default a component will reject an update, both Prim and Compound,
during the first prepare phase. This is defined in PrimImpl and should
be inherited by all components. If you wish to indicate that a component
does implement update, then you must set the attribute sfUpdatable to be
true (or override the prepare method to not check) - if it is missing or
false it will reject the request. Clearly all components in a tree must
accept for an update to happen. 

There are templates UpdatableCompound and UpdatablePrim that includes
that attribute set.

So the example should read:

sConfig extends UpdatableCompound {
     ....
}

As for the ant task, this will probably come when you write it :-) 

Patrick


-----Original Message-----
From: smartfrog-developer-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
[mailto:smartfrog-developer-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of
Steve Loughran
Sent: 25 September 2006 17:34
Cc: Smartfrog-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Smartfrog-developer] Update lifecycle moved into Primimpl
and CompoundImpl

Goldsack, Patrick wrote:
> 
> I have moved the very, very, experimental component hierarchy Update 
> lifecycle implementation into the core PrimImpl and CompoundImpl from 
> the UpdateablePrimImpl and UpdateableCompoundImpl classes. The Update 
> interface now moves into org.smartfrog.sfcore.prim.
> 
> Documentation will follow.
> 
> But for those of you who have not yet seen the new feature - here is 
> an example of how to use it.
> 
> Use
> 
>   sfStart host name appV1.sf
> 
> to launch something, then use
> 
>   sfUpdate host name appV2.sf
> 
> to update it to the new version. 

presumably ant tasks and tests will also follow.



> 
> In detail, there are a number of new methods described in the Update 
> interface used for the update processing. This includes a 2-phase 
> prepare-to-update lifecycle during which an update can be aborted, and

> the normal 3-phase update itself (3-phase as it may start new 
> components as part of the process, so it needs the equivalent to 
> sfDeployWith, sfDeploy and sfStart to coordinate with the normal 
> startup of new components). During the last three phases, an error is 
> treated much like an error in initial deployment - fatal by 
> default...! As normal, override for different semantics.
> 
> Every component also provides a "do all update phases on self and 
> children" method - "sfUpdateComponent". So at the top level, a single 
> call will orchestrate the update, much as the helper methods 
> "sfAddNewChild" and "sfAddNewApplication" wrap up the deployment and 
> start-up lifecycle aspects.
> 
> Default implementations are in PrimImpl and CompoundImpl, but as usual

> these can be overridden as desired. If one of the attributes with an 
> "sf" prefix is changed, it is assumed to need a redeployment (stop and
> restart) of the component as it may need to move or be implementated 
> by a different class. If only the non-sf attributes have changed, then

> the context is updated and the update phases run to allow rebinding or

> adjustment to attribute values to be handled. Again, override if this 
> is not the desired semantics. One restriction currently is that if the

> top component of the hierarchy requires redeployment it will fail - it

> is afterall orchestrating the update.
> 
> At its simplest, if you  want to do something in a Prim on update (as 
> you normally will, if only to set internal variables to new values), 
> override the definitions of
> 
> sfUpdateDeploy()
> sfUpdateStart()
> 
> With appropriate calls to super methods as for the normal sfDeploy and

> sfUpdate.

This could set up expectations in users that an update really will
update a running application. Surely the default behaviour of a prim
that is running would be to say 'too late, I'm inflexible', until they
get enhanced to be dynamic.

-Steve


------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT Join
SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V
_______________________________________________
Smartfrog-developer mailing list
Smartfrog-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/smartfrog-developer

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV