Branch: refs/heads/release/jon3.3.x Home: https://github.com/rhq-project/rhq Commit: def8112715dc27123d6e3534c4be7bf255f05ce9 https://github.com/rhq-project/rhq/commit/def8112715dc27123d6e3534c4be7bf255... Author: Lukas Krejci lkrejci@redhat.com Date: 2014-09-22 (Mon, 22 Sep 2014)
Changed paths: M modules/core/domain/src/main/java/org/rhq/core/domain/configuration/ConfigurationUtility.java M modules/core/domain/src/test/java/org/rhq/core/domain/configuration/ConfigurationUtilityTest.java M modules/enterprise/gui/coregui/src/main/java/org/rhq/coregui/client/bundle/deploy/GetDeploymentConfigStep.java M modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/bundle/BundleManagerBean.java M modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/bundle/BundleManagerRemote.java
Log Message: ----------- [BZ 1141982] Readonly required props with defaults forced to same values during bundle deployment.
In the case of new resource creation where the user has the ability to enter an initial value for a readonly property. This is not true with bundle deployment because the configuration object is populated with the default values straight away. This is to make it possible for the server-side bundle plugin to pass on some information to the agent-side bundle handler.
This fix ensures that an update of such readonly property is not possible either through UI or remote API.
In remote API we simply check the supplied deployment configuration more rigorously, disallowing changes of any readonly properties from the default values provided by the deployment configuration definition.
The UI had a clever logic of reusing configuration properties used with the currently live deployment (if any). This approach generally worked but was also updating readonly properties with the values coming from the live deployment which is a wrong thing to do if we understand the readonly props as a way of defining additional metadata about the bundle version generated by the server-side plugin. These should always be relevant to the bundle version being deployed and not taken over from a deployment of some previous bundle version.
(cherry picked from commit 8ddc6ca38e45b6312fb7d903a5f9eef50cf068bb)
Commit: 7a45c9632d23d4b8ef3cdec49b94e3dcf09bce67 https://github.com/rhq-project/rhq/commit/7a45c9632d23d4b8ef3cdec49b94e3dcf0... Author: Lukas Krejci lkrejci@redhat.com Date: 2014-09-22 (Mon, 22 Sep 2014)
Changed paths: M modules/plugins/jboss-as-7/src/main/java/org/rhq/modules/plugins/jbossas7/PatchHandlerComponent.java M modules/plugins/jboss-as-7/src/main/java/org/rhq/modules/plugins/jbossas7/util/PatchDetails.java
Log Message: ----------- [BZ 1136945] Purge/revert of EAP patch bundles works more sanely.
To implement this reasonably, we started tracking the state of patch bundles deployed through RHQ in external file, located under the target Wildfly/EAP server's .installation/.rhq subdirectory (the .installation directory is used by Wfly/EAP itself to keep track of patching, so it is a logical place to add patching related information).
During deployment we determine the effective set of patches that were applied from the patch file (by comparing histories before and after deployment). We then use this information to revert/purge only the patches that were deployed using RHQ. This information is stored per destination in the above mentioned metadata directory (so that multiple destinations per EAP are supported (even though such arrangement is non-sensical)).
In another words all patches applied before a first patch bundle was deployed through a destination are retained after a bundle purge and the revert or purge of the bundle will fail or warn if the history of patch deployment is unexpected (due to external patch rollbacks or applications).
The revert/purge will fail if no patches can be rolled back due to the state of the history having a different "tip" than expected. A warning is emitted to the audit log if some of the patches that were expected to rollback couldn't be because of some other change in the patch application history.
There situations will only exist if the EAP server is patched through other means than RHQ after it has been patched using RHQ thus creating and inconsistency between what RHQ sees as the deployment history of the destination and the real state on the EAP resources.
(cherry picked from commit d9beded5301ae12e2e20a00dc26c6e0e7cf80962)
Commit: b6e69ef3f250613bc6f74f4d5e1867c3b4882feb https://github.com/rhq-project/rhq/commit/b6e69ef3f250613bc6f74f4d5e1867c3b4... Author: Lukas Krejci lkrejci@redhat.com Date: 2014-09-22 (Mon, 22 Sep 2014)
Changed paths: M modules/plugins/jboss-as-7/src/main/java/org/rhq/modules/plugins/jbossas7/BaseServerComponent.java M modules/plugins/jboss-as-7/src/main/resources/META-INF/rhq-plugin.xml
Log Message: ----------- [BZ 1069547] Adding "Active Patches" trait to Host ctl & Standalone svr
As such, the user now has the overview of the patches applied to the individual Wfly/EAP servers in their env. This complements the bundle subsystem from which the same information could be deduced, too, under the assumption that RHQ server would be the sole "issuer" of the patches to the servers.
(cherry picked from commit 5336d8c3380a8af3c8b9d73f4c2fc4da2c4e7a0a)
Commit: e5579a170ad0008b40f2ab589ee802d041dec3e5 https://github.com/rhq-project/rhq/commit/e5579a170ad0008b40f2ab589ee802d041... Author: Lukas Krejci lkrejci@redhat.com Date: 2014-09-22 (Mon, 22 Sep 2014)
Changed paths: M modules/plugins/jboss-as-7/src/main/java/org/rhq/modules/plugins/jbossas7/PatchHandlerComponent.java
Log Message: ----------- [BZ 1140578] Change the patch name delimiter also on the agent-side.
(cherry picked from commit 6f5c3811fd1d15e1ce76c53f82cb43ee07f6610f)
Compare: https://github.com/rhq-project/rhq/compare/897a8b3165ba...e5579a170ad0