Spring's JMX offering includes comprehensive support for JMX notifications.
Registering Listeners for Notifications
Spring's JMX support makes it very easy to register any number of NotificationListeners with any number of MBeans (this includes MBeans exported by Spring's MBean Exporter and MBeans registered via some other mechanism). By way of an example, consider the scenario where one would like to be informed (via a Notification) each and every time an attribute of a target MBean changes.
With the above configuration in place, every time a JMX Notification is broadcast from the target MBean (bean:name=testBean1), the Console Logging Notification Listener bean that was registered as a listener via the notification Listener Mappings property will be notified.
The ConsoleLogging NotificationListener bean can then take whatever action it deems appropriate in response to the Notification.
You can also use straight bean names as the link between exported beans and listeners:<beans>
If one wants to register a single NotificationListener instance for all of the beans that the enclosing MBeanExporter is exporting, one can use the special wildcard '*' (sans quotes) as the key for an entry in the notificationListenerMappings property map; for example:<property name="notificationListenerMappings">
If one needs to do the inverse (that is, register a number of distinct listeners against an MBean), then one has to use the notification Listeners list property instead (and in preference to the notification Listener Mappings property). This time, instead of configuring simply a Notification Listener for a single MBean, one configures Notification Listener Bean instances... a Notification ListenerBean encapsulates a Notification Listener and the ObjectName (or ObjectNames) that it is to be registered against in an MBeanServer. The Notification ListenerBean also encapsulates a number of other properties such as a Notification Filter and an arbitrary handback object that can be used in advanced JMX notification scenarios.
The configuration when using NotificationListenerBean instances is not wildly different to what was presented previously:<beans>
The above example is equivalent to the first notification example. Lets assume then that we want to be given a handback object every time a Notification is raised, and that additionally we want to filter out extraneous Notifications by supplying a Notification Filter. (For a full discussion of just what a handback object is, and indeed what a Notification Filter is, please do consult that section of the JMX specification (1.2) entitled 'The JMX Notification Model'.)<beans>
Spring provides support not just for registering to receive Notifications, but also for publishing Notifications.
The key interface in Spring's JMX notification publication support is the Notification Publisher interface (defined in the org. spring frame work. jmx. export. notification package). Any bean that is going to be exported as an MBean via an MBeanExporter instance can implement the related Notification Publisher Aware interface to gain access to a Notification Publisher instance. The Notification Publisher Aware interface simply supplies an instance of a Notification Publisher to the implementing bean via a simple setter method, which the bean can then use to publish Notifications.
As stated in the Javadoc for the NotificationPublisher class, managed beans that are publishing events via the NotificationPublisher mechanism are not responsible for the state management of any notification listeners and the like ... Spring's JMX support will take care of handling all the JMX infrastructure issues. All one need do as an application developer is implement the NotificationPublisherAware interface and start publishing events using the supplied NotificationPublisher instance. Note that the NotificationPublisher will be set after the managed bean has been registered with an MBeanServer.
Using a NotificationPublisher instance is quite straightforward... one simply creates a JMX Notification instance (or an instance of an appropriate Notification subclass), populates the notification with the data pertinent to the event that is to be published, and one then invokes the sendNotification(Notification) on the NotificationPublisher instance, passing in the Notification.
Find below a simple example... in this scenario, exported instances of the JmxTestBean are going to publish a NotificationEvent every time the add(int, int) operation is invoked.package org.springframework.jmx;
The NotificationPublisher interface and the machinery to get it all working is one of the nicer features of Spring's JMX support. It does however come with the price tag of coupling your classes to both Spring and JMX; as always, the advice here is to be pragmatic... if you need the functionality offered by the Notification Publisher and you can accept the coupling to both Spring and JMX, then do so.
Java-Springs Related Interview Questions
|Adv Java Interview Questions||J2EE Interview Questions|
|Core Java Interview Questions||JSP Interview Questions|
|Java-Springs Interview Questions||Java Servlets Interview Questions|
|JMS(Java Message Service) Interview Questions||Hibernate Interview Questions|
|Java applet Interview Questions||Java Interview Questions|
|Framework7 Interview Questions||Java collections framework Interview Questions|
|Java 8 Interview Questions||Java Programmer Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.