All of the previous releases for RHQ are listed with information about new features and bug fixes.
Resource Configuration
better drift support
Server Enhancements
enhanced config sync
Support for PostgreSQL 9.1
performance enhancements
UI Enhancements
start supporting a REST api to have some endpoints around and to play with it.
Resource Support
enhanced JBoss AS 7 plugin
bug fixes
UI Enhancements
update of GWT / SmartGWT to support more modern browsers
Bug fixes
Better REST API support
Option to dump the system state to the server log in order for diagnosing
Improvements in availability handling
better as7 support
increased test coverage
exporting of reports
Performance enhancements
Plugin I18N
more REST work
Changes in charting (replace the old struts/JSP code and replace with a GWT solution; GSoC work)
Build with maven 3
Running on JDK 7
Two bugfixes for RHQ 4.5.0
Removal of web services
Removal of (for a long time not built
These features are almost certainly going into a future release of RHQ. We like 'em.
TBD
These are ideas and things that could be nifty to include but that don't have a plan yet.
Adding support for MS SQL as a backend: Design - MS SQL Server DB backend
Add auditing framework for RHQ operations
Remote server install
consistent write/read perms for all subsystems, i.e. CONTROL becomes OPERATION_READ and OPERATION_WRITE, just like CONFIGURE became CONFIGURE_READ and CONFIGURE_WRITE
authorization fixes
conditionally render tabs or disable/lock tabs? conditionally render buttons or disable/lock buttons?
Change tree so that relationship other than parent-child can be defined
A visual inventory browser
More managed resource plugins
what resources could be added?
Add mod_jk monitoring
What kinds of metrics could be collected?
Allow for different availability check intervals depending on resource or resource type to e.g. check "important" resources more often.
A syslog alert sender plugin that can talk to remote syslogd to deliver alert notifications
Alerts based on total group measurements
true group alerting – e.g. "3 of 5 resources are down" or "the average heap usage is <yadda>"
Combining data from different resources and types to trigger alerts on this combined data
Allow to create derived metrics in a sense that the metric is the result of some computation like e.g. the difference of created vs. destroyed session bean instances. Or full servlet execution time minus some SLSB method time and so on.
Send alerts based on trends
Track downtime to help monitor SLAs
Availability alerting – not exactly or not all of what users expect (i.e. down and has been down for 10 minutes)
Alert sending schedules (bucketing)
instead of getting alert notification storms, allow the user to configure when he/she should get notifications; so the system will queue up notifications and then send, in a single email, all queued notifications every 10 minutes for that user
composite alerting
instead of an alert definition being tied to a single resource or a single group or a single type (alert template), allow each alert condition to be related to a resource / group. this way you can say "if average web server group metric is <foo>" or "if average app server service metric is <bar>" or "if database metric is "yadda" then alert
complex alerting
more flexible alert condition processing - today we only support 'AND' vs 'OR' - let's support complex conditions such as (a AND (b OR c))
in-line call-time instructions
instead of forcing users to go to our documentation to figure out how to instrument their WARs for call-time data collection, make the web.xml snippet and instructions available in the monitor>response sub-tab itself. this way users go there, realize they haven't instrumented their app, and can easily copy/paste into their application's web.xml
in-line call-time enablement
instead of forcing the users to go monitor>schedules to enable call-time data on the server-side for a resource (or group) enable them to click a quick link within the monitor>response tab which will enable the appropriate schedule automatically...or, at the very least, provide a link that takes them to monitor>schedules with instructions on what to do (this means that we should always keep the monitor>response sub-tab enables for resources that support it)
in-line call-time setup
instead of forcing users to go to inventory>connection, allow viewing and alteration of the response time properties (log file, url excludes, url transforms) in line with the tabular results
in-line event source setup
instead of forcing users to go to inventory>connection, move the creation to a new sub-tab called event>sources (or even in-line the viewing/editing of event sources at the top of the audit trail / table
A standalone (Swing?) bundle creation tool. Bundles are the way to provision complex software installations onto managed machines. There is some support for creating bundles already (e.g. bundleGen and some cli scripts), but those could become more comfortable for the user to use.
Finish group-wise content functionality
Push this EAR out to that cluster; update (in rolling fashion) this clustered WAR
Comparing different resource configs and copying changes
Incorporating third-party GUIs into the RHQ GUI
Better subtab nav / better alert definition subtab view
jshaughn: the default alerts subtab is definitions. Would be nice if this list view gave some indication of alerts generated for the listed defs. today you have to click again and go to the history subtab to see if anything actually happened. maybe not a big deal given that alert notification is probably the primary mechanism for knowing if something happened
joseph: would be nice if users could hover over the alerts main-tab, and the sub-tabs would be auto-visible options to choose from before clicking
ips: jshaughn: +1. in addition to having an Alerts (Count) colun, we could potentially also add a Last Fired column with a dateTime
jshaughn: both of those would be nice
jshaughn: i like the subtab hover a lot, i hate having that multi-step process to get where I'm going
jshaughn: would be very useful for Inventory tab as well
joseph: yeah, preview functionality is not only bad ass, but often times actually useful too ; )
resource "actions"
either right-hand side panel (collapsable) vs. pop-up menu somewhere on the content area vs. quick action icon (next to avail check and favorite badge)
ajax feedback mechanism
add an "in progress" spinner to all pages when gwt is doing something async - this might be done at the global level for all pages if there are any async things happening, or perhaps it should be relevant to the content area that is doing the async work.
event>source sub-tab
move event sources out of plugin config into event>configure sub-tab to sit alongside event>history sub-tab - this will also allow event source reconfiguration without having to restart the agent-side resource component, and allow for a more directed/concise UI for group-wise updates of just the event logging stuff
search trees
searchable resource / group trees - a tree showing search results might be a flattened but disambiguated result list, or it might be greyed inner tree nodes
parameterized web context
make coregui web context a configurable parameter as part of the build (<address>:7080/<context>/) so that we can have, for example, "/rhq" or "/jon"
Improve the availability reporting lag
precompute resource disambiguation
pre-compute resource disambiguation / lineage / hierarchy - the read/write profile is heavily weighted towards the read-access since nearly all fragments of all pages across the site need to be disambiguated. this would also enable us to easily expose lineage data via the remote API, instead of disambiguation being a UI-only thing
Add more flexibility for the remote agent install: Design-RemoteAgentInstall
Separate agent heartbeat from availability reporting
Provide translations of e.g. Alert messages or Installer messages
maven build forking
fix maven build to fork javac for most (all?) modules, this will lower the maximum memory requirement (Xmx) when building from scratch, as well as lower the needed memory when building individual modules (the common case)