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)".
(BundleEvent.STOPPED | BundleEvent.STOPPING | BundleEvent.UNINSTALLED)) == 0;
can be used to check if the OSGI environment is active or not.