Triggering logic on commit of ResourceResolver

[Dominik Süß <do...@gmail.com>]

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

Re: Triggering logic on commit of ResourceResolver

[Alexander Klimetschek <ak...@adobe.com>]

On 25.06.2014, at 15:35, Dominik Süß <do...@gmail.com> wrote:

> this isn't true anymore, the session.save() in the POST Servlet is
> triggered through the resourceResolver.commit() [0] - and direct
> session.save() should not be performed anymore

Ok, I see, didn't know.

> The mechanism I propose is bound to resourceResolver but does not prevent
> JCR API access beside the fact that session.save() would not be a complete
> resourceresolver.commit (which would still have pending changes aka the
> events).

If you ask me, this is still an abstraction leak and probably very confusing to someone new.

Cheers,
Alex

Re: Triggering logic on commit of ResourceResolver

[Dominik Süß <do...@gmail.com>]

Hi Alex,

this isn't true anymore, the session.save() in the POST Servlet is
triggered through the resourceResolver.commit() [0] - and direct
session.save() should not be performed anymore - even if switching to jcr
api because you act on low level API (e.g. for versioning) you should
control commit behavior via the resourceResolver - that way you can ensure
that any changes performed in other resourceProviders will be commited as
well. I know that the majority of cases will be local JCR repositories but
just think of remote sources included via REST Interfaces or the (yet not
possible) case that two repos are mounted in one instance (e.g. to separate
/content from /apps and /libs).

The mechanism I propose is bound to resourceResolver but does not prevent
JCR API access beside the fact that session.save() would not be a complete
resourceresolver.commit (which would still have pending changes aka the
events).

Best regards

Dominik


[0]
https://github.com/apache/sling/blob/trunk/bundles/servlets/post/src/main/java/org/apache/sling/servlets/post/AbstractPostOperation.java#L129
Am 25.06.2014 21:50 schrieb "Alexander Klimetschek" <ak...@adobe.com>:

> On 25.06.2014, at 00:27, Dominik Süß <do...@gmail.com> wrote:
>
> > 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.
>
> But you exclude any change through the JCR API, for example the sling post
> servlet.
>
> Cheers,
> Alex
>
>

Re: Triggering logic on commit of ResourceResolver

[Alexander Klimetschek <ak...@adobe.com>]

On 25.06.2014, at 00:27, Dominik Süß <do...@gmail.com> wrote:

> 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.

But you exclude any change through the JCR API, for example the sling post servlet.

Cheers,
Alex

Re: Triggering logic on commit of ResourceResolver

[Dominik Süß <do...@gmail.com>]

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" <ak...@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üß <do...@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
>
>

Re: Triggering logic on commit of ResourceResolver

[Alexander Klimetschek <ak...@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üß <do...@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