JMX notification alternatives

Hello,

I had the inital idea to implement an alarm system using jmx notifications. From my interpretation this generates alot of code clutter in every class looking to send alarms. Even the base class of javax.management.Notification has a minimal constructor requiring a local variable sequenceNumber.

Another idea would be to directly instantiate a new custom Alarm class who doesn't require the implementation of mbean interface or local variables. A little shortened:

publicclass Alarm(){

String type; Object source; String Message;

public Alarm(String type, Object source, String message){

this.type = type ;

this.src = ... ;

.....

/* Register this alarm to an Alarm manager */

AlarmManager.getInstance().addAlarm(this);

}

/* Accessors and mutators .... */

}

publicclass AlarmManager{

private AlarmManager(){/* Singleton */}

publicstatic AlarmManager getInstance(){

if(instance ==null){

instance =new AlarmManager();

}

return instance;

}

publicvoid addAlarm(Alarm alarm){

/* Store alarm, parse and perform action */

}

}

I haven't fully tested to plan and for sure can tell if it's actually possible. But the thought of having an Alarm register itself to an AlarmManager seams quite appealing. The AlarmManager in turn may have filters and sophisticated methods to determine proper course of action for the incoming alarms.

A second requirement is to be able to enable/disable an alarm. I don't quite see a reason to disable alarm-sending in the class generating the alarm, since that adds extra code redundant to processing the class's normal responsibilities. Rather, the AlarmManager may comprise of methods for throwing away or otherwise disregard incoming alarms based on some user-defined filter.

Does this seem like valid idea, or are there other choises of implementing jmx notifications which involves generating minimum code at the many classess generating alarm-notifications (Possibly an implementation the way org.apache.logging.logfactory is commonly used for logging.) ? The AoP approach doesn't seem appropriate either.

Not that it matters a whole lot, but this application is constructed using spring 2.0.

Does this seem like a valid idea, or is jmx by some left-out functionality still the better choise?

Message was edited by:

Toxic

[3468 byte] By [Toxica] at [2007-11-27 11:14:59]
# 1

( I have another thought using JMX notifications with spring 2.0. The easiest way to send notifications is to inherit from NotificationBroadcasterSupport, however trouble arises when inheritance is already in use.

Is there a nice way to avoid implementing addNotificationLister, removeNotificationListener and sendNotification which are part of the otificationBroadcaster ? )

......and at the expense of coupling to both spring and jmx the notificationPublisher is an excellent tool to satisfy my demands .........

Message was edited by:

Toxic

Message was edited by:

Toxic

Toxica at 2007-7-29 14:10:20 > top of Java-index,Core,Monitoring & Management...