Higher level observation servicesPage comment added by Bertrand DelacretazIf by "this" you mean the tentative API, then agreed, I'll remove it. The interesting thing is that a number of the patterns mentioned here might not need observation at all, a form of slow polling would work for most of them and be more scalable. As you say, the Sling JcrResourceListener makes it easy to listen to specific events, but to support that it has to blindly relay a lot of JCR events to the OSGi event queue, which might also hinder scalability. I'll run some tests with Oak to measure what the actual impact is.
In reply to a comment by Felix Meschberger:
My impression is that we don't need this The idea of Sling's conversion of JCR observation events to OSGi EventAdmin events is exactly this level of abstraction. By registering an OSGi EventHandler service an declaring what kinds of events you are interested in you can exactly have this filtering.
Change Notification Preferences
View Online
|
|
- [CONF] Apache Sling > Higher level observation services confluence
- [CONF] Apache Sling > Higher level observation services confluence
- [CONF] Apache Sling > Higher level observation services confluence
- [CONF] Apache Sling > Higher level observation services confluence
- [CONF] Apache Sling > Higher level observation services confluence
- [CONF] Apache Sling > Higher level observation services confluence
- [CONF] Apache Sling > Higher level observation services confluence
- [CONF] Apache Sling > Higher level observation services confluence
- [CONF] Apache Sling > Higher level observation services confluence
- [CONF] Apache Sling > Higher level observation services confluence
- [CONF] Apache Sling > Higher level observation services confluence
