[PLUTO-538] New EventCoordinationService and merging EventContainer with PortletContainer

• Type: Improvement
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.0.0
• Fix Version/s: 2.0.0
• Component/s: portlet container
• Assignee: Ate Douma
• Reporter: Ate Douma
• Created: 11/Mar/09 14:42
• Updated: 14/Mar/09 03:25
• Resolved: 14/Mar/09 03:25

Description

Below copied (in part) from email discussion on the Pluto dev list, see also: http://www.nabble.com/More-required-Pluto-2.0-SPI-and-implementation-refactoring-issues-td21973310.html

• • • 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
      invocation.
      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.