Am 27.10.15 um 12:03 schrieb Michael Dürig: > > See GlobbingPathFilter [1] for how globbing on paths works. Note, that > that there is no globbing on the elements of a path (yet). >
Actually I'm not sure anymore of globbing is really helpful. For example in the case of the jsp scripting engine: this is interested in all changes to jsp files underneath /libs and /apps. However simply for listing all changes to /libs/**/*.jsp (and /apps/**/*.jsp) does not work as a remove might simply wipe /libs/foo and this triggers only a /libs/foo removal event. For changes of the jsp, it's similar, as the content of the jsp is not saved in the .jsp node, but in a sub node. At least to handle removal, listening to /libs and /apps is required. For add/change the filter might be fine tuned. However this makes a really complicated setup. Carsten > Michael > > > [1] > https://github.com/apache/jackrabbit-oak/blob/6a7c413ba69663bdf6b15e7aab211089f76da056/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.java > > > On 27.10.15 11:55 , Carsten Ziegeler wrote: >> Thanks Michael, >> >> so from that list, from a Sling perspective globbing seems to be the >> interesting part for me. Node types are not sufficient as we would need >> to filter on resource types, and that can become really tricky due to >> the type inheritance we have. >> >> So if no one complains I'll add globbing to our new api >> >> Regards >> Carsten >> >> Am 27.10.15 um 11:47 schrieb Michael Dürig: >>> >>> See my reply to Bertrand on 19.10.15 for an overview. >>> >>> Regarding capabilities, Oak's filtering mechanism allows filtering by >>> node type, by paths (including some globbing), by access control and by >>> visibility (internal Oak nodes). It has additional support for filtering >>> events of sub trees of added/deleted/moved nodes. See implementations of >>> org.apache.jackrabbit.oak.plugins.observation.filter.EventFilter for >>> further details. >>> >>> You can also implement your own EventFilter if you fancy. For most cases >>> though >>> org.apache.jackrabbit.oak.plugins.observation.filter.UniversalFilter >>> would do the trick. That one can be parametrised by a selector selecting >>> a node (relative to the current one) and a predicate to apply to that >>> node. >>> >>> Finally there is >>> org.apache.jackrabbit.oak.plugins.observation.filter.FilterBuilder, >>> which can be used to build complex filters from the basic ones. >>> >>> Currently this is pretty much only used internally in Oak. But I'd be >>> happy to make this more publicly available if we can come up with an >>> API. >>> >>> Michael >>> >>> On 27.10.15 10:41 , Carsten Ziegeler wrote: >>>> Am 27.10.15 um 10:23 schrieb Stefan Egli: >>>>> This is probably stating the obvious, but the resource-name-filter >>>>> should >>>>> be compatible with oak's filter capabilities (OAK-1133) >>>>> >>>> Or a subset. It would be great, if someone can summarize those >>>> capabilities here. >>>> >>>> Thanks >>>> Carsten >>>> >>>>> Cheers, >>>>> Stefan >>>>> >>>>> On 27/10/15 10:11, "Carsten Ziegeler" <[email protected]> wrote: >>>>> >>>>>> Continuing this discussion, right now the resource listeners can >>>>>> subscribe to a path and a change type (added/changed/removed). >>>>>> >>>>>> I think a pretty common use case is to filter on the resource >>>>>> name, all >>>>>> script implementations that cache, filter on the script extension. >>>>>> >>>>>> Should we support this for registering the listener? And if, how? >>>>>> >>>>>> Regards >>>>>> Carsten >>>>>> -- >>>>>> Carsten Ziegeler >>>>>> Adobe Research Switzerland >>>>>> [email protected] >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
