You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Davide Giannella (JIRA)" <ji...@apache.org> on 2016/11/14 11:36:03 UTC

[jira] [Closed] (OAK-5011) Add event aggregation support to observation filtering

     [ https://issues.apache.org/jira/browse/OAK-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davide Giannella closed OAK-5011.
---------------------------------

Bulk close for 1.5.13

> Add event aggregation support to observation filtering
> ------------------------------------------------------
>
>                 Key: OAK-5011
>                 URL: https://issues.apache.org/jira/browse/OAK-5011
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core, jcr
>    Affects Versions: 1.5.12
>            Reporter: Stefan Egli
>            Assignee: Stefan Egli
>             Fix For: 1.6, 1.5.13
>
>         Attachments: OAK-5011.patch
>
>
> Currently the observation filtering 'subsystem' allows only the creation of events with the path and identifier set to the parent of where the change happened. To support features like JCR-4046 we need some sort of event 'aggregation'. The idea is that while the change happened somewhere in a subtree it would still be reported with the {{event.getIdentifier()}} set on some parent/aggregator node (the {{event.getPath()}} would still be the actual change).
> To support this, the suggestion is to add a {{EventAggregator}} to the {{FilterBuilder}} which would be invoked right before the actual event is being created, but after the filtering happened, so it would only affect how the event looks like, not whether or not the event is generated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)