[
https://issues.apache.org/jira/browse/KARAF-6953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré resolved KARAF-6953.
-----------------------------------------
Fix Version/s: 4.3.1
4.2.11
Resolution: Fixed
> 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
> Fix For: 4.2.11, 4.3.1
>
>
> 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/%[email protected]%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)
