CODEWITHSUNDEEP
javajmx
Cincinnati Joe
Cincinnati Joe

Reputation: 2127

Best practice for emitting JMX notifications

Looking for guidelines when defining an MBean that emits notifications, specifically on the type of notifications. The JMX Best Practices on Oracle's site says the following. But it's a bit old and pre-Java6.

Notifications should be instances of javax.management.Notification or one of the subclasses from the javax.management namespace. Information that does not fit into one of those subclasses should be conveyed by attaching a CompositeData to the notification using the setUserData method.

Also on Oracle's site, I see that Weblogic defines some of its own subclasses, e.g. WebLogicLogNotification. Its Best Practices states:

All JMX notification objects extend the javax.management.Notification object type. JMX and WebLogic Server define additional notification object types, such as javax.management.AttributeChangeNotification. The additional object types contain specialized sets of information that are appropriate for different types of events.

Our notifications don't fit any of the standard subclasses, so like WLS, considering defining our own subclass with custom getters for the information we wish to convey with the notifications. Or would it be better to stick with the base javax.management.Notification and just attach our info with the generic setUserData(Object)? If we do the latter, I suppose the Object should be a JMX type such as CompositeData, which doesn't seem as nice. Thoughts on which would be better from a consumer's point of view?

EDIT: From the consumers view, I guess the downside of a custom subclass is they would have to include that in their application/classpath.

Upvotes: 3

Views: 1448

Answers (1)

jtahlborn
jtahlborn

Reputation: 53694

it's almost always a bad idea to use custom data types in jmx. it is very limiting. stick to the open types and your data can be consumed by any jmx client (java or otherwise).

note, you can always provide some helper classes which do some sort of "custom bean" <-> "open type" conversion. classes which have access to the helper classes can utilize these convenience methods (e.g. ThreadInfo.from()), while external and non-java code is still able to consume the data.

Upvotes: 4

Related Questions