4:22 p.m.
Branch: refs/heads/master
Home: https://github.com/hawkular/hawkular-alerts
Commit: b5e0dff913a1afe8cdba5ee9e2f41a5ad0cd4118
https://github.com/hawkular/hawkular-alerts/commit/b5e0dff913a1afe8cdba5e...
Author: Jay Shaughnessy <jshaughn(a)redhat.com>
Date: 2015-07-17 (Fri, 17 Jul 2015)
Changed paths:
M
hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/json/JacksonDeserializer.java
M
hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/AvailabilityConditionEval.java
M
hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/CompareConditionEval.java
M
hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/ConditionEval.java
M
hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/ExternalConditionEval.java
M
hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/StringConditionEval.java
M
hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/ThresholdConditionEval.java
M
hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/condition/ThresholdRangeConditionEval.java
M hawkular-alerts-api/src/test/java/org/hawkular/alerts/api/JsonJacksonTest.java
Log Message:
-----------
Fix bug in 'type' attribute handling in JacksonDeserializer
There was a bug in the 'type' attribute handling in deserializeCondition.
But after some examination I simplified things a bit by:
- Have the ConditionEval subclasses set their 'type' at construction time.
There is only one valid type, just set it. This is now analogous to
Condition, where the type is also set at construction.
- Given that we can depend on the type field being set, simplify the
'type' handling in the deserializer.
- Also, convert to switch stmts on the enum for clarity.
- Note, this fixed a bug in ExternalConditionEval where type was not being
set correctly.
Commit: d913dacfd413edd6d2c9618f518c0ce52c3ec50a
https://github.com/hawkular/hawkular-alerts/commit/d913dacfd413edd6d2c961...
Author: Jay Shaughnessy <jshaughn(a)redhat.com>
Date: 2015-07-17 (Fri, 17 Jul 2015)
Changed paths:
M
hawkular-alerts-metrics/src/test/groovy/org/hawkular/alerts/external/ExternalMetricsITest.groovy
Log Message:
-----------
Update to reflect that fetchAlerts now returns 200+emptyList as
opposed to 204. Also, use only junit asserts.
Commit: 8c5d85ca7ed6903164629134684223ed5aa51002
https://github.com/hawkular/hawkular-alerts/commit/8c5d85ca7ed69031646291...
Author: Jay Shaughnessy <jshaughn(a)redhat.com>
Date: 2015-07-17 (Fri, 17 Jul 2015)
Changed paths:
M
hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/services/AlertsService.java
M
hawkular-alerts-engine/src/main/java/org/hawkular/alerts/engine/impl/AlertsEngineImpl.java
M
hawkular-alerts-engine/src/main/java/org/hawkular/alerts/engine/impl/CassAlertsServiceImpl.java
M
hawkular-alerts-engine/src/main/java/org/hawkular/alerts/engine/impl/DroolsRulesEngineImpl.java
M
hawkular-alerts-engine/src/main/java/org/hawkular/alerts/engine/rules/RulesEngine.java
M
hawkular-alerts-engine/src/main/java/org/hawkular/alerts/engine/service/AlertsEngine.java
M
hawkular-alerts-rest-tests/src/test/groovy/org/hawkular/alerts/rest/LifecycleITest.groovy
Log Message:
-----------
Fix issue in handleAutoResolvedTriggers() where we reloaded the trigger
multiple times if autoResolveAlerts=true.
Moreover, protect against unnecessarily reloading a trigger. If a trigger
is already in firing mode, don't reload it just to set it to firing mode.
- make RulesEngine.getFact more useful, return the fact object, not the FactHandle
- add AlertsEngine.getLoadedTrigger in order to see the actual (non-persisted)
state of a trigger in the engine.
- add a test for this case
Compare: https://github.com/hawkular/hawkular-alerts/compare/ea91916099c6...8c5d85...