A few times the thought has occurred to me that a Node-level equivalent to the TreeCacheListener interface could be useful. In some use cases, registrants are only interested in events on certain nodes. If they implement TreeCacheListener they have to do an Fqn comparison and discard a lot of events. A node-level equivalent would allow them to register interest only in the nodes they want.
The downside is adding some complexity to the Node implementations, plus the addition of one field per node to hold the registered listeners. This field could be lazy-initialized, so the memory cost on most nodes is 1 pointer.
Potential places this could be used:
1) HttpSession replication. We currently need to track modifications in the top node associated with each session, but ignore any child nodes associated with session attributes.
2) EJB3 SFSB replication. A similar situation will likely apply.
3) TreeCacheAop collection classes. Perhaps useful for http://jira.jboss.com/jira/browse/JBCACHE-354.
Also, toward the bottom of the second page of posts on http://www.jboss.com/index.html?module=bb&op=viewtopic&t=75874 there's a half-baked idea where this might be useful.
Another requirement that sometimes arises is to supply the originator of the TreeCacheListener event. For example, I may not be interested to receive the event that is coming from my own; that is, to exclude myself. E.g., when I do a put, I may not be interested to receive an event.