Re: 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=DEVDEV