| Handling system bundle updates using SimpleConfigurator and ConfigApplier [message #800332] |
Thu, 16 February 2012 19:11  |
 Terran Gilman
Messages: 67
Registered: July 2009 |
Member |
|
|
We have a hand-rolled runtime platform that consists of the core Equinox components and p2. We have our own update mechanism built that leverages the provisional PlanExecutionHelper utility class. I noticed that if you follow the call chain through the SimpleConfigurator into ConfigApplier, it pre-emptively throws an IllegalStateException if it detects that the system bundle would be updated when applying the change set.
My question is around the proper handling of this case. The message provided in the exception suggests that the framework needs to be restarted. However, I haven't been able to track down how the update is recorded so it will take affect once the restart is complete.
I know the SimpleConfigurator reads the bundles.info file and uses the ConfigApplier to update the profile based on this information. Which component is responsible for updating the bundles.info file in the first place? Is this a side-effect of one of the earlier operations performed by the p2 engine or planner?
|
|
|
| Re: Handling system bundle updates using SimpleConfigurator and ConfigApplier [message #805471 is a reply to message #800332] |
Thu, 23 February 2012 15:17  |
Terran Gilman
Messages: 67
Registered: July 2009 |
Member |
|
|
I've done some additional research into how the p2 UI manages the update process. From what I can tell, there are some additional utility APIs that we missed in our original effort; namely ProvisioningSession and ProfileChangeOperation.
I am going to be trying a new approach that uses these classes instead of dealing with the low level p2 APIs. The only thing I don't see in these APIs is some type of cumulative profile change operation. The three subclasses I've found, install, uninstall, and update, handle single or sets of changes that fall into the same category. However, the life cycle we're looking to support requires the ability for a mixed operation.
Change requests will be queued up based on actions taken in the web ui. However, an administrator subsequently needs to initiate a maintenance request at which time any queued requests should be executed. These changes could include installs, updates, and/or removals simultaneously. Is there an existing operation for this type of action or should I create a new subclass using the core of the existing subclasses?
Additional: Can I just execute several install, update, or uninstall operations serially and then apply the entire change set at the end instead of creating a new subclass?
[Updated on: Thu, 23 February 2012 16:24] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.02263 seconds
] 
Search
Help
Register
Login
Home
