Description of problem: EAP server doesn't need to have datasource disabled to make configuration changes. Some properties require reload in order to apply, but that is ok. From user point of view. If user would need to disable datasource (that requires currently reload of the server), change configuration and then again enable the resource, it is too many operations in order to change just one property. There can be required reload, but that is true for both cases whether you disable datasource before editing or configuration change is done on enabled datasource. Version-Release number of selected component (if applicable): JON 3.2.0 How reproducible: always Steps to Reproduce: 1. import EAP 6 server to JON 2. create datasource 3. check that datasource is enabled (if not enable it) 4. try to change any configuration value Actual results: datasource has to be disabled to make changes in configuration Expected results: make the changes with potential informative message that reload is required for the changes to apply Additional info: This is regression to JON 3.1.2 where wasn't necessary to disable datasource before editing its configuration This is also related to https://bugzilla.redhat.com/show_bug.cgi?id=999976, but when I try to change the configuration of the enabled xa-datasource via EAP CLI, it works, therefore there should be another better solution with lower impact on worsening user experience
Adding bug 1020880 to see also as these are very closely related. Bottom line is that a user should be able to modify the configuration without performing extra steps or performing a server restart. EAP supports the ability to modify most configuration attributes without a restart. Furthermore, a disable is not required either. Looking at bug 999976 I would also agree that the action taken there was a very bad one. All that does is explains that the plug-in is broken by design instead of fixing the invalid implementation.
Moving to unspecified target milestone as only JON 3.2.0 'blockers'(https://url.corp.redhat.com/bz-jon32-blockers-list-notmodified-nodocs) will make it into subsequent builds after ER5.
Asking Thomas to revisit this prior to 3.3.0. Thomas, decide whether we can do something better or if what was done for Bug 999976 is still the best option. There seems to be disagreement about whether enabled/disabled is a valid gating factor.
Already tracked by Bug 1004977 *** This bug has been marked as a duplicate of bug 1004977 ***