You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Michael Dürig <md...@apache.org> on 2014/07/16 16:12:54 UTC
Adding further filtering capabilities to JackrabbitEventFilter
Hi,
What do people think about adding further filtering capabilities to
JackrabbitEventFilter? I was thinking of path exclusion and user data
exclusion:
- 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.
- User data exclusions would allow for excluding events with certain
user data. This could be useful if a session wants to bulk write some
data without the respective event handlers being fired. That session
would just need to set the user data to the same value as specified in
the exclusion filter.
Michael
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
Re: Adding further filtering capabilities to JackrabbitEventFilter
Posted by Alexander Klimetschek <ak...@adobe.com>.
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 6.8.14 7:42 , hsp wrote:
> That is:
> I have a case where it should be monitored when updating the value of a
> property occur in nodes of a certain type.
>
> Nowadays the event listener is triggered in any update in nodes of that
> type. I wonder if would be possible to configure to just trigger when
> updating certain property.
>
This should already be possible for Oak by building a custom filter
using the classes in
org.apache.jackrabbit.oak.plugins.observation.filter. I hesitate to add
too much additional support to the Jackrabbit API until we have a
clearer picture of the roadmap for Jackrabbit 2 and Oak.
Michael
> Regards
> Helio.
>
>
>
> --
> View this message in context: http://jackrabbit.510166.n4.nabble.com/Adding-further-filtering-capabilities-to-JackrabbitEventFilter-tp4661094p4661190.html
> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
>
Re: Adding further filtering capabilities to JackrabbitEventFilter
Posted by hsp <pi...@ibest.com.br>.
That is:
I have a case where it should be monitored when updating the value of a
property occur in nodes of a certain type.
Nowadays the event listener is triggered in any update in nodes of that
type. I wonder if would be possible to configure to just trigger when
updating certain property.
Regards
Helio.
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Adding-further-filtering-capabilities-to-JackrabbitEventFilter-tp4661094p4661190.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: Adding further filtering capabilities to JackrabbitEventFilter
Posted by Michael Dürig <md...@apache.org>.
Sorry I can't follow here. Could you be a bit more specific?
Michael
On 25.7.14 8:34 , hsp wrote:
> I wonder if would possible to set an filter directly to a node property if
> modified.
> Cheers
> Helio
>
>
>
> --
> View this message in context: http://jackrabbit.510166.n4.nabble.com/Adding-further-filtering-capabilities-to-JackrabbitEventFilter-tp4661094p4661130.html
> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
>
Re: Adding further filtering capabilities to JackrabbitEventFilter
Posted by hsp <pi...@ibest.com.br>.
I wonder if would possible to set an filter directly to a node property if
modified.
Cheers
Helio
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Adding-further-filtering-capabilities-to-JackrabbitEventFilter-tp4661094p4661130.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: Adding further filtering capabilities to JackrabbitEventFilter
Posted by Michael Dürig <md...@apache.org>.
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.
> - User data exclusions would allow for excluding events with certain
> user data. This could be useful if a session wants to bulk write some
> data without the respective event handlers being fired. That session
> would just need to set the user data to the same value as specified in
> the exclusion filter.
No much enthusiasm for this one, also from my side... such a feature has
the issue that it would no work across cluster nodes as session related
information does not come across cluster nodes.
Michael
Re: Adding further filtering capabilities to JackrabbitEventFilter
Posted by Michael Dürig <md...@apache.org>.
> I think that for the bulk write usecase it is more probable that the
> writer wants to disable the firing of (all) event handlers on its path and
> fire them at once at the end. So basically with the exclusion pattern
> there should be a predefined global excluded userdata that one can set on
> the ObservationManager in order to avoid all listeners. Otherwise the
> mechanism only works if the listener acts proactively on it (which might
> be more sane in the end :) ).
But this would rather be a thread scheduling issue than an observation
issue. For this we'd better improve configurability of event
generation/consumption and the associated thread pools. See also
OAK-1368 for some ideas here.
Michael
Re: Adding further filtering capabilities to JackrabbitEventFilter
Posted by Marius Petria <mp...@adobe.com>.
On 7/17/14, 11:22 AM, "Michael Dürig" <md...@apache.org> wrote:
>>>
>>>- User data exclusions would allow for excluding events with certain
>>>user
>>>data. This could be useful if a session wants to bulk write some data
>>>without the respective event handlers being fired. That session would
>>>just
>>>need to set the user data to the same value as specified in the
>>>exclusion
>>>filter.
>>
>>What would be an example of user data? Property value constraints?
>
>See ObservationManager.setUserData() and Event.getUserData(). It could
>be any string and its semantics would be specific to the usage.
I think that for the bulk write usecase it is more probable that the
writer wants to disable the firing of (all) event handlers on its path and
fire them at once at the end. So basically with the exclusion pattern
there should be a predefined global excluded userdata that one can set on
the ObservationManager in order to avoid all listeners. Otherwise the
mechanism only works if the listener acts proactively on it (which might
be more sane in the end :) ).
Marius
Re: Adding further filtering capabilities to JackrabbitEventFilter
Posted by Michael Dürig <md...@apache.org>.
On 16.7.14 6:46 , Robert Munteanu wrote:
>
> I know that /content/ugc is not interesting to my listener, so I can
> exclude it by path. However, the basis of the exclusion can be
> expressed more directly in the form of a property constraint,
> something like [jcr:primaryType=my:ugcNode]. In practice the filtering
> is a bit more complex, the condition would be: "Have a parent of type
> my:Page until - but excluding - /content". However, I'm not sure if
> this can be expressed concisely by a JackrabbitEventFilter or if the
> evaluation can be done is an efficient manner by Oak.
Oak has quite powerful filter capabilities for observation. Filters that
affect whole subtrees (like sub tree exclusion or inclusion) are the
ones that are most beneficial wrt. performance as they allow for
skipping whole parts of the tree.
The JackrabbitEventFilter is a dump storage object extending from JCR
2.1's EventFilter. It is used for passing filter parameters, which would
otherwise be passed individually when registering an event listener.
Using JackrabbitEventFilter for anything more complex than
inclusion/exclusion would bend the initial too much IMO.
We should probably think of ways to expose the extended filter
capabilities through a richer API. A neat idea would be to reuse JCR's
query syntax for this. However exposing a simple object model along with
a builder would probably be simpler, more flexible, extensible and
easier to maintain and use.
>> - User data exclusions would allow for excluding events with certain user
>> data. This could be useful if a session wants to bulk write some data
>> without the respective event handlers being fired. That session would just
>> need to set the user data to the same value as specified in the exclusion
>> filter.
>
> What would be an example of user data? Property value constraints?
See ObservationManager.setUserData() and Event.getUserData(). It could
be any string and its semantics would be specific to the usage.
Michael
>
> Thanks,
>
> Robert
>
Re: Adding further filtering capabilities to JackrabbitEventFilter
Posted by Robert Munteanu <ro...@apache.org>.
Hi Michael,
On Wed, Jul 16, 2014 at 5:12 PM, Michael Dürig <md...@apache.org> wrote:
>
> Hi,
>
> What do people think about adding further filtering capabilities to
> JackrabbitEventFilter? I was thinking of path exclusion and user data
> exclusion:
>
> - 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.
That sounds interesting. I don't think I've seen this in practice but
I can imagine it being used. However I think that such exclusions are
really based on more directly expressed criteria. Taking for example
* /content is the pool of all content
* /content/ugc contains users-generated content
I know that /content/ugc is not interesting to my listener, so I can
exclude it by path. However, the basis of the exclusion can be
expressed more directly in the form of a property constraint,
something like [jcr:primaryType=my:ugcNode]. In practice the filtering
is a bit more complex, the condition would be: "Have a parent of type
my:Page until - but excluding - /content". However, I'm not sure if
this can be expressed concisely by a JackrabbitEventFilter or if the
evaluation can be done is an efficient manner by Oak.
>
> - User data exclusions would allow for excluding events with certain user
> data. This could be useful if a session wants to bulk write some data
> without the respective event handlers being fired. That session would just
> need to set the user data to the same value as specified in the exclusion
> filter.
What would be an example of user data? Property value constraints?
Thanks,
Robert