I just realized that there might be the need to dynamicaly add paths to the Listener. I have at least 2 cases in mind where the paths cannot be determined at deployment time which is the workflow launcher in CQ (where a user does define a ruleset at runtime) which might be changed to individual listeners being registerd, and the other case is when you have the temporary need to watch for changes of specific nodes (e.g. when a cache needs to be invalidated based on contentchanges - so the listener just needs to react on changes of resources relevant to the invalidation logic).
During writing that I just came up with the question, what about such global listeners as the replication agent of CQ which potentially nees to act on all paths. The restrictions I have in mind is the path /content and that it would be sufficient to have one aggregated event for a page (substructure containing all resource to be used for rendering one request) which needs to be touched on subcontentchanges anyway (lastmodified). -- Dominik On Tue, Oct 22, 2013 at 5:48 PM, Carsten Ziegeler <[email protected]>wrote: > From the use cases I know, the listeners register for a specific path and > are rarely interested in anything else. Some do check the resource type as > well. > For example the script engines check for changes under /libs and /apps (the > resource paths actually) for changes to scripts, the job engine checks for > new jobs somewhere under /var/jobs and checks the resource type as well > etc. > Many use cases check for changes (resource added, resource removed, > resource changed) and then re-read the sub tree based on the changes. > > The mapping handler in the resource resolver is probably the most > interesting one as it changes for nodes with some well defined properties, > basically scanning the whole repository. And I think the i18n stuff does > something similar (but this one might still be using jcr observation). > > This list is by no means exhaustive for Sling, but we see that we already > have two listeners scanning the whole repository and require access to > properties. > > Carsten > > > 2013/10/22 Dominik Süß <[email protected]> > > > In a discussion [0] within the Oak mailinglist it became clear that the > way > > Sling listens zu JCR Repository Changes and transforms all of them to > > events will not scale well in some big scale scenarios that oak is aiming > > to enable. Therefore the question was posted if it would be feasible > and/or > > even necessary to refactor the API and deprecate (or at least discurrage) > > registration in a global scope as currently done. > > > > Since I do not want to copy & paste parts of the discussion I do hope > that > > the participants of the oak discussion add the remaining options with > some > > more detail about consequences than can be found in the linked > discussion. > > > > It would be great to also get some feedbacks of consumers of the existing > > API about the usage to identify how finegrained a potential > > registrationlogic with paths/properties might need to be. > > > > Best regards > > Dominik > > > > [0] http://markmail.org/message/n5vllhjoawypteck > > > > > > -- > Carsten Ziegeler > [email protected] >
