[
https://issues.apache.org/jira/browse/SLING-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15587906#comment-15587906
]
Dominik Süß commented on SLING-5014:
------------------------------------
[~cziegeler] - I was checking the various options before - the challenging part
is dealing with the uninstall cases where lower level install candidates might
hang around. The Bootstrap Installer does not take of cleaning the install
state of further install candidates so further install candidates will still
hang around and lead to downgrade. (see scenario 1). A default handling might
not be applicable as the version range of the uninstall directive might in fact
allow a certain downgrade (see scenario 2) - I know that the lower boundary
cases are probably an edge case but these are present for the bootstrap
installer so the osgi installer needs to respect them. As this affects the
state based on available install candidates I saw no other location but the
BundleTaskCreator to perform the blacklisting. The API change was necessary as
TaskResourceGroup#getNextActiveResource had a hard wired behavior to deliver
only the second resource. Spreading the blacklist logic across
BundleTaskCreator AND EntityResourceList as the TaskResourceGroup
implementation would spread the logic in a way that would make it a lot harder
to understand and wires the implementations together. If EntityResourceList
always would be the only implementation we "could" cast to the implementation
and use the method instead of relying on publicly exposing this new method, yet
this is error prone as in case the implementation needs to change at some point
the implicit need for this method would not be documented.
Having a new method in a Provider API leading to a minor version increment to a
package anyways only implemented by the Sling Installer itself sounded like a
fair compromise and least intrusive change.
Scenario 1:
uninstall directive for bundle-x [1.0, 1.1)
Installed version 1.1, version 1.0 is in install state
Bootstrap directive will have no impact
Uninstallation of version 1.1 happening via osgi installer
as no further install candidate is existing the bundle needs to be completely
uninstalled (no downgrade)
Scenario 2:
uninstall directive for bundle-y [2.0,3.0) - because 2.x line had a serious bug
installed version: 3.0 versions 1.0 & 2.x are in install state
Bootstrap directive will have no impact
Uninstallation of version 3.0 will need to downgrade to 1.0 as 2.x versions are
blacklisted (no uninstallation)
> Installer blacklist, to avoid reinstalling older bundles
> --------------------------------------------------------
>
> Key: SLING-5014
> URL: https://issues.apache.org/jira/browse/SLING-5014
> Project: Sling
> Issue Type: Bug
> Components: Installer
> Affects Versions: Installer Core 3.6.6
> Reporter: Dominik Süß
> Fix For: Installer Core 3.6.10
>
> Attachments: SLING-5014-1.diff
>
>
> In case a bundle has mutliple install candiates only the highest version
> (with the highest priorty for the same versions) wins. An uninstall directive
> in the Sling bootstrap.txt file or provisioning model uninstalls this
> version. The way the OSGi install behavior is defined this lets the next
> artifact in the priority queue to get active and consequently only leads to
> downgrade to the next in the queue.
> As the uninstall directive declares a range that should be uninstalled the
> expectation is that after a startup with such an uninstall directive none of
> the declared versions are in an installed state. In consequence the OSGi
> installer must save this metainformation in the state that prevents a
> downgrade to a version that is part of an active uninstall directive.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
