[wildfly-dev] Proposal to add notifications to WildFly management model and API

[Jason Greene]

On Jul 10, 2014, at 4:52 AM, Jeff Mesnil <jmesnil at redhat.com> wrote:

> 
> On 8 Jul 2014, at 23:07, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
>> On 7/7/14, 9:46 AM, Jeff Mesnil wrote:

-snip-

>>> The main reason for the wildcard is for the resource-added/resource-removed notifications. I find more intuitive to have the notifications at the same resource-level than their corresponding add/remove operations.
>> 
>> Agreed. I don't think this should be an issue. We shouldn't use the 
>> Resource tree anyway as the data structure for retaining the registered 
>> handlers; a separate structure is needed. The wildcards are fine as long 
>> as there's a relevant ManagementResourceRegistration.
> 
> In my POC, I am using a single Map to retain the handler and is separate from the resource tree.
> The Map keys are the path address from the registerNotificationHandler() method (that can be wildcard addresses).
> When a notification is emitted, I iterate on its entries to find the handlers that match the actual address of resource emitting the notification.
> I.e. the data structure grows with the number of handlers, not with the resources that emits notifications.

Is this map broken up into path segments to mitigate the o(n) cost? 

e.g.determining if /x=blah/y=foo/z=bar matches x=blah/y=foo/* = 2 O(1) map lookups

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat