Writing Your Own Monitor

Your monitors are lame. How do I write my own?

First you need to decide if you're a plain old Monitor, or a super cool CompositeMonitor.

What's makes the CompositeMonitor so special?

The CompositeMonitor can hold sub-monitors. This ability to group monitors can come in handy sometimes.

The MonitoringEngine also supports some free correlation of Monitors inside CompositeMonitors. The compositeMonitorStarted() and compositeMonitorCompleted() methods are used to auto-correlate sub-monitors to a containing parent monitor started on the same thread. The following code will explain this a little better.

public void doParent() {
    TransactionMonitor parent = new TransactionMonitor("parent");
    try {
        doChild();
        parent.succeeded();
    } finally {
        parent.done();
    }
}
 
public void doChild() {
    TransactionMonitor child = new TransactionMonitor("child");
    try {
        // Doing childish things...
 
        child.succeeded();
    } finally {
        child.done();
    }
}

After child.done() is called, the MonitoringEngine will add a reference to child inside parent's list of children. Monitor processors can use this feature to process a parent and it's children as a whole. For example, writing the whole graph of monitors to an XML is much simpler this way.

Ok, I don't need the CompositeMonitor stuff, how do I make a simple monitor?

All you need to do is implement the Monitor interface.

There's a lot of convenience methods for adding primitive attributes to the Monitor, though. If you want to save some effort, you should consider subclassing from AbstractMonitor. This abstract class implements all the methods defined by the Monitor interface. All you need to do is add your additional logic and you're on your way.

What if I do want to use the CompositeMonitor stuff?

In that case, you'll need to implement the CompositeMonitor interface. This interface extends the Monitor interface as well, so you have to implement the methods held on that interface as well.

The CompositeMonitor interface has two key differences from the Monitor interface. The first is that the CompositeMonitor holds references to sub-monitors. The second is that sub-monitors inherit attributes from their parent monitor. Client code can flag attributes as not-inheritable, if desired.

To assist you in implementing the CompositeMonitor interface, you can subclass from the AbstractCompositeMonitor class. This class implements all methods on the CompositeMonitor interface. It also overrides the set() methods from the Monitor interface so that attributes set using those methods are marked as inheritable by default.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License