Hi Alex, yet the system is based on JCR 2.x but it might migrated to Oak in time.
But anyways I wonder if this is really a good idea for this specific use case. If I get the idea right you'd add properties in a specific namespace to the resources to be added and process them on commit and drop them from the persisted conten - right? a) I'd bind to a very generic mechanism that would be added to each and every commit and needs to check for the properties on every commit although I know when to fire an event upfront (only condition - commit was successful) b) AFAIR a later commithook can still fail and stop the commit from happening c) I'd abuse a persistence mechanism (although not really commited in the end) as transport for metainformation I create on a higher level and need to process after the commit on higher level d) Te mechanism implies that I have direct connection between event and a specific node that I can utilize to transportmetadata, but an event is often connected to a bunch of changes (ok I just could abuse one of those but this feels hacky) e) I'm currently not sure if this would work for deletes as well, so if I add the metadata to a deleted node I'd have this changed node in the commit hook at all. All in all using commit hooks seem to require a lot of deep knowledge about Oak while the requirements are solely definable on the sling layer. Looking at those from an API view I "just" need a way to conditionally fire events/create jobs while the condition is a successful commit. Best regards Dominik Am 24.06.2014 23:37 schrieb "Alexander Klimetschek" <aklim...@adobe.com>: > 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 > >
