> Hi,
> Trying to understand implications of switching from OSGi EventHandler to
> ResourceChangeListener I'd like to find out how the hook into Oak is
> achieved. IIUC then currently all (!) ResourceChangeListeners are combined
> into 1 (Basic)ObservationReporter, which gets invoked by a ('singleton')
> OakResourceListener at [0] so that it can forward the changes to its
> listeners in [1].
> As a result after replacing the Sling event bridge with this new mechanism,
> there will still be exactly 1 OakResourceListener which facades all
> ResourceChangeListeners. And that 1 will imv become the new bottleneck.
> I fail to see how this will improve the filtering that we're trying to
> achieve in Oak - or is there a 1:1 mapping with the above mechanism still
> planned?
The 1:1 mapping (or even an optimization as there might be some overlap
between several listeners) was and is the goal of this approach.
If that isn't implemented in this way atm, I think this is a big
oversight and needs to be fixed asap.



Carsten Ziegeler
Adobe Research Switzerland

Reply via email to