Re: CommitHooks as OSGi Components.

[Chetan Mehrotra]

On Thu, Sep 15, 2016 at 1:15 AM, Rob Ryan  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.

[Rob Ryan]

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"  wrote:

On Mon, Sep 12, 2016 at 3:12 PM, Ian Boston  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.

[Ian Boston]

On 12 September 2016 at 10:45, Chetan Mehrotra 
wrote:

> On Mon, Sep 12, 2016 at 3:12 PM, Ian Boston  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.

[Chetan Mehrotra]

On Mon, Sep 12, 2016 at 3:12 PM, Ian Boston  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.

[Ian Boston]

Hi,


On 12 September 2016 at 09:43, Chetan Mehrotra 
wrote:

> On Mon, Sep 12, 2016 at 2:08 PM, Ian Boston  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.

[Chetan Mehrotra]

On Mon, Sep 12, 2016 at 2:08 PM, Ian Boston  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.

[Ian Boston]

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

[Michael Dürig]

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.

[Tomek Rekawek]

Hi Ian,

> On 09 Sep 2016, at 18: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.

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
reka...@adobe.com



smime.p7s
Description: S/MIME cryptographic signature

CommitHooks as OSGi Components.

[Ian Boston]

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