as you know we're currently in the process of moving away from the OSGi
event based observation to the ResourceChangeListener interfaces. Main
reason is moving to a more scalable/better performing solution.

We started very simple with the ResourceChangeListener: listeners
register themselves with the three where they are interested in changes.
They can also specify whether they are interested in adds, removes,
and/or updates. This is basic functionality.

Recently, support for a glob pattern was added, for example scripting
engines like jsp are only interested in changes of "*.jsp" files. While
this sounds like a great idea, this only works reliable for adds and
updates. However it does not work for removes, if e.g. only the parent
resource of a jsp (or any parent) is removed, then usually you only get
a resource removal event for that parent. As the listener is registered
with the *.jsp pattern and the parent name usually does not match this,
the listener does not get this event at all.

I guess a good compromise would be to do the filtering for add and
update but send all remove events for the relevant tree to the listener.

For resource mapping we currently register a listener that listens to
all events that deal with certain properties. So if a specific property
is added, removed, or updated this listener should be triggered. Again
for add and update this might be solvable, but for a delete it is not.
Furthermore the information about properties for a change event is
currently specified as optional, so the listener can't rely that this
information is send. And I don't think that it makes sense to send this
information for each and every event we have, as usually listeners do
not care about specific properties.

I tend to move this special filtering to the listener. However this
leaves us still with the problem that the listener is mounted at /. I
think we should narrow down the support for resource mappings to
specific paths. We can make this configurable of course.

Finally, recently some people suggested that we support all of Oaks
filtering possibilities for the ResourceChangeListener. I'm not a fan of
that - first of all, we should only support what is really needed.
Second, as soon as we support it, it means that every resource provider
needs to support it which might but a high burden for nothing on the
implementations. And finally, as we already see with the globbing,
filtering is nice but we have to be careful for remove events and
clearly specifiy how this works - and specify it in a way that it really
works for the listeners.

Carsten Ziegeler
Adobe Research Switzerland

Reply via email to