Hi thanks for the reply. See comments in line. Lin
On Mon, Apr 12, 2010 at 11:59 AM, Guillaume Nodet <[email protected]> wrote: > I initially simply borrowed this interface from the DeployementAdmin spec, > but I agree I'm not really sure how the prepare phase could be used in a > smart way. > I'd have no problem to remove if at this point. I guess we can leave it there and remove it if there is no usage. I just want to make sure I didn't miss anything in prepare(). :) > In the case of updates, you're right that the goal would be to revert to the > last state. > In the current code, a bundle processor will be called for each updated or > new bundle. I was assuming (but haven't really thought about that in > details), that a bundle would be updated only of the version is already > installed and the RESOURCE_UPDATE_ATTRIBUTE is set on the resource. The > goal of this attribute is to force the update in case the content of the > bundle has changed, but the version has not. This would be true for maven > snapshots for example. In such a case, the bundle would be updated, but in > all other cases, the bundle would either be untouched, or a new one > installed (with a different version). In the case of an update, I agree we > can't revert, but then, it's a snapshot, and i would think it's not that big > a problem to not really revert them. > For subsystems, I think it should be possible to revert to the previous > state if we keep the list of constituents before starting the update and > somehow revert to those. We might be able to recreate the current list of > constituents from the header too. Not really sure. Ok I agree that it is impossible to handle bundle update->rollback while it is possible to handle subsystem update->rollback. I tried to code this in rev 933378. > Also, in case of a subsystem update, I'm not sure what to do with resources > that would be provisioned in the parent context ... > Another thing that came to my mind, is that the parent context may not be > the best place to put all those dependencies. A peer subsystem with an > Export-All policy might be better manageable, as those would be located in a > well defined place instead of bloating the parent context. > >> Regarding API, for SubsystemEvent, there is a type called RESOLVED. I >> could not figure out when we could emit that type, as the framework >> can resolve a bundle any time. >> > > I would suppose we could listen to the composite state and fire the event > when the composite itself enters the RESOLVED state. > There may be little need for this event, not sure about the use cases yet. Ok that sounds reasonable. I'll add that.
