You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Stefan Egli (JIRA)" <ji...@apache.org> on 2016/10/24 16:01:01 UTC
[jira] [Updated] (JCR-4045) Improved support for node removals
[ https://issues.apache.org/jira/browse/JCR-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Egli updated JCR-4045:
-----------------------------
Attachment: JCR-4045.patch
Attaching [^JCR-4045.patch] which suggests the introduction of a new properties to the JackrabbitEventFilter:
* {{reportPotentialAncestorRemovals}}
This would - given we agree upon it - result in any {{NODE_REMOVED}} event to be inspected if it is potentially an ancestor of the filter and if yes, reports the event.
Let's discuss the pros and cons of doing this either with a separate listener in Sling, or with this new suggested property, or JCR-4037 (but that latter one would probably be more costly)
> Improved support for node removals
> ----------------------------------
>
> Key: JCR-4045
> URL: https://issues.apache.org/jira/browse/JCR-4045
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: core
> Reporter: Carsten Ziegeler
> Attachments: JCR-4045.patch
>
>
> If a listener is subscribed for removal events of a subtree, e.g. /a/b/c/d it gets removal events for everything in that three.
> However, if /a/b is removed, the listener is not informed at all, which makes the listener state inconsistent/invalid
> I suggest to add a new flag to the JackrabbitEventFilter and if that is enabled the listener will get remove events of all the parent nodes - if the listener is interested in remove events of any kind.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)