You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "Christian Raschka (JIRA)" <ji...@apache.org> on 2007/05/27 22:32:16 UTC

[jira] Commented: (PLUTO-267) Implementation of the new Eventing Model

    [ 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.