[jira] [Updated] (KARAF-6953) Globally Prevent AutoRefresh Cascade on Feature Install

["Jean-Baptiste Onofré (Jira)" <ji...@apache.org>]

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

Jean-Baptiste Onofré updated KARAF-6953:
----------------------------------------
    Summary: Globally Prevent AutoRefresh Cascade on Feature Install  (was: Globally Prevent Auto-Update Cascade on Feature Install)

> Globally Prevent AutoRefresh Cascade on Feature Install
> -------------------------------------------------------
>
>                 Key: KARAF-6953
>                 URL: https://issues.apache.org/jira/browse/KARAF-6953
>             Project: Karaf
>          Issue Type: New Feature
>          Components: karaf
>            Reporter: Kevin Brooks
>            Assignee: Jean-Baptiste Onofré
>            Priority: Major
>
> In a production environment, accidentally refreshing an existing feature or bundle could be problematic.
> As an existing example, the activemq-client feature depends on the activemq-osgi bundle. The activemq-osgi bundle has many optional, wildcard imports. See here: https://github.com/apache/activemq/blob/master/activemq-osgi/pom.xml I believe that this may have been the underlying cause of http://mail-archives.apache.org/mod_mbox/karaf-user/201710.mbox/%3C0a12ea34-9b9e-5a18-a711-e66625240dcf@nanthrax.net%3E
> In this example, if a new feature is installed which updates an existing com.fasterxml.jackson service or includes a new com.fasterxml.jackson service, activemq is refreshed, causing quite a bit of fall out. Existing brokers are destroyed, transitive dependencies are refreshed, including web/jetty.
> The interruption in service and potential for data loss is bad, but this could get even worse if the refresh causes downstream runtime errors, of which, may not be realized immediately.
> I acknowledge that there is a command line option to prevent this behavior, however, it requires the command line and it relies on human input.
> I'd like to prevent users from shooting themselves in the foot...
> The kar installation service has configuration exposed that could work in this scenario (noAutoRefreshBundles), but would need to be transplanted into the features installation service.
> Alternatively, we could abstract one level and introduce the notion of default or mandatory option values. This approach would be fairly flexible, would be easier to fit into the featuresBoot process, and could solve other yet-to-be-seen use cases.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)