[
https://issues.apache.org/jira/browse/PLUTO-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499444
]
Christian Raschka commented on PLUTO-267:
-----------------------------------------
Information about the new eventing algorithm:
Portlets can fire events during their action or event phase
(processAction()/processEvent()).
Furthermore container events exist to give notice that modes or parameter have
changed. Those
events are sent to all interested portlets (to be precise PortletWindows). To
be able to process
events the portlets have to declare it in the portlet.xml
(<supported-processing-event>).
After the action phase has ended (at the end of doAction()) a message is sent
to the
EventProvider (fireEvent()). Thereupon the EventProvider begins to send events.
Now the provider spools those events in a loop until all events are processed
(including newly
added events in the processEvent() method). For that purpose all events are
entered into an
event list and the flag notProcessed is set. After an event is processd the
flag is set to false.
Description of the loop body:
An arbitrary event is taken. Then all interested PortletWindows are seeked for
this event in the
registry. A new thread will be applied to all of those PortletWindows (if it is
not done yet).
Within this thread every event will be fired, which is collected for that
PortletWindow, by calling
the event container's (PortletContainerImpl's) fireEvent() method.
After the loop the algorithm waits until all threads are processed. Now the
render phase can start,
because all events are processed. The prior parameter will only be deleted at
the first time (flag
in the request), to enable that different render parameter can be set in
dissimilar events in the same
request.
Unfortunatly I have to apply a trick until now, to make firing of events during
the event processing
possible:
Within the loop the thread is created and started. If it is a normal flow, than
the impression arises
that there are no events which should be processed. Therefore I wait a
reasonable time, before
the need of doing something is checked. In theory it can happen that events are
not noticed (if
processEvent() takes too much time), but on that you cannot rely according to
the specification.
This problem has to be solved in the future.
It is also possible to specify how many events are allowed to be on the event
list. So an infinte loop
of events can be avoided.
In fact it could be possible that an event call takes an infinite time and the
thread does not end, too.
Then the program flow cannot switch over to the render phase.
Any comments or questions are welcome
> Implementation of the new Eventing Model
> ----------------------------------------
>
> Key: PLUTO-267
> URL: https://issues.apache.org/jira/browse/PLUTO-267
> Project: Pluto
> Issue Type: New Feature
> Affects Versions: 1.1-286-COMPATIBILITY
> Reporter: Christian Raschka
> Fix For: 1.1-286-COMPATIBILITY
>
> Attachments: eventing.021106.patch,
> eventing.moreeventsbug.051106.patch, eventing_rev14.240507.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
