The GUI could then use this metadata as follows: * for a Resource type that has storeType="MEMORY": all loads and updates are done from memory. * for a Resource type that has storeType="PERSISTENT": all loads and updates are done from disk or other persistent data storage * for a Resource type that has storeType="BOTH": all loads are done from disk, but for updates the user can select whether: a) the update should only be persisted to disk, or b) the update should also be persisted to memory (i.e. put into effect in the running server instance) As a concrete example, in the current code, if the user updates a JMS Queue's resource config, the changes are persisted to the associated xml file, but if that Queue is deployed via a nested config file (e.g. within a SAR) or the deployment scanner is disabled, that Queue continues using the old config until its xml file is either manually redeployed or the app server is restarted. Even if the deployment scanner is enabled and it is deployed at the top level, the in-memory Queue would not get updated until next time the deployment scanner runs (60 seconds by default in EAP). The feature proposed by this JIRA would give the user the ability to choose to immediately enact the change to the running Queue by selecting an "update configuration in memory, as well as to disk" checkbox when updating the config.
(6:53:29 PM) ccrouch: I agree there is some mileage in letting people choose between updating the current running image or waiting for the change to get picked up at restart (6:53:55 PM) ccrouch: but then we're going to have to maintain two config copies (6:54:02 PM) ccrouch: one of the currently running version (6:54:11 PM) ccrouch: and one of the version which is about to be running (6:54:28 PM) ccrouch: if they choose to have it take effect later (6:54:49 PM) ccrouch: its quite an advanced use case, compared to where we are now :-) No, you wouldn't have to maintain two config copies. For configs with a storeType of "BOTH", if the user does not choose the "update configuration in memory, as well as to disk" option when updating the config, the configuration update will only be persisted to disk and only this version of the config will be saved to JON's config history. Just as it is today, the in-memory version will not be saved to the JON history. The only time the in-memory version will be saved to JON's history is when the storeType is "MEMORY".
I'm not so sure about this one. If there are potentially multiple definitions of what the current config is (on disk vs. in memory) then we can't show the user accurate information. I'm in favor of leaving it up to the plugin to define current.
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-950