Show the use of an OSGi Config Properties to control flush actions

[bhellema]

Customers might have complicated deployments where content may refer to other pieces of content, such as a Page might depend on a DAM asset. There's a way of controlling the dispatcher cache by leveraging the statfileslevel property to invalidate the cache when an ACTIVATE occurs however we may not want to invalidate the entire cache, or large portions of the cache when only a few resources need to be purged.

For example, if a website section /content/my-site/us/en/products leverages images from /content/dam/products, anytime an image asset in /content/dam/products is updated, we want to ensure any uses of it by web pages in /content/my-site/us/en/products are also updated. We could set a stat level of 1 that invalidates everything under /content when anything under /content changes, however this inefficient, since an update to /content/my-site/us/en/products would invalidate everything under the rest of the web site too, for example: /content/my-site/us/en/services and /content/my-site/us/en/about-us, etc.

This experiment would be to introduce an OSGi property to specify a targeted flush rule. By creating a new sling:OsgiConfig node for each flush rule set, this gives more control over the cache flush operations.

See https://adobe-consulting-services.github.io/acs-aem-commons/features/dispatcher-flush-rules/index.html for additional details.

[atopper]

This would be a useful experiment based on a customer I was researching in October.

[atopper]

If there are complex mappings, which would invalidate pages over and over, I wonder if batching options would be a good addition to this experiment.