Maybe we can introduce a --force option to stop whatever the
bundle/feature is used by another feature ?
Regards
JB
On 04/13/2015 06:12 PM, Guillaume Nodet wrote:
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
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
