[
https://issues.apache.org/jira/browse/PLUTO-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma resolved PLUTO-538.
-----------------------------
Resolution: Fixed
All fixed and implemented with the recent big bang refactoring and final
commits r753592 and r753593
> 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.
