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.)