You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Alexander Klimetschek <ak...@adobe.com> on 2014/08/02 02:43:30 UTC
Re: Adding further filtering capabilities to JackrabbitEventFilter
On 21.07.2014, at 00:23, Michael Dürig <md...@apache.org> wrote:
> On 16.7.14 4:12 , Michael Dürig wrote:
>>
>> - Path exclusion would allow certain paths to be excluded from sending
>> events. This is helpful if you want to listen to say /content but not to
>> /content/foo. Relieving event handlers from handling such exclusions
>> will lower client code complexity and increase performance.
>
> I created JCR-3797 and OAK-1978 to track this.
I think it would be more useful to allow globbing paths. The current getAdditionalPaths() could be changed to allow path globbing.
For example /home/users/**/mail/**/sentitems/**
(Could also be regular expressions)
This when you don't use very detailed node types, but rely more on path structures. We have a lot of use cases of that in our product. I have previously mentioned that over in [1].
[1] https://issues.apache.org/jira/browse/OAK-1133
Cheers,
Alex
Re: Adding further filtering capabilities to JackrabbitEventFilter
Posted by Michael Dürig <md...@apache.org>.
On 5.8.14 2:08 , Alexander Klimetschek wrote:
> On 04.08.2014, at 00:41, Michael Dürig <md...@apache.org> wrote:
>
>>> I think it would be more useful to allow globbing paths. The current getAdditionalPaths() could be changed to allow path globbing.
>>
>> This already exists in Oak. See org.apache.jackrabbit.oak.plugins.observation.filter.GlobbingPathFilter.
>
> Ah, great. But I can't register this using the JCR API, right? I would need to set up the whole observation listener through oak apis?
No, not for the time being due to compatibility concerns. See the second
part of my previous message.
Michael
Re: Adding further filtering capabilities to JackrabbitEventFilter
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 04.08.2014, at 00:41, Michael Dürig <md...@apache.org> wrote:
>> I think it would be more useful to allow globbing paths. The current getAdditionalPaths() could be changed to allow path globbing.
>
> This already exists in Oak. See org.apache.jackrabbit.oak.plugins.observation.filter.GlobbingPathFilter.
Ah, great. But I can't register this using the JCR API, right? I would need to set up the whole observation listener through oak apis?
Cheers,
Alex
Re: Adding further filtering capabilities to JackrabbitEventFilter
Posted by Michael Dürig <md...@apache.org>.
On 2.8.14 2:43 , Alexander Klimetschek wrote:
> On 21.07.2014, at 00:23, Michael Dürig <md...@apache.org> wrote:
>
>> On 16.7.14 4:12 , Michael Dürig wrote:
>>>
>>> - Path exclusion would allow certain paths to be excluded from sending
>>> events. This is helpful if you want to listen to say /content but not to
>>> /content/foo. Relieving event handlers from handling such exclusions
>>> will lower client code complexity and increase performance.
>>
>> I created JCR-3797 and OAK-1978 to track this.
>
> I think it would be more useful to allow globbing paths. The current getAdditionalPaths() could be changed to allow path globbing.
This already exists in Oak. See
org.apache.jackrabbit.oak.plugins.observation.filter.GlobbingPathFilter.
The reason this is not exposed through the API is that we still need to
maintain a certain degree of compatibility with Jackrabbit 2 and so far
we used to backport all additional features that we exposed through the
Jackrabbit API. If there is sufficient need for this feature we can
discuss adding it and clarify its support in Jackrabbit 2.
Michael
>
> For example /home/users/**/mail/**/sentitems/**
>
> (Could also be regular expressions)
>
> This when you don't use very detailed node types, but rely more on path structures. We have a lot of use cases of that in our product. I have previously mentioned that over in [1].
>
> [1] https://issues.apache.org/jira/browse/OAK-1133
>
> Cheers,
> Alex
> r