Processing lifecycle callbacks
The section documents the lifecycle api and its behaviour.
Classes bound into an EventProcessor register for lifecycle callbacks with annotations on methods. A Lifecycle interface is implemented by the generated EventProcessor, lifecycle method calls are routed to annotated callback methods.
The source project for the examples can be found here
Table of contents
Lifecycle - init
EventProcessor#init
Calls init on any node in the graph that has registered for an init callback. The init calls
are invoked in topological order.
Lifecycle - teardown
EventProcessor#tearDown
Calls tearDown on any node in the graph that has registered for an tearDown callback.
The tearDown calls are invoked reverse topological order.
Lifecycle - start
EventProcessor#start
Calls start on any node in the graph that has registered for an onStart callback. The start calls
are invoked in topological order. Start must be called after init
Lifecycle - stop
EventProcessor#stop
Calls stop on any node in the graph that has registered for an onStop callback.
The stop calls are invoked reverse topological order.
Attaching a user node to lifecycle callback
User nodes that are added to the processing graph can attach to the lifecycle callbacks by annotating methods with the relevant annotations.
public static class MyNode {
@Initialise
public void myInitMethod() {
System.out.println("Initialise");
}
@Start
public void myStartMethod() {
System.out.println("Start");
}
@Stop
public void myStopMethod() {
System.out.println("Stop");
}
@TearDown
public void myTearDownMethod() {
System.out.println("TearDown");
}
}
public static void main(String[] args) {
var processor = Fluxtion.interpret(new MyNode());
processor.init();
processor.start();
processor.stop();
processor.tearDown();
}
Output
Initialise
Start
Stop
TearDown