Monitor is an interface, an the implementation may provide many advanced features. The default Monitor implementation is built as a composite : it uses a set of sub-components to compute indicators about the application state.

Those components MUST implement the interface org.jmonit.spi.Aggregator (or extend org.jmonit.monitors.AbstractAggregator ). Before being used by the composite monitor, they receive the composite via the setComposite initialization method. This method will be called any time a new aggregator is added or removed to the monitor. The aggregator may use the composite to acces other aggregators.

Each aggregator receives datas from the composite monitor in the added(long) method. They can use this data to compute any indicator or run any process that can be usefull to monitor the application state. The clear() method is used to reset the aggregator from a management console. Be aware that some counters may not be set to null in this method : for example, the Concurrency aggregator manages a counter of concurrent active threads that use the monitor. Also be aware when creating custom aggreagtors that they are used in a concurrent context. synchronize the required methods or use java.util.concurrent classes to assume thread-safety and data consistency.

Custom aggregators are managed by a org.jmonit.spi.FeatureManager implementation (see later section about features). The default-one uses a properties files in classpath root : . This file lists class name of Factories used to create the aggregators instances. The factory ( org.jmonit.spi.Factory ) is used by jMonit to create new aggregators instance for monitors on demand.