Indeed, in my case it seem that the OSGi installer was just stuck for some reason. After restarting the installer bundle org.apache.sling.installer.core <http://dow-qa-publish-1.nhe.netcentric.biz:4503/system/console/bundles/10> everything was fine again. I cannot reproduce any longer. But there seems definitely something to be fishy when the Installer can reach such a state. Konrad
> On 24 May 2016, at 13:30, Carsten Ziegeler <[email protected]> wrote: > > Carsten Ziegeler wrote >> Konrad Windszus wrote >>> Hi, >>> Currently in case the entity (e.g. bundle or configuration) with the >>> highest priority is removed through the OSGi Installer (no matter which >>> provider contributed it), the one with the 2nd highest priority will not >>> automatically get activated (see >>> https://issues.apache.org/jira/browse/SLING-5744 >>> <https://issues.apache.org/jira/browse/SLING-5744>). >>> This is IMHO a defect which should be fixed. >>> >>> Since the OSGi Installer Impl already maintains a list of processed >>> entities from the past it should have all the necessary information to >>> automatically try to install the entity with the same ID from another >>> location (with the now highest priority) in case the formerly active entity >>> was removed. At least for the schemes "launchpad and jcrinstall" this >>> should be possible, as that URL contains all relevant information to >>> automatically try to install those entities in case an entity with a higher >>> priority get removed. >>> >>> If that use case is not supported, this may lead to very problems which are >>> hard to debug and fix automatically, because in those cases, the according >>> entities have to be explicitly modified to be picked up by the OSGi >>> installer. >>> WDYT? >> >> This sounds like a serious bug to me, I'm pretty sure this worked in the >> past. I also think that we might have IT tests for this scenario. >> > > ConfigPrioritiesTest#testOverrideConfig is testing this scenario unless > I'm misunderstanding your case. > > > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] <mailto:[email protected]>
