|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | |||||||||
public interface Verifier
A 'Verifier' as the name suggests is used to evaluate criterias
on the filtered (or unfiltered) log event model.
Verifiers are usually configured with certain criterias and observe the
execution of an (usually refining) action on the current log event model. For
example, we can configure a verifier to monitor a filter action on the log
event model and can trigger when the criteria configured in the verifier is
met and can execute an action.
Verfiers can be both quantitative (for example, can count the number of
matches) and qualitative (for example, can analyze the occurances against
time, or can observe the transition between namespaces).
On meeting its criteria a Verifier usually executes an action or in Insight a
Job. A Job
performs a specific action, usually to report the action to the user (like by
sending an email or showing a pop-up).
A Job will usually be sent a JobMessage which will
contain the information to be acted upon. There can be multiple types of
messages. For more information, see
JobMessage.
The Verifier framework is not aware of any actions being
executed in Insight, and also of actions it is observing. For an action
to be verifiable it needs to be aware of the Verifier framework, and
should provide means to register Verifier(s) and also call them
appropriately.
An abstract implementation of the Verifier interface is provided
as AbstractVerifier, which takes care of a number of tasks
that need to be performed by a Verifier.
Anyone developing a new Verifier should keep in mind that the
verify method is called
in the same thread that executes the action which the Verifier
is observing. Hence, any performance bottlenecks in the code inside this
method will effect the entire action desired by the action.
A Verifier can be identified by the fully qualified class name
of the class implementing the Verifier. The verifier also needs
to return a display name for the Verifier. This would be used
for easy identification of the Verifier by the user.
A Verifier can be serialized and stored for future invocation.
A factory mechanism is provided to deserialize a Verifier. For
a format of the serialized Verifier see
VerifierDeserializer.
Every Verifier must provide a default constructor implementation.
AbstractVerifier,
Job,
JobMessage,
VerifierDeserializerImpl| Method Summary | |
|---|---|
VerifierDeserializer |
getDeserializer()
This method returns the deserializer to be used for serializing the Verifier. |
java.lang.String |
getDisplayName()
Returns the display name of the verifier to be displayed in the UI of the application to the user. |
java.lang.String |
getUID()
Returns the unique identifier for this Verifier - the fully
qualified name of the class implementing the interface. |
void |
notifyEndAction(LogEventModel logEventModel)
Notifies the verifier that the action has ended on the current log event model. |
void |
notifyStartAction(LogEventModel logEventModel)
Notifies the verifier that an action has started on the current log event model. |
void |
registerJob(Job job)
Registers a Job to be called on meeting the criteria
specified in this Verifier. |
java.lang.String |
serialize()
Returns the string format of the Verifier for persistance,
possibly in the preference mechanism of the application. |
void |
verify(LogEvent logEvent,
FilterCriteria filterCriteria,
boolean success)
Verifies and registers an action being executed on the log event model. |
| Method Detail |
|---|
void notifyStartAction(LogEventModel logEventModel)
logEventModel - The log event model on which the action is being
executed.
void verify(LogEvent logEvent,
FilterCriteria filterCriteria,
boolean success)
At present only the filter action is supposed to be able to support
Verifiers. Should other actions (say, search) also be
modified to support Verifiers, the codebase should be
refactored to create a super-type (RefinementCriteria?) of
FilterCriteria and the criteria for the other action
(in our example SearchCriteria) and the signature of this
method should be changed to take the new Type as a parameter, and all
implementations adjusted accordingly.
logEvent - The event which was acted upon.filterCriteria - The criteria which was executed on the event.success - If the event meets the criteria or not.void notifyEndAction(LogEventModel logEventModel)
For accumulator kind of verifiers, this will be the trigger to call the
Job(s).
logEventModel - The log event model on which the action is being
executed.void registerJob(Job job)
Job to be called on meeting the criteria
specified in this Verifier.
job - The Job to be called on trigger.java.lang.String serialize()
Verifier for persistance,
possibly in the preference mechanism of the application. The format in
which the serialized format is returned is described in the documentation
for VerifierDeserializer.
String form of the Verifier.VerifierDeserializerVerifierDeserializer getDeserializer()
Verifier. A Verifier may use the default
implementation of VerifierDeserializer provided:
VerifierDeserializerImpl, or provide their own deserializer.
VerifierDeserializer to be used for the Verifier.java.lang.String getUID()
Verifier - the fully
qualified name of the class implementing the interface.
java.lang.String getDisplayName()
Verifier.
|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | |||||||||