On 30.10.15 8:58 , Carsten Ziegeler wrote:
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.
Right, this is the case when going through JCR's or Jackrabbit's
observation API: Oak sets its filters up such that sub tree events are
not sent as this is usually too much of an overhead. Directly on Oak you
could set the filter up differently though. What is currently missing
however is name globbing (i.e. for *.jsp). This should be relatively
easy to add.
IMO the biggest missing piece in the picture is a good public API
exposing all this extra functionality. I think we need a joint effort
here to define this at some point .
Michael
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" <cziege...@apache.org> 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
cziege...@apache.org
