Mercury event framework design notes


November 21, 2008 By oleg

For a long time I’ve been perplexed by what is going inside Maven, what’s there under the hood. Later I started learning the code and it gave me some perspective. Then I wrote a chunk of code – Mercury, but the exact understanding of what is happening inside is still hard to grasp: the code base is rather big and logic rather complex for a human mind to follow all the details.

All that, plus the necessity to provide tool integration, led to the idea to introduce an event framework into Mercury. All major processing object implement EventGenerator interface, that allows client code to register MercuryEventListener implementations and unRegister them as well.

**MercuryEvent** in itself has

* local TZ based start timestamp
* long duration in millis
* enumeration based type, which is also used for event partitioning
* name – obviously to identify this event
* tag to record lightweight information about event
* result to record the outcome of the event
* Map based payload – for tool integration to get access to typed objects, event wants to carry to the tool

Client code has several options to play with:

* event listener can declare a BitSet based mask of event types it wants to be notified about
* event manager could be configured with a mask of event types it will propagate
* there is a system property to define which event types should be propagated by the event manager, if one is created by the client code

The event manager itself separates event dispatching from event generator code via a thread pool, so that events are only placed into an event queue in the event generator thread, and then are sent out to listeners in parallel to the main code.

There is also a **DumbListener**, implemented to just peek at the events – prints them out to system.out or any other output stream.