Hi Janaka, First *"**ServiceLifeCycle is already in use and your changes may affect existing usage" * is sufficient warning. Because we can't add lengthy descriptions in small UI box. Practically, do we change the *LC state id* having large number of artifacts in a production system ?.
Renaming the existing *LC state id* is only one use case. Following are are the valid points of allowing to update the existing LC configuration. 1. Add new state to existing configurations. 2. Add/update executors, validators, transition UI ..etc. 3. Add/Update the parameters. 4 Add/update the check Items ..etc Thanks. Ajith. On Sat, Feb 22, 2014 at 2:16 AM, Janaka Ranabahu <[email protected]> wrote: > Hi, > > I have noticed that we allow users to modify a lifecycle that is already > assigned to resources. Did we do a complete analysis of the situations that > could come by allowing this behavior? > > I have noticed the following inconsistent behavior due to this. > > When saving the lifecycle configuration, it only gives a warning saying* > "ServiceLifeCycle is already in use and your changes may affect existing > usage. Are you sure you want to save these Lifecycle changes?"* There is > no descriptive explanation about what is the impact of the change. It > happens to be that, if you rename a state, and if there were resources on > that state, the lifecycle portlet disappear from the UI. There is no way to > remove, add or do any action on the lifecycle for that resource and that > resource is completely unusable(from LC point of view) from that point > onward. > > Also we do not update the existing resources with the change. If we add a > new check item or change a check item of an existing state, that change is > not reflected for the resources that are already associated with the > lifecycle. Because of that, G-Reg began to have resources with the same > lifecycle, but with different behaviors. > > Therefore, I'm wondering what is the purpose of modifying a lifecycle > which is already in use. IMO, this had introduced a inconsistent behavior > and had not solve anything. The real problem comes when there is a high > number of resources that is associated with the lifecycle. > > Thanks, > Janaka > > -- > *Janaka Ranabahu* > Senior Software Engineer; WSO2 Inc.; http://wso2.com > > > * E-mail: [email protected] <http://wso2.com>**M: **+94 718370861 > <%2B94%20718370861>* > > Lean . Enterprise . Middleware > -- Ajith Vitharana. WSO2 Inc. - http://wso2.org Email : [email protected] Mobile : +94772217350
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
