Hi, 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. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
