Describe and introduce classes to model alarms

Alarm is an indication of an error condition in the system. The distinguishing factor of alarms from other system events, is that alarms have a "severity".

According to management standard the severities are:

public static final int SEVERITY_NORMAL = 0;
public static final int SEVERITY_WARNING = 1;
public static final int SEVERITY_MINOR = 2;
public static final int SEVERITY_MAJOR = 3;
public static final int SEVERITY_CRITICAL = 4;
public static final int SEVERITY_UNKNOWN = 5;

Another characteristic of alarms is that they can be "stateful" or "stateless".

/** the possible states of an alarm */
public static final int STATE_CLEARED = 0;
public static final int STATE_CHANGED = 1;
public static final int STATE_CREATED = 2;
public static final int STATE_NONE = 3;

A stateful alarm represents an error condition in the system, e.g. "jboss.alarm.memory.low", that can "clear" itself. So at some point the server indicates it is low on memory, but after a GC the memory levels go back to normal so the alarm is automatically cleared. For the server (or the mbean that produces the alarm) to do that, it must keep track of the alarm status.

A stateless alarms indicates an instantanious error condition, e.g. security violation, or deployment failed. The error producing mbean doesn't keep track of the error condition to report a clearance of the error (or this may be simply imposssible).

A common source of confusion is that we associate an alarm with the Notification carrying the alarm. A notification is simply an "event in transit". In the case of stateless alarms, the notification carries the full state of the alarm, because every instantiation of the alarm is a separate event. But with stateful alarms, the notification mearly carries the state change of the alarm, i.e. you can have 3 notifications referring to the same logical alarm condition.