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