Dominik Süß commented on SLING-5014:

[~cziegeler] - I can revisit this within the next 1-2 weeks. Sorry about the 
reformatting, this was created right after switching a new IDE which had some 
automatisms in there that I was not used to (and forgot to crosscheck the patch 
as I just did search for initial review).  I will crosscheck the osgi installer 
and see how to best hook in there and see how we can make the corresponding 
state handling of OSGi Installer more reliable based on problematic scenarios 
that we worked around or patched in quite brute manner in the past (e.g. 
cleaning osgi installer state cache). So this might take some time until I come 
up with a sequence of patches addressing those issues including the aspect of 

> 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üß
>         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

Reply via email to