ResourceChangeListener v/s Sling Event

With introduction of ResourceChangeListener, this blog is an effort to help developers choose between ResourceChangeListener and Sling Event for an implementation.

ResourceChangeListener:

pros:

• 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

cons:

• Can only be used to handle resource events.

Sling Event:

pros:

• Can be used for handling non-resource events. Example:
  • Replication
  • Workflow Events
  • Sling Jobs
• When used with Sling jobs, sling event would guarantee Job processing.

cons:

• 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