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
On 25.06.2014, at 00:27, Dominik Süß dominik.su...@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
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
On 25.06.2014, at 15:35, Dominik Süß dominik.su...@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
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
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