Mercury Event Framework Design Notes

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 big and logic is complex for a human mind to follow all the details.

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

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 events

• 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 the event manager should propagate which event types, 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 sent 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.