Event debugger

[julien1]

I worked a bit on the event controller context which is an interface for performing event coordination in the new portlet controller module.

Here are the principles of event control:

1/ when a portlet window produces an event this event is given to the event controller context that can react to that event and queue new events for consumption.

2/ when an event is queued for consumption, it will be delivered to the target portlet window.

In each cases the event could be ignored by the controller, for instance if the portlet window produces an event that it does not publish in its metadata or if the event controller context creates an event that cannot be consumed by the target window id.

So here I am talking about "portlet window" and not portlet. A portlet window has a window id and reference a portlet. This notion of window of course only pertains to the environment but actually we don't care much here.

Here is an exemple with portlet windows A,B and C.

1/ user click on portlet A which is a process action
2/ A is invoked and fires event foo : it is a produced event [A,foo]
3/ the event controller is invoked and in reaction queues event [B,bar] and [C,bar]
4/ [B,bar] is consumed by B and produces [B,juu]
5/ [C,bar] is consumed by C and produces [C,daa]
6/ the event controller is invoked with [B,juu] but chose to do nothing (so the event is 'discarded')
7/ the event controller is invoked with [C,daa] and in reaction queues the event [A, zii]
8/ [A,zii] is delivered and consumed by A that does not produce anything in reaction
9/ we are done!!! I hope it is clear

So for the JBPC I want to have an event debugger that would be used with a JSP tag that would display in the page a list of the events that would help developers to understand what happened during the action/event phase and my need is that someone comes up with the best system to display that.

[julien1]

here are the relevant methods of the event controller context

 /**
 * <p>Give control to the context when an event is produced. The session
 * argument gives to the context the capability to queue events in response
 * of the produced event or to interrupt the session. It has also access
 * to the full history of distributed events in order to provide advanced
 * implementation of event cycle detection.</p>
 *
 * <p>During the invocation of this method, any runtime exception thrown will signal
 * a failure and the produced event will be discarded although the event
 * distribution will continue.</p>
 *
 * <p>During the invocation of this method, any error thrown will be propagated
 * to the portlet controller invoker.</p>
 *
 * @param session the session
 * @param sourceEvent the source event
 * @param producedEvent the produced event
 */
 void eventProduced(EventPhaseSession session, Event sourceEvent, Event producedEvent);

 /**
 * <p>Signal to the context when an event is consumed by a portlet. The session argument
 * only provides querying capabilities and it is not possible to queue event
 * or interrupt the session.</p>
 *
 * <p>During the invocation of this method, any runtime exception thrown will
 * be ignored by the controller.</p>
 *
 * <p>During the invocation of this method, any error thrown will be propagated
 * to the portlet controller invoker.</p>
 *
 * @param session the session
 * @param sourceEvent the source event
 * @param consumedEvent the consumed event
 */
 void eventConsumed(EventPhaseSession session, Event sourceEvent, Event consumedEvent);

the first method is used to route an produced event to create events in reaction.

the second method is more an acknowledgement method that say that en event was consumed.

I plan to add other callbacks for ignored events or failures.

[julien1]

Here is the EventPhaseSession interface:

public interface EventPhaseSession
{

 /**
 * Queue an event for consumption. The queue is a FIFO queue.
 *
 * @param event an event
 * @throws IllegalArgumentException if the event is null
 * @throws IllegalStateException if an event cannot be published
 */
 void queueEvent(Event event) throws IllegalArgumentException, IllegalStateException;

 /**
 * Stop processing of all events and returns from the controller.
 *
 * @throws IllegalStateException if the session cannot be interrupted.
 */
 void interrupt() throws IllegalStateException;

}

It is usable really only during the routing phase and the event controller context can use it to queue events.

the interrupt method is used by the controller context can be used to interrupt the event phase (for instance a portal logout event could do that).

[wesleyhales]

I have a working demo for the debugger, how do you propose that I get the debugging data (i.e. portlet id, event param, etc) to the ui?

[julien1]

I propose to provide that data as a portlet request attribute during the render phase.

"wesleyhales" wrote:
I have a working demo for the debugger, how do you propose that I get the debugging data (i.e. portlet id, event param, etc) to the ui?

[julien1]

so it would be a portlet component inserted in a page.

I propose to provide that data as a portlet request attribute during the render phase.

"wesleyhales" wrote:
I have a working demo for the debugger, how do you propose that I get the debugging data (i.e. portlet id, event param, etc) to the ui?