On Jul 10, 2014, at 4:52 AM, Jeff Mesnil <jmesnil(a)redhat.com> wrote:
On 8 Jul 2014, at 23:07, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
> On 7/7/14, 9:46 AM, Jeff Mesnil wrote:
>> 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
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
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