You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Stefan Egli (JIRA)" <ji...@apache.org> on 2015/06/01 09:28:17 UTC

[jira] [Commented] (SLING-4751) New Observation Support

    [ https://issues.apache.org/jira/browse/SLING-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567013#comment-14567013 ] 

Stefan Egli commented on SLING-4751:
------------------------------------

I see two problems with the previous (current) implementation - not sure if you covered them already:
 # the 'bridge' listener has to listen to any event (ie {{/}}) as it has no idea on what paths the listeners are interested.
 # there is no distinction between events generated by the local instance and by any other instance in the cluster (external)

Re 1. the new ResourceListener has {{PATHS}} which is good. But I guess the 'bridge' listener will still have to listen to {{/}} so not much gained there?
Re 2. this I think would be an important distinction to have.

> New Observation Support
> -----------------------
>
>                 Key: SLING-4751
>                 URL: https://issues.apache.org/jira/browse/SLING-4751
>             Project: Sling
>          Issue Type: Improvement
>          Components: API, JCR, ResourceResolver
>            Reporter: Carsten Ziegeler
>            Assignee: Carsten Ziegeler
>             Fix For: API 2.10.0, Resource Resolver 1.2.6
>
>
> Mail thread:
> http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983F2.20402%40apache.org%3E
> Starting mail
> Right now, resources changes are propagated through event admin - which
> at the time sounded like a good idea. Over time, this has shown to be a
> bottle neck.
> Basically there are at least three problems:
> - the sender of the resource events does not know whether there is a
> receiver, therefore events for each and every change need to be sent
> - event objects are immutable and therefore all relevant data needs to
> be calculated upfront, even if it's not used. For example a resource
> event contains the resource type which needs to be fetched from the
> repository, even if no one is interested in it.
> - receivers of the events can't easily act on behalf of the user who
> initiated the change.
> I created a new listener api at [1] which defines a ResourceListener
> interface and some ways how to specify the events one is interested in.
> The user aware resource listener allows to act on behalf of the user (if
> that information is available).
> On the other side, a new service, the ObservationReporter [2] is
> defined. Resource providers report changes through this interface. The
> payload of such an event is an interface which allows for lazy retrieval
> of the information.
> We can also use this mechanism for compatibility and an implementation
> of the observation reporter might sent all events via the event admin.
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/observation/
> [2]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)