You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Stefan Egli <st...@apache.org> on 2016/10/24 16:13:06 UTC
[REVIEW][API] Additions to JackrabbitEventFilter
Hi all,
There are quite a few feature suggestions/requests around wrt the
JackrabbitEventFilter to help downstream applications including Sling. It
would be great if we could review and decide on how we'd like to move
forward with this in the next days, ideally if possible resulting in a
Jackrabbit 2.13.5 release end of this week (as downstream timeline would be
fulfilled that way).
I would suggest to have the discussion wrt whether it makes sense at all,
whether we want it/do it now and if the API is feasible in each of the
following tickets:
* JCR-4044 : globbing support
* JCR-4037 : includeSubtreeOnDelete
* JCR-4048 : applyOnChild / child filtering
* JCR-4045 : reportPotentialAncestorRemovals
* JCR-4046 : reportJcrContentOnParent
Some might seem more straight-forward than others and yes it increases the
JackrabbitEventFilter (perhaps too much, not sure). But they should all have
some arguing/use cases in the description as to why it makes sense to have
them. The goal of all this is to improve observation performance in the end.
Thanks,
Cheers,
Stefan
--
https://issues.apache.org/jira/browse/JCR-4044
https://issues.apache.org/jira/browse/JCR-4037
https://issues.apache.org/jira/browse/JCR-4048
https://issues.apache.org/jira/browse/JCR-4045
https://issues.apache.org/jira/browse/JCR-4046
Re: [REVIEW][API] Additions to JackrabbitEventFilter
Posted by Stefan Egli <st...@apache.org>.
(+oak-dev as it meanwhile has move to oak features alone)
I've committed OAK-5013 which introduces the OakEventFilter extension and
a number of such extensions (OAK-5019, OAK-5020, OAK-5021, OAK-5022,
OAK-5023).
While they should all in principle work I don't consider them as done yet
as the test coverage is minimal and there's room for code(-style)
improvement.
But the point of this heads-up is about the API of OakEventFilter that
should ideally not have to change anymore, so if you're interested pls
have a look.
Cheers,
Stefan
On 26/10/16 19:09, "Stefan Egli" <st...@apache.org> wrote:
>On 26/10/16 16:48, "Michael Dürig" <md...@apache.org> wrote:
>
>>... Just ensure we expose the required
>>functionality on the Oak side as a proper API. That is, interface and
>>utility only and proper package versioning...
>
>Opened OAK-5013 for that which is just about the API.
>(it's a beautified version of the previous patches)
>
>Cheers,
>Stefan
>
>
Re: [REVIEW][API] Additions to JackrabbitEventFilter
Posted by Stefan Egli <st...@apache.org>.
(+oak-dev as it meanwhile has move to oak features alone)
I've committed OAK-5013 which introduces the OakEventFilter extension and
a number of such extensions (OAK-5019, OAK-5020, OAK-5021, OAK-5022,
OAK-5023).
While they should all in principle work I don't consider them as done yet
as the test coverage is minimal and there's room for code(-style)
improvement.
But the point of this heads-up is about the API of OakEventFilter that
should ideally not have to change anymore, so if you're interested pls
have a look.
Cheers,
Stefan
On 26/10/16 19:09, "Stefan Egli" <st...@apache.org> wrote:
>On 26/10/16 16:48, "Michael Dürig" <md...@apache.org> wrote:
>
>>... Just ensure we expose the required
>>functionality on the Oak side as a proper API. That is, interface and
>>utility only and proper package versioning...
>
>Opened OAK-5013 for that which is just about the API.
>(it's a beautified version of the previous patches)
>
>Cheers,
>Stefan
>
>
Re: [REVIEW][API] Additions to JackrabbitEventFilter
Posted by Stefan Egli <st...@apache.org>.
On 26/10/16 16:48, "Michael Dürig" <md...@apache.org> wrote:
>... Just ensure we expose the required
>functionality on the Oak side as a proper API. That is, interface and
>utility only and proper package versioning...
Opened OAK-5013 for that which is just about the API.
(it's a beautified version of the previous patches)
Cheers,
Stefan
Re: [REVIEW][API] Additions to JackrabbitEventFilter
Posted by Michael Dürig <md...@apache.org>.
On 26.10.16 4:13 , Stefan Egli wrote:
> In JCR-4046 I've now added another example for doing a new event feature
> in oak-jcr (this time for subtree aggregation).
Explicitly not commenting on this (also not implying anything). Just
limited bandwidth on my side.
>
> Wdyt? Should we move forward with suggested EventFilterBuilder approach
> and skip adding these 5 features to the JackrabbitEventFilter?
+1, I like that approach. Just ensure we expose the required
functionality on the Oak side as a proper API. That is, interface and
utility only and proper package versioning.
Michael
Re: [REVIEW][API] Additions to JackrabbitEventFilter
Posted by Stefan Egli <st...@apache.org>.
(+gentle bump ;)
In JCR-4046 I've now added another example for doing a new event feature
in oak-jcr (this time for subtree aggregation).
Wdyt? Should we move forward with suggested EventFilterBuilder approach
and skip adding these 5 features to the JackrabbitEventFilter?
Cheers,
Stefan
On 25/10/16 16:15, "Stefan Egli" <st...@apache.org> wrote:
>On 24/10/16 22:27, "Michael Dürig" <md...@apache.org> wrote:
>
>>A related question is how we retrofit this to Jackrabbit 2. How do users
>>know (and find out) which of these features is supported or not.
>
>We discussed this offline: what we could do instead of extending the
>JackrabbitEventFilter is to introduce a oak-core utility eg
>EventFilterBuilder that would take a JackrabbitEventFilter and return a
>'modified' filter that contains the extended filter functionality. That
>way it would be clear that it's only supported by oak-core. And it would
>remove the necessity to extend JackrabbitEventFilter in the first place.
>
>Added a sketch of how this could look to [0].
>
>Wdyt?
>
>Cheers,
>Stefan
>--
>[0] -
>https://issues.apache.org/jira/browse/JCR-4044?focusedCommentId=15605418&p
>a
>ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#commen
>t
>-15605418
>
>
Re: [REVIEW][API] Additions to JackrabbitEventFilter
Posted by Stefan Egli <st...@apache.org>.
On 25/10/16 16:15, "Stefan Egli" <st...@apache.org> wrote:
>... to introduce a oak-core utility ...
I meant to write: ... oak-jcr utility...
Re: [REVIEW][API] Additions to JackrabbitEventFilter
Posted by Stefan Egli <st...@apache.org>.
On 24/10/16 22:27, "Michael Dürig" <md...@apache.org> wrote:
>A related question is how we retrofit this to Jackrabbit 2. How do users
>know (and find out) which of these features is supported or not.
We discussed this offline: what we could do instead of extending the
JackrabbitEventFilter is to introduce a oak-core utility eg
EventFilterBuilder that would take a JackrabbitEventFilter and return a
'modified' filter that contains the extended filter functionality. That
way it would be clear that it's only supported by oak-core. And it would
remove the necessity to extend JackrabbitEventFilter in the first place.
Added a sketch of how this could look to [0].
Wdyt?
Cheers,
Stefan
--
[0] -
https://issues.apache.org/jira/browse/JCR-4044?focusedCommentId=15605418&pa
ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment
-15605418
Re: [REVIEW][API] Additions to JackrabbitEventFilter
Posted by Michael Dürig <md...@apache.org>.
On 24.10.16 6:13 , Stefan Egli wrote:
> Some might seem more straight-forward than others and yes it increases
> the JackrabbitEventFilter (perhaps too much, not sure). But they should
> all have some arguing/use cases in the description as to why it makes
> sense to have them. The goal of all this is to improve observation
> performance in the end.
>
A related question is how we retrofit this to Jackrabbit 2. How do users
know (and find out) which of these features is supported or not.
Michael