[
https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15529055#comment-15529055
]
Stefan Egli commented on SLING-6056:
------------------------------------
bq. So I assume you mean we should avoid this additional filtering.
Sort of yes. But not because the additional filtering is expensive, it is only
expensive if no-one is interested (as Oak would not have to calculate/queue/etc
the event)
bq. For this to work it would mean that the ObserverConfigurations are a direct
1:1 representation of the registered listeners, I'm not sure if this is the
case, it might be compacted. But we can solve that.
That I think is only a side aspect. To have 1 RCL (resourcechangelistener) map
to 1 JRL (jcr/oak-resourcelistener) would perhaps be ideal, but imv the main
goal is to map those RCL with the same path to 1 JRL (the goal must be to
receive only events that anyone actually wants to receive). So for me it's fine
how that ObserverConfiguration 'compaction' is currently done (it's probably
even faster this way).
bq. So what about we add the report method on the ObserverConfiguration and
deprecate it in ObservationReporter?
Ok, and BasicObservationReporter.reportChange would remain as is, but no longer
be called, right? Then JRL would directly call the new
ObserverConfiguration.reportChanges. Yes that would work too. (IMO it would
'dirty' the API slightly though: ObserverConfiguration currently is just what
the name says, a configuration. With this change it would become also a
reporter - for which the ObservationReporter was originally targeted..)
> achieve 1:1 mapping between observation and resource change listener
> --------------------------------------------------------------------
>
> Key: SLING-6056
> URL: https://issues.apache.org/jira/browse/SLING-6056
> Project: Sling
> Issue Type: Task
> Components: ResourceResolver
> Affects Versions: JCR Resource 2.8.0, API 2.14.2, Resource Resolver 1.4.18
> Reporter: Stefan Egli
> Assignee: Stefan Egli
> Priority: Critical
> Fix For: JCR Resource 2.8.2, API 2.15.0, Resource Resolver 1.4.20
>
> Attachments: SLING-6056.patch
>
>
> At the moment it seems there is a 1:n mapping between 1 OakResourceListener
> (and 1 BasicObservationReporter) and n ResourceChangeListeners. The idea
> however is to get rid of such a bottleneck and have a 1:1 mapping (that might
> or might not be in the BasicObservationReporter, that I don't know). We
> should implement such a 1:1 mapping.
> See [thread on dev list|http://sling.markmail.org/thread/uwhda777psgklwo6]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
