[
https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15528972#comment-15528972
]
Carsten Ziegeler commented on SLING-6056:
-----------------------------------------
I start to understand the problem, now a ObservationReporter gets a list of
configurations and the Oak observer impl uses that to register the observer (or
jcr listeners). Whenever any of those report a change,
ObservationReporter.reportChanges is called and then - and this is the problem
- the resource resolver implementation needs to do the filtering based on the
reported changes.
So I assume you mean we should avoid this additional filtering. 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.
So what about we add the report method on the ObserverConfiguration and
deprecate it in ObservationReporter? ObserverConfiguration is provider type so
we can easily add methods
> 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)
