[
https://issues.apache.org/jira/browse/OAK-5021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15628253#comment-15628253
]
Stefan Egli commented on OAK-5021:
----------------------------------
That's needed if you want to match the {{nt:file}} node itself. The algorithm
is to find the first matching node type and then take the subpath to the actual
change and match that against what is registered. For the {{nt:file}} node that
subpath would be an empty string.
You can of course also register deeper subpaths, such as {{"jcr:content/**"}}
too.
> Improve observation of files
> ----------------------------
>
> Key: OAK-5021
> URL: https://issues.apache.org/jira/browse/OAK-5021
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
> Affects Versions: 1.5.12
> Reporter: Stefan Egli
> Assignee: Stefan Egli
> Fix For: 1.5.13
>
>
> (Originally reported as JCR-4046, but moved to Oak as a result of introducing
> the OakEventFilter in OAK-5013. From the original description: )
> A file in JCR is represented by at least two nodes, the nt:file node and a
> child node named jcr:content holding the contents of the file (and metadata).
> This has the consequence that if the contents of a file changes, a change
> event of the jcr:content node is reported - but not of the nt:file node.
> This makes creating listeners listening for changes in files complicated, as
> you can't use the file name to filter - especially with glob patterns (see
> JCR-4044 - now OAK-5019) this becomes troublesome.
> In addition, whenever you get a change for a jcr:content node, you have to
> check if the parent is a nt:file node and decide based on the result.
> It would be great to have a flag on the JackrabbitEventFilter to enable
> smarter reporting just for nt:files: if a property on jcr:content is changed,
> a change to the nt:file node is reported.
> See also SLING-6163 and OAK-4940
> /cc [~cziegeler]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
