JDK-6610917 : Define a generic NotificationFilter
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 2.0,5.0,6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_2.5
  • CPU: generic,x86
  • Submitted: 2007-09-28
  • Updated: 2017-05-16
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b26Fixed
Related Reports
Duplicate :  
JDK-4718350 - RFE: Wildcard support in notification filter
Duplicate :  
JDK-6301223 - Enhance javax.management.NotificationFilterSupport to support complex syntax instead of only prefix
Relates :  
JDK-6602310 - Extensions to Query API for JMX 2.0
Relates :  
JDK-6577604 - MBeanServerNotificationFilter should support ObjectName wildcards
Relates :  
JDK-6611518 - Define a method to add a NotificationFilter locally or remotely
Description
The JMX API today defines an interface NotificationFilter and three concrete implementations of it: AttributeChangeNotificationFilter, MBeanServerNotificationFilter, and NotificationFilterSupport.  If your filter case corresponds to one of these you are in luck, but if not then you need to write a custom filter class.  If you're adding the filter remotely, then you need to arrange for this class to be present on both client and server, which is a pain.

What's needed is to provide a more generic filter class that will cover most cases that users need.  It should certainly be able to do everything that the existing classes, plus cover some common cases that they don't.

Some examples:

    *  An AttributeChangeNotification where the attribute name is "SecurityLevel" or "ErrorCount". (This corresponds to AttributeChangeNotificationFilter.)
    * An AttributeChangeNotification where the attribute type is "int".
    * An AttributeChangeNotification where the attribute name is "SecurityLevel" and the new value of the attribute is greater than 3.
    * An MBeanServerNotification where the ObjectName is "a:b=c" or "x:y=z".  (This corresponds to MBeanServerNotificationFilter.)
    * An MBeanServerNotification where the ObjectName matches "mydomain:*". (This is currently not possible with MBeanServerNotificationFilter, which is bug 6577604.)
    * A Notification where the type string is "my.type.one" or "my.type.two". (This corresponds to NotificationFilterSupport.)
Comments
EVALUATION The proposal is to define the new class such that it evaluates a javax.management.QueryExp against the Notification. Using the query language (see CR 6602310), the cases in the CR description are covered as follows: * An AttributeChangeNotification where the attribute name is "SecurityLevel" or "ErrorCount": "instanceof 'javax.management.AttributeChangeNotification' and AttributeName in ('SecurityLevel', 'ErrorCount')". * An AttributeChangeNotification where the attribute type is "int": "instanceof 'javax.management.AttributeChangeNotification' and AttributeType = 'int'". * An AttributeChangeNotification where the attribute name is "SecurityLevel" and the new value of the attribute is greater than 3: "instanceof 'javax.management.AttributeChangeNotification' and AttributeName = 'SecurityLevel' and NewValue > 3". * An MBeanServerNotification where the ObjectName is "a:b=c" or "x:y=z": "instanceof 'javax.management.relation.MBeanServerNotification' and ObjectName.canonicalName in ('a:b=c', 'x:y=z')". * An MBeanServerNotification where the ObjectName matches "mydomain:*": "instanceof 'javax.management.relation.MBeanServerNotification' and ObjectName.canonicalName like 'mydomain:%'". * A Notification where the type string is "my.type.one" or "my.type.two": "Type in ('my.type.one', 'my.type.two')".
28-09-2007