Details
-
Improvement
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
None
-
None
Description
With STANBOL-464 the BundleProvider was changed to only uninstall resources if Bundles where uninstalled. See STANBOL-464 for more information why this change was needed.
This Issue suggests to go back to the scheme of uninstalling resources when a bundle is STOPPED as this has big usability advantigaes - users need only to stop/start Bundles instead of uninstalling and re-uploading them!
This has even more importance in the light of STANBOL-529. Because as in future the default configuration will be shipped as bundles users are much more likely to start/stop bundles to activate/deactivate such configurations.
For being able to use the STOPPED event for uninstalling resources the BundleProvider needs to be able to detect if such an event was caused (a) by the user stopping a Bundle or (b) the OSGI environment shutting down (see STANBOL-464 for details).
After investigation this distinction is possible by checking the state of the System Bundle (bundle with the id '0') because:
- if the System Bundle is STOPPED the OSGI environment is shutting down.
- it is ensured that the System Bundle is the first one that is in the BundleEvent#STOPPING state
- Bundle Events are processed asynchronously. Therefore such events will be processed of the System Bundle is already STOPPING
The SystemBundle is accessible by calling "BundleContext.getBundle(0)".
(context.getBundle(0).getState() &
(BundleEvent.STOPPED | BundleEvent.STOPPING | BundleEvent.UNINSTALLED)) == 0;
can be used to check if the OSGI environment is active or not.
Attachments
Issue Links
- supercedes
-
STANBOL-464 The Bundle Provider MUST NOT uninstall resources if a Bundle is STOPPED
-
- Closed
-