I agree, but as answered in another thread there are (staying on your example of data source) some attributes we can't change runtime. We need to stop pools and so on. IOW we would need for these cases a composite operation to remove (nicely) and re-add a resource with all attributes cloned except the changed ones. Probably we need this kind of operations not only for ds and it have to be designed considering also the effort guys are doing for nice shutdown of the server. just my 2C S. On 05/05/2011 03:10 PM, Heiko W.Rupp wrote: > Hi, > > I understand that for many configuration changes, direct editing of values (i.e. write-attribute) is not supported for various reasons > - only changing one attribute may introduce inconsistencies > - applying the change would require a restart > > So the result is that many items (better name?) just allow to :remove them and then to :add > them again. > > This may be fine for items that only have one or two attributes, > but for a data source as an example with 30 attributes, it is a pain for the user that > is not using the embedded console or RHQ to specify them all in a curl statement > or even in the :add(...) command in the CLI just to increase some Tx timeout or to provide > a different password. > > There are of course other items in the management tree where this applies as well. > > Heiko > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Why does it work for server-config and server-group? It seems that I am able to change the server-config/socketbinding attribute at runtime. But of course it is not applied immediately. Or am I missing something here? On May 6, 2011, at 12:36 PM, Heiko Braun wrote: > > I don't have an answer to the technical solution, > but from the a users perspective, this doesn't work out at all. > > Towards a solution, it might help to break the requirements into > > a) modifications to the configuration > b) applying the new configuration to runtime components. > > If b) requires a restart, fine. That's something we can explain to the user. > But a) still needs to be possible, even when then changes are not applied immediately. > > There is no way we can tell people: > > "In order to change the password for connecting to the database, > you need to delete the DS config and start over." > > This issue pops up every once in a while and we tried to work around it. > But let's face it: It's a shortcoming of the current design. > > I do completely understand the reasons that lead to the current approach, > but I believe it's pretty much useless to move forward w/o a solution. > > Ike > > On May 6, 2011, at 12:10 PM, Stefano Maestri wrote: > >> I agree, but as answered in another thread there are (staying on your >> example of data source) some attributes we can't change runtime. We need >> to stop pools and so on. >> IOW we would need for these cases a composite operation to remove >> (nicely) and re-add a resource with all attributes cloned except the >> changed ones. >> >> Probably we need this kind of operations not only for ds and it have to >> be designed considering also the effort guys are doing for nice shutdown >> of the server. >> >> just my 2C >> >> S. >> >> On 05/05/2011 03:10 PM, Heiko W.Rupp wrote: >>> Hi, >>> >>> I understand that for many configuration changes, direct editing of values (i.e. write-attribute) is not supported for various reasons >>> - only changing one attribute may introduce inconsistencies >>> - applying the change would require a restart >>> >>> So the result is that many items (better name?) just allow to :remove them and then to :add >>> them again. >>> >>> This may be fine for items that only have one or two attributes, >>> but for a data source as an example with 30 attributes, it is a pain for the user that >>> is not using the embedded console or RHQ to specify them all in a curl statement >>> or even in the :add(...) command in the CLI just to increase some Tx timeout or to provide >>> a different password. >>> >>> There are of course other items in the management tree where this applies as well. >>> >>> Heiko >>> >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I don't have an answer to the technical solution, but from the a users perspective, this doesn't work out at all. Towards a solution, it might help to break the requirements into a) modifications to the configuration b) applying the new configuration to runtime components. If b) requires a restart, fine. That's something we can explain to the user. But a) still needs to be possible, even when then changes are not applied immediately. There is no way we can tell people: "In order to change the password for connecting to the database, you need to delete the DS config and start over." This issue pops up every once in a while and we tried to work around it. But let's face it: It's a shortcoming of the current design. I do completely understand the reasons that lead to the current approach, but I believe it's pretty much useless to move forward w/o a solution. Ike On May 6, 2011, at 12:10 PM, Stefano Maestri wrote: > I agree, but as answered in another thread there are (staying on your > example of data source) some attributes we can't change runtime. We need > to stop pools and so on. > IOW we would need for these cases a composite operation to remove > (nicely) and re-add a resource with all attributes cloned except the > changed ones. > > Probably we need this kind of operations not only for ds and it have to > be designed considering also the effort guys are doing for nice shutdown > of the server. > > just my 2C > > S. > > On 05/05/2011 03:10 PM, Heiko W.Rupp wrote: >> Hi, >> >> I understand that for many configuration changes, direct editing of values (i.e. write-attribute) is not supported for various reasons >> - only changing one attribute may introduce inconsistencies >> - applying the change would require a restart >> >> So the result is that many items (better name?) just allow to :remove them and then to :add >> them again. >> >> This may be fine for items that only have one or two attributes, >> but for a data source as an example with 30 attributes, it is a pain for the user that >> is not using the embedded console or RHQ to specify them all in a curl statement >> or even in the :add(...) command in the CLI just to increase some Tx timeout or to provide >> a different password. >> >> There are of course other items in the management tree where this applies as well. >> >> Heiko >> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I don't have an answer to the technical solution, but from the a users perspective, this doesn't work out at all. Towards a solution, it might help to break the requirements into a) modifications to the configuration b) applying the new configuration to runtime components. If b) requires a restart, fine. That's something we can explain to the user. But a) still needs to be possible, even when then changes are not applied immediately. There is no way we can tell people: "In order to change the password for connecting to the database, you need to delete the DS config and start over." This issue pops up every once in a while and we tried to work around it. But let's face it: It's a shortcoming of the current design. I do completely understand the reasons that lead to the current approach, but I believe it's pretty much useless to move forward w/o a solution. Ike On May 6, 2011, at 12:10 PM, Stefano Maestri wrote: > I agree, but as answered in another thread there are (staying on your > example of data source) some attributes we can't change runtime. We need > to stop pools and so on. > IOW we would need for these cases a composite operation to remove > (nicely) and re-add a resource with all attributes cloned except the > changed ones. > > Probably we need this kind of operations not only for ds and it have to > be designed considering also the effort guys are doing for nice shutdown > of the server. > > just my 2C > > S. > > On 05/05/2011 03:10 PM, Heiko W.Rupp wrote: >> Hi, >> >> I understand that for many configuration changes, direct editing of values (i.e. write-attribute) is not supported for various reasons >> - only changing one attribute may introduce inconsistencies >> - applying the change would require a restart >> >> So the result is that many items (better name?) just allow to :remove them and then to :add >> them again. >> >> This may be fine for items that only have one or two attributes, >> but for a data source as an example with 30 attributes, it is a pain for the user that >> is not using the embedded console or RHQ to specify them all in a curl statement >> or even in the :add(...) command in the CLI just to increase some Tx timeout or to provide >> a different password. >> >> There are of course other items in the management tree where this applies as well. >> >> Heiko >> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I agree, but as answered in another thread there are (staying on your example of data source) some attributes we can't change runtime. We need to stop pools and so on. IOW we would need for these cases a composite operation to remove (nicely) and re-add a resource with all attributes cloned except the changed ones.

Probably we need this kind of operations not only for ds and it have to be designed considering also the effort guys are doing for nice shutdown of the server. just my 2C S. On 05/05/2011 03:10 PM, Heiko W.Rupp wrote: > Hi, > > I understand that for many configuration changes, direct editing of values (i.e. write-attribute) is not supported for various reasons > - only changing one attribute may introduce inconsistencies > - applying the change would require a restart > > So the result is that many items (better name?) just allow to :remove them and then to :add > them again. > > This may be fine for items that only have one or two attributes, > but for a data source as an example with 30 attributes, it is a pain for the user that > is not using the embedded console or RHQ to specify them all in a curl statement > or even in the :add(...) command in the CLI just to increase some Tx timeout or to provide > a different password. > > There are of course other items in the management tree where this applies as well. > > Heiko > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev