A higher level of JMX Notification

Hi everybody.

While JMX has a great way of communication towards the MBeans through the use of high level interfaces, the notification mechanism is only available through a pre-determined interface (the NotificatioListener) that support only the passage of some pre-determined information such as a timestamp, a counter, a string message and an object.

I've developed an idea of mine that enables the use of high level interfaces also to obtain notifications from the MBeans. For example:

publicinterface CountNotifier{

void countChanged(int newValue);

}

will be an interface used both on the MBean and the client sides. On the MBean side the programmer will simply call

countNotifier.countChanged(count);

in order to notify registered listeners instead of creating a javax.management.Notification object and send it.

On the client side, the programmer will register an implemention of CountNotifier, for example:

new CountNotifier(){

@Override

publicvoid countChanged(int newValue){

System.out.println("Notification of new value: " + newValue);

}

}

I've realized a little demonstrative draft implementation of an extension to the JMX API. You can find it in the lib package (there's actualy one helper class with 2 static methods, one for the client and one for the server and an annotation, this should be used to annotate the MBean with the interfaces of notifier that it supports).

In the example package there are some classes that show how the programmers on MBean side and on the Client side can write the code to use this new higher level notification feature.

https://devel.savona.cnit.it/~perr/jmx-notification.zip

please, accept the certificate ;-)

I look forward to hearing your opinions.

Marco P.

[2296 byte] By [-._marco_.-a] at [2007-11-27 6:51:58]
# 1

Marco,

This is a pretty neat idea! It's a good way of making notifications less verbose both on the server and on the client sides.

I think we might want to explore how we could make some variant of this idea a part of the JMX API. For example, we could make the method arguments part of the Notification's UserData (as you do) but using the MXBean framework to do the serialization.

Concerning your implementation, you could make Java serialization work by assuming that the notification interface (CountNotifier in your example) does not contain overloaded methods. So you could iterate over Class.getMethods() looking for one with the right name.

You can eliminate the need for @SuppressWarnings("unchecked") in the newNotifierProxy method by using intf.cast(Proxy.newProxyInstance(...)). Also, I think the ClassLoader argument should be intf.getClassLoader().

In the registerNotifier method, couldn't the type of the listener argument be T instead of Object?

Feel free to mail me (firstname.lastname@sun.com) to discuss this further.

Regards,

蒩monn McManus -- JMX Spec Lead -- http://weblogs.java.net/blog/emcmanus

emcmanusa at 2007-7-12 18:26:33 > top of Java-index,Core,Monitoring & Management...