(sling-org-apache-sling-api) 01/01: SLING-12249 Clarify that both REMOVED and ADDED events may be received for ancestors of registered path.

[kw...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

kwin pushed a commit to branch feature/resource-changes-outside-path-for-add
in repository https://gitbox.apache.org/repos/asf/sling-org-apache-sling-api.git

commit 0dfd14abe0fdea8415b5f9999ff9a33ffec030da
Author: Konrad Windszus <kw...@apache.org>
AuthorDate: Wed Feb 7 20:08:39 2024 +0100

    SLING-12249 Clarify that both REMOVED and ADDED events may be received
    for ancestors of registered path.
---
 .../api/resource/observation/ResourceChangeListener.java   | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/main/java/org/apache/sling/api/resource/observation/ResourceChangeListener.java b/src/main/java/org/apache/sling/api/resource/observation/ResourceChangeListener.java
index e2caf50..dcdb954 100644
--- a/src/main/java/org/apache/sling/api/resource/observation/ResourceChangeListener.java
+++ b/src/main/java/org/apache/sling/api/resource/observation/ResourceChangeListener.java
@@ -70,14 +70,14 @@ public interface ResourceChangeListener {
      * </ul>
      *
      * <p>
-     * In general, it can't be guaranteed that the underlying implementation of the resources will send a remove
-     * event for each removed resource. For example if the root of a tree, like {@code /foo} is removed, the underlying
+     * In general, it can't be guaranteed that the underlying implementation of the resources will send a remove/add
+     * event for each removed/added resource. For example if the root of a tree, like {@code /foo} is removed, the underlying
      * implementation might only send a single remove event for {@code /foo} but not for any child resources.
-     * Therefore if a listener is interested in resource remove events, it might get remove events for resources
-     * that not directly match the specified pattern/filters. For example if a listener is registered for {@code /foo/bar}
-     * and {@code /foo} is removed, the listener will get a remove event for {@code /foo}. The same is true if any pattern is used
-     * and any parent of a matching resource is removed. If a listener is interested in
-     * remove events, it will get a remove of any parent resource from the specified paths or patterns. The listener
+     * Similarly for renaming a subtree from {@code /foo} to {@code /bar} the add event may only be sent for {@code /bar}
+     * but not for any child resources.
+     * Therefore a listener might get remove/add events for resources that not directly match the specified pattern/filters. 
+     * For example if a listener is registered for {@code /foo/bar} and {@code /foo} is removed, the listener will get a remove event for {@code /foo}.
+     * The same is true if any pattern is used and any parent of a matching resource is removed/added. The listener
      * must handle these events accordingly.
      *
      * <p>If one of the paths is a sub resource of another specified path, the sub path is ignored.</p>