Is this for a resource provider implementation that is not backed by JCR? Because if we are talking about JCR resources I would advocate solutions on the JCR repo layer, Oak has some options with commit hooks.
Just my 2 cents, Alex On 24.06.2014, at 04:22, Dominik Süß <dominik.su...@gmail.com> wrote: > Hi everyone, > > I'm currently doing some research to implement a feature where I need to > integrate 3rd party systems that act as client and need to perform some > local changes that I can trigger from the sling instance. > > The issue I do have is that there seems to be no proper way to transport > the information that I do have when preparing the changes in the local repo > via resourceresolver to some code that is executed after the transient > changes have been commited. > > The only mechansim available is listening for the Resource events but I > lose a lot of information. One example is removal of a node where I cannot > access the values of the removed resource anymore. The remove event for a > resource testa with attribute testb with value testc provides me the > following information: > > event.topicsorg/apache/sling/api/resource/Resource/REMOVEDpath/content/testa > useridadminresourceRemovedAttributes[testb, jcr:primaryType] > Beside losing information it just feels wrong that I have to bind to the > persisted information but cannot bind specific logic to a commit. > > When thinking about this a bit more I wonder why Event and JobHandling > shouldn't have an option to only be triggered on commit. If I'd have a way > to prepare events/jobs that only get fired if the commit could successfully > be performed I'd have a way to transport all the metadata I need to trigger > the 3rd system via EventListener/JobConsumer. > > My concrete usecase is about triggering securitymechanisms of multiple > third party system based on changes persisted in a sling instance (synching > accesscontrol for a highly integrated system that is not only composed of > sling instances). > > I had a related requirement some years ago where a search integration did > require some metadata about deleted resources to be able to perform a > proper cleanup and we had to turn on jcr versioning to be able to get this > data from the corresponding frozen nodes since the original nodes are > already gone when the event is fired. > > Any alternative idea or opinions regarding such an extension? > > Best regards > Dominik