In RHQ we use the Augeas library to do the configuration file parsing and updates for us in some of the plugins. Augeas in itself is pretty cool and the language for describing the structure of arbitrary configuration files and howto update them is pretty powerful. The only downside to using Augeas is that it is a C library and we therefore have to bind with it and use it more carefully so that we don’t leak its native resources that aren’t under control of JVM’s garbage collector.

TestNG defines a @Listeners annotation that is analogous to the listeners element in the test suite configuration xml file. This annotation can be put on any class but is not applied only to that class, but uniformly on all the tests in the test suite (which is in line with the purpose of the original XML element but it certainly is confusing to see an annotation on a class that has much wider influence but that single class).

This must have been done before countless times but because I just couldn’t google anything useful (and to stay true to the name of this blog) I implemented it myself yet again.

We are currently starting to think about what would it take to implement exporting and importing various "configuration" elements including metric and alert templates, server configuration, dynagroup definitions, users & roles and possibly other "entities" between different RHQ installations.

Since RHQ3, we support "alert sender" server plugins. Basically an alert sender is a piece of code that can generate some sort of response to the firing of an alert.

Humans make mistakes. That’s because they learn and by making mistakes and experimenting they perfect their skills. Computers on the other hand only do as they are told. When a human interacts with the computer, she expects the computer to be human-like to the extent that it can recover or react to the mistakes she makes while learning the rules of interaction with it.

In my previous post I talked about the approach I took to export data from a database using a JPA model. I also mentioned that that was a part of a larger effort to support performance testing that we are currently implementing for RHQ. This post is a follow-up on that theme. This time we’re going to take a look at how to use the exported data in TestNG based tests.

In RHQ, we are currently contemplating implementing a series of automated performance tests. For those tests to make any sense, we have to provide them with some initial data to work with.

RHQ is not built to be used by thousands of users at the same time. We rather add features to the page so that it contains maximum information and context so that the users can make the right decisions about their infrastructure. But even then we do care about a responsive and reasonably performing UI (and the system as a whole of course).

Well, the time has come for me to reinvent the wheel. This is going to be a blog about stuff that I find interesting as I move along my way of an open-source developer.