Update lifecycle moved into Primimpl and CompoundImpl

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. 


As a simple example you can try the following and observe the effects
using the management console:

appV1.sf:
#include "/org/smartfrog/components.sf"
sfConfig extends Compound {
    x 10;
}


appV2.sf:
#include "/org/smartfrog/components.sf"
sfConfig extends Compound {
    x 20;
    y extends Compound {
        a "hello";
    }
}

appV3.sf:
#include "/org/smartfrog/components.sf"
sfConfig extends Compound {
    z 20;
    y extends Compound {
        a "goodbye";
        b "and thanks for all the fish";
    }
}


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.

Patrick

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