New EventCoordinationService and merging EventContainer with PortletContainer
-----------------------------------------------------------------------------
Key: PLUTO-538
URL: https://issues.apache.org/jira/browse/PLUTO-538
Project: Pluto
Issue Type: Improvement
Components: portlet container
Affects Versions: 2.0.0
Reporter: Ate Douma
Assignee: Ate Douma
Fix For: 2.0.0
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
