You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Ian Boston <ie...@tfd.co.uk> on 2016/09/09 16:04:31 UTC
CommitHooks as OSGi Components.
Hi,
Is it possible write a CommitHook as an OSGI Component/Service and for Oak
to pick it up ?
The Component starts and gets registered as a service, but Oak doesn't
appear to pick it up.
If its not possible to add a CommitHook in this way, what is the best way
of doing it from outside the oak-core bundle ?
Best Regards
Ian
Re: CommitHooks as OSGi Components.
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Thu, Sep 15, 2016 at 1:15 AM, Rob Ryan <rr...@adobe.com> wrote:
> Last I heard even local events can be subject to loss of the user id if so many events are being processed that ‘compaction’ is used to mitigate the load. Is this still the case?
>
> Please don’t point people toward the availability of the user id from events (without full disclaimers) if it will not *always* be available.
Thats the case for JCR level ObservationListener which makes use of
BackgroundObserver. In Ian case he is directly building on top of
Observer and hence can control the compaction aspect.
Chetan Mehrotra
Re: CommitHooks as OSGi Components.
Posted by Rob Ryan <rr...@adobe.com>.
Last I heard even local events can be subject to loss of the user id if so many events are being processed that ‘compaction’ is used to mitigate the load. Is this still the case?
Please don’t point people toward the availability of the user id from events (without full disclaimers) if it will not *always* be available.
-Rob
On 9/12/16, 2:45 AM, "Chetan Mehrotra" <ch...@gmail.com> wrote:
On Mon, Sep 12, 2016 at 3:12 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> but if the information that connect a sessionID/userID to the
> paths that are modified is available through some other route, I might be
> able to use something else.
A regular Observer should work for that case. Just register an
instance with service registry and it would be picked up and for non
external event CommitInfo would be present
Chetan Mehrotra
Re: CommitHooks as OSGi Components.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 12 September 2016 at 10:45, Chetan Mehrotra <ch...@gmail.com>
wrote:
> On Mon, Sep 12, 2016 at 3:12 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> > but if the information that connect a sessionID/userID to the
> > paths that are modified is available through some other route, I might be
> > able to use something else.
>
> A regular Observer should work for that case. Just register an
> instance with service registry and it would be picked up and for non
> external event CommitInfo would be present
>
Perfect,
thanks.
I should have spotted that.
Best Regards
Ian
>
> Chetan Mehrotra
>
Re: CommitHooks as OSGi Components.
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Mon, Sep 12, 2016 at 3:12 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> but if the information that connect a sessionID/userID to the
> paths that are modified is available through some other route, I might be
> able to use something else.
A regular Observer should work for that case. Just register an
instance with service registry and it would be picked up and for non
external event CommitInfo would be present
Chetan Mehrotra
Re: CommitHooks as OSGi Components.
Posted by Ian Boston <ie...@tfd.co.uk>.
Hi,
On 12 September 2016 at 09:43, Chetan Mehrotra <ch...@gmail.com>
wrote:
> On Mon, Sep 12, 2016 at 2:08 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> > Unfortunately the IndexProvider route doesn't appear give me the
> > information I am after (CommitInfo).
>
> Any details around intended usage? CommitInfo is now exposed via
> OAK-4642 to IndexEditorProvider
>
I would like it to work with older versions of oak pre 1.5.8 or 1.6
The use case is to capture commit info and pump it into a dataset for
visualisation along with other activity information. CommitInfo seems to be
what I need, but if the information that connect a sessionID/userID to the
paths that are modified is available through some other route, I might be
able to use something else.
Best Regards
Ian
>
> Chetan Mehrotra
>
Re: CommitHooks as OSGi Components.
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Mon, Sep 12, 2016 at 2:08 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> Unfortunately the IndexProvider route doesn't appear give me the
> information I am after (CommitInfo).
Any details around intended usage? CommitInfo is now exposed via
OAK-4642 to IndexEditorProvider
Chetan Mehrotra
Re: CommitHooks as OSGi Components.
Posted by Ian Boston <ie...@tfd.co.uk>.
Hi,
Thank you for the pointers.
Unfortunately the IndexProvider route doesn't appear give me the
information I am after (CommitInfo).
Since I need this to work in an independent bundle patching the repository
manager isn't an option.
I am currently looking to see if there are any other services exposed that
might give me a route in.
Best Regards
Ian
On 12 September 2016 at 08:38, Michael Dürig <md...@apache.org> wrote:
>
> Hi,
>
> No it isn't. Commit hooks haven't been designed for this type of
> dynamicity and generality. Exposing them at this layer has been considered
> way to dangerous and a breach of modularity.
>
> What has been done in the past for use cases requiring commit hook
> functionality on one hand and some part of dynamicity on the other, was to
> to specialise the use case. Index editors are one example here.
>
> Michael
>
>
> On 9.9.16 6:04 , Ian Boston wrote:
>
>> Hi,
>> Is it possible write a CommitHook as an OSGI Component/Service and for Oak
>> to pick it up ?
>> The Component starts and gets registered as a service, but Oak doesn't
>> appear to pick it up.
>> If its not possible to add a CommitHook in this way, what is the best way
>> of doing it from outside the oak-core bundle ?
>> Best Regards
>> Ian
>>
>>
Re: CommitHooks as OSGi Components.
Posted by Michael Dürig <md...@apache.org>.
Hi,
No it isn't. Commit hooks haven't been designed for this type of
dynamicity and generality. Exposing them at this layer has been
considered way to dangerous and a breach of modularity.
What has been done in the past for use cases requiring commit hook
functionality on one hand and some part of dynamicity on the other, was
to to specialise the use case. Index editors are one example here.
Michael
On 9.9.16 6:04 , Ian Boston wrote:
> Hi,
> Is it possible write a CommitHook as an OSGI Component/Service and for Oak
> to pick it up ?
> The Component starts and gets registered as a service, but Oak doesn't
> appear to pick it up.
> If its not possible to add a CommitHook in this way, what is the best way
> of doing it from outside the oak-core bundle ?
> Best Regards
> Ian
>
Re: CommitHooks as OSGi Components.
Posted by Tomek Rekawek <re...@adobe.com>.
Hi Ian,
> On 09 Sep 2016, at 18:04, Ian Boston <ie...@tfd.co.uk> wrote:
>
> Hi,
> Is it possible write a CommitHook as an OSGI Component/Service and for Oak
> to pick it up ?
> The Component starts and gets registered as a service, but Oak doesn't
> appear to pick it up.
The standard RepositoryManager[1] (responsible for setting-up the repo) allows to register EditorProvider, IndexEditorProvider and IndexProvider via OSGi. If you use a Sling-based setup, then the repository is created by OakSlingRepositoryManager[2] and it’s only possible to register index-related services.
> If its not possible to add a CommitHook in this way, what is the best way
> of doing it from outside the oak-core bundle ?
I’m afraid they can’t be added dynamically, so you need to modify the *RepositoryManager class and add an appropriate .with() invocation.
Regards,
Tomek
[1] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/osgi/RepositoryManager.java
[2] https://github.com/apache/sling/blob/trunk/bundles/jcr/oak-server/src/main/java/org/apache/sling/jcr/oak/server/internal/OakSlingRepositoryManager.java
--
Tomek Rękawek | Adobe Research | www.adobe.com
rekawek@adobe.com