title: Best practice for emitting JMX notifications
body: <p>Looking for guidelines when defining an MBean that emits notifications, specifically on the type of notifications. The <a href="http://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html" rel="nofollow">JMX Best Practices</a> on Oracle's site says the following. But it's a bit old and pre-Java6.</p>
  
  <blockquote>
    <p>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.</p>
  </blockquote>
  
  <p>Also on Oracle's site, I see that Weblogic defines some of its own subclasses, e.g. WebLogicLogNotification. Its <a href="http://download.oracle.com/docs/cd/E12840_01/wls/docs103/jmx/notifications.html" rel="nofollow">Best Practices</a> states:</p>
  
  <blockquote>
    <p>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.</p>
  </blockquote>
  
  <p>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?</p>
  
  <p>EDIT: From the consumers view, I guess the downside of a custom subclass is they would have to include that in their application/classpath.</p>