[
https://issues.apache.org/jira/browse/FELIX-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13823702#comment-13823702
]
Marcel Offermans commented on FELIX-4184:
-----------------------------------------
Following up. Jan Willem correctly mentions that, due to a flaw, we currently
don't stop *affected* bundles at all, but attempt to update them while running.
This causes the resolve issues mentioned above. An example:
Say we update a bundle that implements some API, and the bundle containing it,
because the API has been changed. If we first update the implementation without
stopping it, it will try to resolve against the new API and fail because that
has not yet been installed. Stopping both bundles first, then updating,
refreshing and then starting again solves that issue nicely.
So that's what we need to do here!
> Temporary resolver errors while updating bundles with deploymentadmin
> ---------------------------------------------------------------------
>
> Key: FELIX-4184
> URL: https://issues.apache.org/jira/browse/FELIX-4184
> Project: Felix
> Issue Type: Bug
> Components: Deployment Admin
> Affects Versions: deploymentadmin-0.9.4
> Reporter: Marcel Offermans
>
> When you use the system property to not stop the world during an update,
> updating a running bundle might cause a (temporary) resolver error (I've seen
> it throw exceptions related to uses constraints). According to the spec, if
> we get an exception here, we should rollback. If you stop the world, this
> never happens, but here such temporary exceptions are probably resolved when
> we refresh packages at the end. That does not happen though, since we never
> get there. We should consider covering this use case, letting the deployment
> continue and deal with errors when resolving (and maybe then rolling back).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
