Branch: refs/heads/release/jon3.3.x
Home:
https://github.com/rhq-project/rhq
Commit: ee7abdce0d41b3797ea36e961067699b632858eb
https://github.com/rhq-project/rhq/commit/ee7abdce0d41b3797ea36e961067699...
Author: Jay Shaughnessy <jshaughn(a)redhat.com>
Date: 2014-08-27 (Wed, 27 Aug 2014)
Changed paths:
M modules/core/domain/src/main/java/org/rhq/core/domain/cloud/StorageNode.java
M
modules/enterprise/gui/coregui/src/main/java/org/rhq/coregui/client/admin/storage/StorageNodeDatasource.java
M
modules/enterprise/gui/coregui/src/main/java/org/rhq/coregui/client/admin/storage/StorageNodeDetailView.java
M
modules/enterprise/gui/coregui/src/main/java/org/rhq/coregui/client/admin/storage/StorageNodeLoadComponent.java
M
modules/enterprise/gui/coregui/src/main/java/org/rhq/coregui/client/admin/storage/StorageNodeTableView.java
Log Message:
-----------
[1071282] disk size used by storage metric is invisible when no metric is collected
[1071291] no-data-available metric values for storage node metrics
The --no-data-available-- is our standard text formatting when a Double is
either null or NaN (using MeasumenentConvertClient). So I couldn't just change
that across the board. But in this instance I agree the table looked
odd and inconsistent. So, now using "NaN" in this scenario. As for the
missing metric entry, certain metrics are simply not able to be reported
immediately. For the one in question I made sure it is there, if possible,
with "NaN" values.
But understand that it is possible to actually get no metrics for a very
brief period after import. Also, it is possible the metric set may lack a
metroc or two for a brief period. The fix covers things as best as
possible. Remember that this entire issue goes away very quickly, as soon
as metrics are initially reported.
Probably more important than the BZ changes were some fixes I found along
the way:
- limit the StorageNode.QUERY_FIND_UNACKED_ALERTS_COUNTS query to committed
storage node resources, otherwise it can report incorrectly. (sorry for the
file reformat)
- Fix the AVAILABILITY column handling, use our more common approach to
avoid some issues. It was working a bit by luck.
- Fix the STATUS field record value, it should be a string.
- Change some formatting to allow more space both for the metrics table
as a whole (in the detail view) and also the metric name column.
- Fix clusterStatusItem value, it should be a String.
- Fix messageItem value, it should be a String.
- Protect against a potential bad widget ID
- Apply CellFormatters prior to setting ListGridFields, and Fix == to be
equals() to ensure proper CellFormatter is applied
(cherry picked from commit 536f7ec548a95c0ae573bf86ce8fdbd0dcafbea0)
Signed-off-by: Jay Shaughnessy <jshaughn(a)redhat.com>