With introduction of ResourceChangeListener, this blog is an effort to help developers choose between ResourceChangeListener and Sling Event for an implementation.
- Can be configured to listen to only specific paths. Multiple watch paths can also be configured to provide it a more granular approach.
- For a bulk operation concerning N resources, listener will be executed ONLY once. Thus, total number of persistence operations = 1 (via handler) + 1 (Bulk operation) = 2
- Can only be used to handle resource events.
- Can be used for handling non-resource events. Example:
- When used with Sling jobs, sling event would guarantee Job processing.
- Cannot restrict events to a certain path. Sling Event listens to all nodes starting from the root node of a repository (/)
- For a bulk operation concerning N resources, handler will be called N times. Thus, total number of persistence operations = N (via handler) + 1 (Bulk operation) = N + 1
2 thoughts on “ResourceChangeListener v/s Sling Event”
The new observation listener has one really big disadvantage. It cannot isten on concrete resource type, which is ridicolous. There is only information about path which is useless in real world