felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian van Spaandonk (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (FELIX-658) Extend deployment admin to optionally support not stopping the world on updates.
Date Mon, 04 Aug 2008 13:24:44 GMT

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

Christian van Spaandonk resolved FELIX-658.

    Resolution: Fixed

I agree this is not very OSGi-like, a change has been committed (rev 682377) that allows to
skip the stopping of unaffected bundles by providing a system property named org.apache.felix.deploymentadmin.stopunaffectedbundle.
If the property is set to "false" the stopping will be skipped when possible, if set to true
or if not set at all everything will function according to the spec (stopping all bundles

> Extend deployment admin to optionally support not stopping the world on updates.
> --------------------------------------------------------------------------------
>                 Key: FELIX-658
>                 URL: https://issues.apache.org/jira/browse/FELIX-658
>             Project: Felix
>          Issue Type: New Feature
>          Components: Deployment Admin
>            Reporter: Marcel Offermans
>            Assignee: Christian van Spaandonk
> Deployment Admin supports the atomic installation, update and removal of a group of bundles
called a package. Once installed, you can create fix packages to upgrade from one version
to the next. Often, those updates only contain a subset of the bundles. However (and this
is very un-OSGi-like) the spec dictates that even if you update only one bundle in a package,
you have to first stop them all, then do the update, and finally start them all again. I would
like to have a switch that allows you to change this behavior to only update what is actually
> Background: To maintain the software and updates to a gateway, we often define a gateway
to contain one deployment package containing all bundles, because that's the only way to truly
create atomic updates (once you start having more deployment packages, you run the risk of
wanting to update things in more than one package, and then run into the issue that there
is no overarching mechanism to do those updates in one transaction).

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message