1. Pluto
  2. PLUTO-538

New EventCoordinationService and merging EventContainer with PortletContainer


    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.0.0
    • Component/s: portlet container
    • Labels:


      Below copied (in part) from email discussion on the Pluto dev list, see also:

          • EventProvider SPI
            The EventProvider SPI also has "mixed" responsibilities.
            As a "-Provider" it is used to generate PortletEvent objects on behalf of the ActionResponse and EventResponse implementations which is
            subsequently stores in an internal list.
            But, it is also responsible for dispatching (coordinating) these registered PortletEvents after the container processAction or fireEvent
            The problem is that the EventProvider can only fireEvents which have been registered by the portlet itself.
            Container initiated events (as described by JSR-286) cannot be handled through this SPI, and Pluto currently doesn't have any support for
            them either.

      As the logic for event coordination (firing) is a very portal (and possibly policy based) functionality, while the creation of events by a
      portlet is very "standards" based, these two responsibilities shouldn't be "mixed" in one interface.

      I propose to remove the fireEvents handling from the EventProvider SPI and introduce a new SPI for handling the event coordination.
      The EventProvider SPI needs to be extended to allow retrieving the "registered" event queue after the portlet invocation by the container.

      (site note: the EventProvider as provided by the Pluto Portal Driver needs some major internal refactoring as well as its implementation is
      rather inefficient right now)

          • new: EventCoordinationService SPI
            As described above, PortletEvent coordination should be dealt with separately, which this new SPI will provide.
            It should as a minimum allow firing events based on a (also new to be defined) PortletEventQueue, as provided by the EventProvider or
            created directly by the container or possibly even the Portal itself.

      Some of the above steps have already been done or are in progress as result of several other JIRA issues like PLUTO-532 and PLUTO-537.
      In addition tho that, I'll merge the current EventContainer interface with the PortletContainer interface:
      as event handling is already implemented in the PortletContainerImpl, I see no reason why to keep these separate, and using a different container for the event handling simply makes no sense at all.


        Ate Douma created issue -
        Ate Douma added a comment -

        All fixed and implemented with the recent big bang refactoring and final commits r753592 and r753593

        Ate Douma added a comment - All fixed and implemented with the recent big bang refactoring and final commits r753592 and r753593
        Ate Douma made changes -
        Field Original Value New Value
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Mark Thomas made changes -
        Workflow jira [ 12454466 ] Default workflow, editable Closed status [ 12565326 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12565326 ] jira [ 12585987 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        2d 12h 43m 1 Ate Douma 14/Mar/09 03:25


          • Assignee:
            Ate Douma
            Ate Douma
          • Votes:
            0 Vote for this issue
            0 Start watching this issue


            • Created: