You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Konrad Windszus <ko...@gmx.de> on 2016/05/24 08:58:33 UTC
OSGi Installer: Removing entities with the highest priority should automatically install the entity with the 2nd highest priority
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?
Konrad
Re: OSGi Installer: Removing entities with the highest priority should automatically install the entity with the 2nd highest priority
Posted by Konrad Windszus <ko...@gmx.de>.
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 <cz...@apache.org> 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
> cziegeler@apache.org <ma...@apache.org>
Re: OSGi Installer: Removing entities with the highest priority
should automatically install the entity with the 2nd highest priority
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: OSGi Installer: Removing entities with the highest priority
should automatically install the entity with the 2nd highest priority
Posted by Carsten Ziegeler <cz...@apache.org>.
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.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org