JBCACHE-56 includes work to emit cache events as mbean notifications. The impending implementation uses the new CacheMgmtInterceptor mbean to receive events from the associated TreeCache instance and rebroadcast them as mbean notifications. This only occurs when a client specifically registers to receive notifications from the mbean so the interceptor won't automatically register for events with the cache.

Several design issues are associated with the notifications.

1) It's possible to define a custom notification class rather than use the generic Notification class. The proposed implementation uses the generic class as it satisfies current requirements and is more amenable to use by third party mbean tools.

2) The Notification class exposes a UserData Object attribute that can be used to incorporate user information into the notification. For TreeCache events, user data are the parameters that are included with the events. For example, user data for the NodeActivated event is the Fqn of the activated node.

One issue is whether the notification should incorporate the received data as is into the notification or should modify it first (e.g., fqn.toString() ). While passing the data as is works fine for local mbean clients, problems may occur when the client is remote. For example, if you access TreeCache interceptor mbeans remotely using Sun's jconsole utility and register for notifications, the mbean display within the utility will fail if a notification contains non-serializable user data (e.g., Fqn, View, TreeCache). In order to eliminate this problem, the implementation will pass String data for TreeCache artifacts. The following are examples.

CacheStarted and CacheStopped notifications will provide the cache's service name rather than a direct reference to the cache. This should lbe sufficient to allow the caller to obtain a direct reference to the cache through the mbean server if necessary.

ViewChanged notification will provide view.toString() rather than a direct reference to the view itself.

All node events(e.g., NodeActivated, NodeCreated, Node Visited) will provide fqn.toString() rather than a direct reference to the fqn.

3) The Notification.setUserData() method takes an Object as parameter. Many of the cache events have a single parameter (e.g., Fqn) so these can be added to the notification easily (e.g., setUserData(fqn.toString) ). However the extended cache events such as NodeEvict have multiple parameters: Fqn, boolean, boolean). So notifications representing these events require a different representation such as as Object[] or possibly a map or list. The initial implementation will use Object[] for these notifications unless there are concerns about this representation.

One design issue here is whether single parameter notifications such as NodeActivated should also use an Object[] parameter for consistency at the expense of some efficiency and indirection. When notifications are displayed in jconsole, simple user data types such as String are shown in a column on the notifications display. User data provided as Object[] is listed as an Object[] reference and the user must click on the displayed Object[] entry to expand it and display the individual array values.

Any thoughts on how user data should be handled?