Mail thread:

      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.



          Issue Links



              • Assignee:
                rombert Robert Munteanu
                cziegeler Carsten Ziegeler
              • Votes:
                0 Vote for this issue
                14 Start watching this issue


                • Created: