RHQ and the future of alerts

So don't get me wrong, alerts will stay within RHQ - I am not questioning them.
In contrary - I am actually working on improving the alert subsystem. As a start I've written some design documents that can be found on the RHQ wiki:

• Alerts architecture overview


• Pluggable alert senders

Please go through them and give us feedback.

But before I continue - a little teaser:

I've extended the Mobicents sender in my experimental branch (see 'Jopr talking') to also support sending via SMS now. So the image above shows an alert sent via that mechanism. Thanks to Jean Deruelle again for helping me on the Mobicents side.

But now back to future alert design...

We have identified the following four fields of change / improvement:

• Allow for pluggable alert senders


• Allow to acknowledge alerts by users


• When a resource is in maintenance mode, do not send alerts about it


• Escalate alert notifications if an alert is not reacted on

Of course some of those are meant for the future - e.g. there is no maintenance mode yet.

The first thing - which I am currently working on are pluggable alert senders. So if you want to e.g write a sender that posts alert notifications to an IRC channel, you can do so now. This is done in a pluggable fashion, which means that the code that does the work and also the UI is encoded in your plugin.

If you want to write such a plugin, you need to do two things:

Extend the abstract AlertSender class and write a plugin descriptor (here is the schema)

I've started an example on how to use this API.

Note that all of this is not yet finished and may change at any time - again I'd like to hear your feedback.

In the very first version only UI elements that follow a <configuration> will be supported. Later it will also be possible to supply a XHTHL snippet for UI fields, where you need to write your own backing beans to transfer the values into the alert subsystem.

Struts 1 and enums - heads up

I lost some good hours on the weekend trying to find out, why a field in my struts form bean was not filled with the correct value, while I could see in the HttpRequest, that the browser / page was indeed sending the correct data.

My form bean contained something like:

public class MyBean extends ValidatorForm {
 
   private MyEnum anEnum;
   private String someField;
 
   public MyEnum getAnEmum() {...}
   public void setAnEnum(MyEnum val) {...}
 
   public String getSomeField() {...}
   public void setSomeField(String val) {...}
}

Not only did my class compile well, I also did not get any errors when running the code - except that anEnum was always populated with the first value listed in MyEnum.

After I changed anEnum to String (and the getter/setter too) and did the conversion to Enum in the backend code, all was fine.

And yes, after I found the solution, I remembered, that we did have such an issue in the past already :-/