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