[rhq-project/rhq] ebe1a3: Prevent ConcurrentModificationExceptions that have...
by Jiri Kremser
Branch: refs/heads/release/jon3.3.x
Home: https://github.com/rhq-project/rhq
Commit: ebe1a3d719736a02f2e7c7921fac83d17e67f029
https://github.com/rhq-project/rhq/commit/ebe1a3d719736a02f2e7c7921fac83d...
Author: Jay Shaughnessy <jshaughn(a)redhat.com>
Date: 2014-09-22 (Mon, 22 Sep 2014)
Changed paths:
M modules/core/plugin-container/src/test/java/org/rhq/core/pc/operation/ParallelOperationsTest.java
Log Message:
-----------
Prevent ConcurrentModificationExceptions that have been showing up in the
Jenkins test runs of this class.
(cherry picked from commit c26c91a29caa7562f6011e1e3bcc937790a498e7)
Signed-off-by: Jay Shaughnessy <jshaughn(a)redhat.com>
Commit: 93a3cfa3650dfe52b9f022973244404cff96d325
https://github.com/rhq-project/rhq/commit/93a3cfa3650dfe52b9f022973244404...
Author: Stefan Negrea <snegrea(a)redhat.com>
Date: 2014-09-22 (Mon, 22 Sep 2014)
Changed paths:
A modules/plugins/cassandra/src/main/java/org/rhq/plugins/cassandra/AntiEntropySessionsComponent.java
M modules/plugins/cassandra/src/main/resources/META-INF/rhq-plugin.xml
M modules/plugins/rhq-storage/src/main/resources/META-INF/rhq-plugin.xml
Log Message:
-----------
[BZ 1084056] Added missing policy to the "Anty Entropy Sessions" type (a single bean) to allow users to configure the behaviour of a missing resourece after a Cassandra or Storage Node server restart
(cherry picked from commit 2dbe6c57daaae87b5ce6890ba0da22c5976c6a7d)
Signed-off-by: Jay Shaughnessy <jshaughn(a)redhat.com>
Commit: 897a8b3165baed336304f5c2d2f2de1cbce83efb
https://github.com/rhq-project/rhq/commit/897a8b3165baed336304f5c2d2f2de1...
Author: Jirka Kremser <jkremser(a)redhat.com>
Date: 2014-09-22 (Mon, 22 Sep 2014)
Changed paths:
M modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/alert/AlertManagerBean.java
M modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/alert/i18n/AlertI18NResourceKeys.java
Log Message:
-----------
[BZ 1145101] - Email alert notification field 'Condition' contains characters which are not part of defined condition - Changing AlertManagerBean.prettyPrintAlertCondition() method to incorporate the changes in alert condition instance for events (the option field is used to carry two regular expression; one for the event details and one for the event source path).
(cherry picked from commit 5e412d56bd3a61f3794f1959e8ce35d7beb47893)
Signed-off-by: Jay Shaughnessy <jshaughn(a)redhat.com>
Compare: https://github.com/rhq-project/rhq/compare/9c86f42aa8ba...897a8b3165ba
9 years, 9 months
[rhq-project/rhq] 9c86f4: [1145298] - AvailabilityProxy can report a false D...
by Jay Shaughnessy
Branch: refs/heads/release/jon3.3.x
Home: https://github.com/rhq-project/rhq
Commit: 9c86f42aa8ba7dd8694902de94d9383f979be34c
https://github.com/rhq-project/rhq/commit/9c86f42aa8ba7dd8694902de94d9383...
Author: Jay Shaughnessy <jshaughn(a)redhat.com>
Date: 2014-09-22 (Mon, 22 Sep 2014)
Changed paths:
M modules/core/plugin-api/src/main/java/org/rhq/core/pluginapi/availability/AvailabilityFacet.java
M modules/core/plugin-container/src/main/java/org/rhq/core/pc/inventory/AvailabilityProxy.java
M modules/core/plugin-container/src/test/java/org/rhq/core/pc/inventory/AvailabilityProxyConcurrencyTest.java
M modules/core/plugin-container/src/test/java/org/rhq/core/pc/inventory/AvailabilityProxyTest.java
Log Message:
-----------
[1145298] - AvailabilityProxy can report a false DOWN
Work related to test failure in AvailabilityProxyConcurrencyTest
- Two changes to AvailabilityProxy itself
- make AvailabilityProxy.getAvailability() a synchronized method. We don't
want two threads calling this concurrently. This is not too likely
in production, given intervals between checks, but may have been possible
when performing a live check. The test code on the other hand was
sometimes failing due to parallel execution of the call.
- stop AvailabilityProxy.getAvailability() from converting UNKNOWN to
DOWN when the avail check is asynchronously in progress. This breaks the
contract as stated in the javadoc and could lead to false DOWN reporting.
(although, conversely, now fixed it could take longer for valid DOWN to
be reported, as a check may need to timeout).
- unrelated but update AvailabilityFacet javadoc to add in valid MISSING state
- work on the test code. replace the concurrent thread approach with the more
realistic serialized calls and change timing around to more predictably
mix some calls that complete synchronously and some that complete
asynchronously.
(cherry picked from commit 417b4570837b87c939a9a458ab4df3bbe0e48369)
Conflicts:
modules/core/plugin-container/src/test/java/org/rhq/core/pc/inventory/AvailabilityProxyConcurrencyTest.java
9 years, 9 months
[rhq-project/rhq] 417b45: Work related to test failure in AvailabilityProxyC...
by Jay Shaughnessy
Branch: refs/heads/master
Home: https://github.com/rhq-project/rhq
Commit: 417b4570837b87c939a9a458ab4df3bbe0e48369
https://github.com/rhq-project/rhq/commit/417b4570837b87c939a9a458ab4df3b...
Author: Jay Shaughnessy <jshaughn(a)redhat.com>
Date: 2014-09-22 (Mon, 22 Sep 2014)
Changed paths:
M modules/core/plugin-api/src/main/java/org/rhq/core/pluginapi/availability/AvailabilityFacet.java
M modules/core/plugin-container/src/main/java/org/rhq/core/pc/inventory/AvailabilityProxy.java
M modules/core/plugin-container/src/test/java/org/rhq/core/pc/inventory/AvailabilityProxyConcurrencyTest.java
M modules/core/plugin-container/src/test/java/org/rhq/core/pc/inventory/AvailabilityProxyTest.java
Log Message:
-----------
Work related to test failure in AvailabilityProxyConcurrencyTest
- Two changes to AvailabilityProxy itself
- make AvailabilityProxy.getAvailability() a synchronized method. We don't
want two threads calling this concurrently. This is not too likely
in production, given intervals between checks, but may have been possible
when performing a live check. The test code on the other hand was
sometimes failing due to parallel execution of the call.
- stop AvailabilityProxy.getAvailability() from converting UNKNOWN to
DOWN when the avail check is asynchronously in progress. This breaks the
contract as stated in the javadoc and could lead to false DOWN reporting.
(although, conversely, now fixed it could take longer for valid DOWN to
be reported, as a check may need to timeout).
- unrelated but update AvailabilityFacet javadoc to add in valid MISSING state
om>
- work on the test code. replace the concurrent thread approach with the more
realistic serialized calls and change timing around to more predictably
mix some calls that complete synchronously and some that complete
asynchronously.
9 years, 9 months
[rhq-project/rhq] 4df0d7: [BZ 1070277] - (JON3-39) JON should (be able to) b...
by Jiri Kremser
Branch: refs/heads/master
Home: https://github.com/rhq-project/rhq
Commit: 4df0d7f411da1a03604e49c6b9d0117965616ca8
https://github.com/rhq-project/rhq/commit/4df0d7f411da1a03604e49c6b9d0117...
Author: Jirka Kremser <jkremser(a)redhat.com>
Date: 2014-09-22 (Mon, 22 Sep 2014)
Changed paths:
M modules/core/dbutils/src/main/scripts/dbsetup/sysconfig-data.xml
M modules/enterprise/gui/coregui/src/main/java/org/rhq/coregui/client/admin/SystemSettingsView.java
M modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/system/SystemManagerBean.java
Log Message:
-----------
[BZ 1070277] - (JON3-39) JON should (be able to) block login to a user without roles - Changing the default of the property to true, i.e. enabling the login for user without roles by default.
Commit: 5e412d56bd3a61f3794f1959e8ce35d7beb47893
https://github.com/rhq-project/rhq/commit/5e412d56bd3a61f3794f1959e8ce35d...
Author: Jirka Kremser <jkremser(a)redhat.com>
Date: 2014-09-22 (Mon, 22 Sep 2014)
Changed paths:
M modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/alert/AlertManagerBean.java
M modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/alert/i18n/AlertI18NResourceKeys.java
Log Message:
-----------
[BZ 1145101] - Email alert notification field 'Condition' contains characters which are not part of defined condition - Changing AlertManagerBean.prettyPrintAlertCondition() method to incorporate the changes in alert condition instance for events (the option field is used to carry two regular expression; one for the event details and one for the event source path).
Compare: https://github.com/rhq-project/rhq/compare/5336d8c3380a...5e412d56bd3a
9 years, 9 months
[rhq-project/rhq] 8ddc6c: [BZ 1141982] Readonly required props with defaults...
by Lukas Krejci
Branch: refs/heads/master
Home: https://github.com/rhq-project/rhq
Commit: 8ddc6ca38e45b6312fb7d903a5f9eef50cf068bb
https://github.com/rhq-project/rhq/commit/8ddc6ca38e45b6312fb7d903a5f9eef...
Author: Lukas Krejci <lkrejci(a)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.
Commit: d9beded5301ae12e2e20a00dc26c6e0e7cf80962
https://github.com/rhq-project/rhq/commit/d9beded5301ae12e2e20a00dc26c6e0...
Author: Lukas Krejci <lkrejci(a)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.
Commit: 5336d8c3380a8af3c8b9d73f4c2fc4da2c4e7a0a
https://github.com/rhq-project/rhq/commit/5336d8c3380a8af3c8b9d73f4c2fc4d...
Author: Lukas Krejci <lkrejci(a)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.
Compare: https://github.com/rhq-project/rhq/compare/317fb0967b34...5336d8c3380a
9 years, 9 months
