On Mon, Apr 12, 2010 at 21:51, Lin Sun <[email protected]> wrote: > 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(). :) >
Actually, there may be some use cases for the prepare() method. The reason is that when installing a subsystem, a processor may be called multiple times for different resources, yet, a single session would be used. The prepare() would then allow some processing after all resources have been processed. If you look at the subsystem processor, it actually restarts the subsystems that were previously stopped (during an update for example). Restarting those in the process() method could have undesirable effect such as forcing the resolution of some bundles too early. So we may want to keep it ... > > > 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. > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
