[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15506623#comment-15506623 ] Stefan Egli commented on SLING-6056: perhaps this should go on a separate ticket, but related to ResourceChangeListener I think we should look into adding more filtering capabilities to it. Ideally it would be possible to support everything what Oak supports. > 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: Resource Resolver 1.4.18 >Reporter: Stefan Egli >Priority: Critical > Fix For: Resource Resolver 1.4.20 > > > 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)
[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15508869#comment-15508869 ] Carsten Ziegeler commented on SLING-6056: - I think this is a separate issue and we have to be careful here as Oak is only one resource provider. I'll start a discussion on the mailing list > 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: Resource Resolver 1.4.18 >Reporter: Stefan Egli >Priority: Critical > Fix For: Resource Resolver 1.4.20 > > > 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)
[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15522765#comment-15522765 ] Stefan Egli commented on SLING-6056: As [~mreutegg] [commented|https://issues.apache.org/jira/browse/OAK-4581?focusedCommentId=15522741&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15522741] on OAK-4581 we should review the usage of OakResourceListener and consider switching back to JcrResourceListener. > 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: Resource Resolver 1.4.18 >Reporter: Stefan Egli >Assignee: Stefan Egli >Priority: Critical > Fix For: Resource Resolver 1.4.20 > > > 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)
[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15523423#comment-15523423 ] Stefan Egli commented on SLING-6056: [~cziegeler], [~radu.cotescu], before I dig too deep into this (and pending discussions on OAK-4581 perhaps), did you have an idea how to achieve this 1:1 mapping best? Currently there is a 1:1 mapping also between ProviderContext and ObservationReporter and JcrResourceProvider creates 1 Oak/Jcr-ResourceListener. Somewhere this 1:1 thing needs to be broken up, not sure if that can/should be done in the ProviderContext? > 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: Resource Resolver 1.4.18 >Reporter: Stefan Egli >Assignee: Stefan Egli >Priority: Critical > Fix For: Resource Resolver 1.4.20 > > > 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)
[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15525170#comment-15525170 ] Carsten Ziegeler commented on SLING-6056: - [~egli] The split up can either be done in JcrResourceProvider#registerListener or we create a new class dealing with this and registerListener delegates to it. I think this depends on how complex the code gets. I'm not 100% sure if compaction of the listeners is already done in the resourceresolver implementation, e.g. if a listener registers at /foo/bar and another at /foo - we could consider only registering a single observer at /foo. Same, if a listener registers at /, we only need one observation listener. > 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: Resource Resolver 1.4.18 >Reporter: Stefan Egli >Assignee: Stefan Egli >Priority: Critical > Fix For: Resource Resolver 1.4.20 > > > 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)
[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[
https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15525450#comment-15525450
]
Stefan Egli commented on SLING-6056:
[~cziegeler], I can't see how it can be done isolated in sling.jcr.resource - I
think it requires an api change in sling.api ({{List
getObservationReporter()}}), which propagates to various other bundles as it
means a version increase. But it is necessary since ObservationReporter is the
one containing {{reportChanges}} - and the goal is to have the
Jcr/OakResourceListener directly call the 'correct' reportChanges - ie a 1:1
mapping between Jcr/OakResourceListener and ObservationReporter. And that can
only be achieved (AFAICS) by changing the api..
> 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: Resource Resolver 1.4.18
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Critical
> Fix For: Resource Resolver 1.4.20
>
>
> 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)
[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15528529#comment-15528529 ] Carsten Ziegeler commented on SLING-6056: - [~egli] We can't make a major version change of that package, we introduced the new abstract class exactly for that reason. If we would increase the major package version, we break all implementations. I'm not 100% sure the API change is really needed, give me please some days to think about it. > 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)
[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[ 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)
[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[ 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)
[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15529285#comment-15529285 ] Carsten Ziegeler commented on SLING-6056: - Ok, so we can add a new reportChanges method to ObservationReporter instead which also takes the configuration as an argument. Sorry, but I'm still not sure what you're trying to achieve. Let's assume we have three listeners, one for /libs and two for /content without any further restrictions. The ObservationReporter will report two configurations, one for /libs and one for /content. The jcr resource module will register two observers based on that and today call ObservationReporter.reportChanges for any change under /libs or /content. The resource resolver implementation does then the dispatching to the correct set of the three listeners. How do you want to change this picture? > 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)
[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15529346#comment-15529346 ] Stefan Egli commented on SLING-6056: bq. The jcr resource module will register two observers I don't see that happening. I see it only registers 1 jcr listener, and that's the problem. There is a 1:1 relation between resource-provider - provider-context. And a provider-context has only 1 ObservationReporter - which combines the 2 configs, and the 3 listeners. I'd like to break up the 1:1 relation between resource-provider and listener. > 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)
[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15529391#comment-15529391 ] Carsten Ziegeler commented on SLING-6056: - Alright but having the registration of the two listeners is actually what this issue is about and what we started with here. So simply change my sentence from above to "The jcr resource module will in the future register two observers" Sorry, that I'm not seeing the problem atm, as I don't see how provider-context plays a role here, it's true its a single reporter the provider gets, but it has two configurations and that's all that is important for the provider. It can register 1, 2 or twenty-five listeners. That's up to the provider implementation. > 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)
[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[
https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15529403#comment-15529403
]
Stefan Egli commented on SLING-6056:
if we have the new method you suggested in ObservationReporter: {{void
reportChanges(@Nonnull ObserverConfiguration config, @Nonnull
Iterable changes, boolean distribute)}} then this can be
achieved yes. Not without, that's all I'm suggesting.
> 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)
[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15529517#comment-15529517 ] Carsten Ziegeler commented on SLING-6056: - :) I understand that you think that method is required I don't understand why. Sorry, maybe my brain is really thinking in the wrong direction. So I'll wait for your patch and see what it changes. > 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)
[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15571302#comment-15571302 ] Carsten Ziegeler commented on SLING-6056: - I had an offline discussion with [~egli] and now I understand why the change of the api is required: There might be listeners with overlapping configurations, if reportChanges is called without the used ObserverConfiguration then the implementation of the reporter is called several times for overlapping events and the reporter will deliver them to the listeners, which means that a listener might get the event twice (or more often based on the overlapping) > 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.5.0 > > 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)
[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15571325#comment-15571325 ] Carsten Ziegeler commented on SLING-6056: - I've added a new method to the api as discussed above - the old method is still in place as it can be used if the implementation is just using a single mechanism like registering a single JCR listener > 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.5.0 > > 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)
[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584751#comment-15584751 ] Carsten Ziegeler commented on SLING-6056: - Updated the resource resolver implementation to correctly split the observer configurations in rev 1765397 > 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: API, JCR, ResourceResolver >Affects Versions: JCR Resource 2.8.0, API 2.14.2, Resource Resolver 1.4.18 >Reporter: Stefan Egli >Assignee: Carsten Ziegeler >Priority: Critical > Fix For: JCR Resource 2.9.0, API 2.15.0, Resource Resolver 1.5.0 > > 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)
[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener
[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15585582#comment-15585582 ] Carsten Ziegeler commented on SLING-6056: - Finished the implementation in jcr resource, except for glob patterns: Unfortunately, it seems that the jackrabbit observation api does not support glob filtering which we need > 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: API, JCR, ResourceResolver >Affects Versions: JCR Resource 2.8.0, API 2.14.2, Resource Resolver 1.4.18 >Reporter: Stefan Egli >Assignee: Carsten Ziegeler >Priority: Critical > Fix For: JCR Resource 2.9.0, API 2.15.0, Resource Resolver 1.5.0 > > 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)
