[jira] [Resolved] (STANBOL-532) Bundle Provide (Sling installer plugin) should again uninstall resources if Bundles are STOPPED. However it MUST NOT uninstall resoruces when the System Bundle not Active

["Rupert Westenthaler (Resolved) (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/STANBOL-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rupert Westenthaler resolved STANBOL-532.
-----------------------------------------

    Resolution: Fixed

fixed with 	#1298756
                
> Bundle Provide (Sling installer plugin) should again uninstall resources if Bundles are STOPPED. However it MUST NOT uninstall resoruces when the System Bundle not Active
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: STANBOL-532
>                 URL: https://issues.apache.org/jira/browse/STANBOL-532
>             Project: Stanbol
>          Issue Type: Improvement
>          Components: Commons
>            Reporter: Rupert Westenthaler
>            Assignee: Rupert Westenthaler
>            Priority: Minor
>
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira