Example: Event listener

The following code example demonstrates how to fire a listenerCountChanged event:
// imagine this snippet inside an EJB or servlet method.
//	Make an inner class implementing the required event interfaces.
EventSourceEvents listener = new Object() implements EventSourceEvents.class
{
	void listenerCountChanged(EventSource es, int old, int newCount)
	{
		try
		{
    	InitialContext ic = new InitialContext();
			// here, the asynch bean can access an environment variable of
			// the component which created it.
		 	int i = (Integer)ic.lookup("java:comp/env/countValue").intValue());
			if(newCount == i)
			{
				// do something interesting 
			}
			// call this event when the following code executes:
		}
		catch(NamingException e)
		{
		}
	}
	void listenerExceptionThrown(	EventSource es, Object listener, 
							String methodName, Throwable exception)
	{
	}
	void unexpectedException(EventSource es, Object runnable, Throwable exception)
	{
	}
}
// register it.
es.addListener(listener);

...

// now fire an event which the previous listener receives.
EventSourceEvents proxy = (EventSourceEvents)
			es.getEventTrigger(EventSourceEvents.class, false);

proxy.listenerCountChanged(es, 0, 1);

// now, fire another event, you can call any of the methods.
proxy.listenerCountChanged(es, 4, 5);

In this example, you get a proxy for the interface that we want to fire a method on. Then, call the method corresponding to the event on the proxy. This action causes the same method with the same parameters to be called on any event listeners that implement the EventSourceEvents interface and that were previously registered with the EventSource "es". The same proxy can be used to send multiple events simultaneously.

The boolean parameter on the getEventTrigger() method is named "sameTransaction". When the sameTransaction parameter is false, a new transaction is started for each event listener invoked and these event listeners can be called in parallel to the caller. However, the event() method always is blocked until all of the event listeners are notified. If the sameTransaction parameter is true, the current transaction, if any, on the thread is used for all of the event listeners; that is, the event listeners share the transaction of the method that fired the event. For that reason, all event listeners must run serially in an undetermined order. That is, the order in which the listeners are called is undefined and the order in which listeners are registered does not act as a guide for the order used at run time. The method on the proxy does not return until all of the event listeners are called; that is, it is a synchronous operation.

The parameters that are passed by reference and listeners do not interfere with these references unless the method that fired the event has purposefully designed such interaction. For example, event listeners can be used as collaborators and add data to a map, which was a parameter. Each event listener runs on its own transaction, independent of any transaction that is active on the thread. Extreme care must be taken when the sameTransaction parameter is false because the parameters can be accessed by multiple threads.


Related tasks
Developing event listeners



Searchable topic ID:   xasb_eventlistener
Last updated: Jun 21, 2007 8:07:48 PM CDT    WebSphere Business Integration Server Foundation, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.wasee.doc/info/ee/asyncbns/xmp/xasb_eventlistener.html

Library | Support | Terms of Use | Feedback