We also have to take care about the started="false" flag somehow.
I suppose if a feature flags the bundle as started="false", it would behave
as if this feature was stopped for the computation of that bundle state.

I'm fine with this behaviour, we just to understand that there's no way to
make sure a bundle is stopped.


2015-04-13 18:04 GMT+02:00 Jean-Baptiste Onofré <[email protected]>:

> I'm with you on that: we just have to agree on the behaviour and document
> it accordingly.
>
> In my opinion, if a bundle is used by a feature (feature A), it should not
> be stopped if we stop another feature that uses it (feature B).
>
> It's the same for the transitive features.
> If a feature is used by a feature, it should not be stopped if we stop
> another feature that used it ;)
>
> Regards
> JB
>
>
> On 04/13/2015 06:01 PM, Guillaume Nodet wrote:
>
>> Yeah, I was thinking about it.
>> Though the obvious other solution is to fix it.
>>
>> I have actually started an email this morning to discuss but I haven't
>> finished it.
>>
>> Overall, I think it may not be very difficult to fix, as the bundle state
>> changes are already handled correctly afaik.  The real problem is to agree
>> on the semantics on the effects, so that we can compute the desired state
>> of each bundle correctly.
>>
>> Problems arise when a bundle is used by several features, one of which
>> being started and the other resolved.
>>
>> Anyway, it's really up to you, I don't mind fixing the code as long as we
>> agree on the behaviour.
>>
>> 2015-04-13 17:51 GMT+02:00 Jean-Baptiste Onofré <[email protected]>:
>>
>>  Hi all,
>>>
>>> I discussed with Christian about KARAF-3102.
>>>
>>> The feature lifecycle doesn't actually fully work, especially around the
>>> stop action.
>>>
>>> In order to avoid to perturb the users, I think we should remove the
>>> features lifecycle commands. Else, if they are provided, users will try
>>> it
>>> and may be disappointed as they won't work as expected.
>>>
>>> WDYT ?
>>>
>>> Regards
>>> JB
>>> --
>>> Jean-Baptiste Onofré
>>> [email protected]
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> [email protected]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Reply via email to