3rd tutorial - AOT no spring
Table of contents
Introduction
This tutorial is an introduction to building Fluxtion dependency injection container ahead of time without Spring. The reader should be proficient in Java, maven, git and have completed the second lottery tutorial before starting this tutorial.
Our goal is to create the lottery processing logic ahead of time as in tutorial 4, but with no Spring dependencies.
At the end of this tutorial you should understand:
- How to add user classes to an event processor programmatically using a FluxtionGraphBuilder
- How to generate a container ahead of time using the Fluxtion maven plugin
- Understand that spring is a build time configuration provider only
Example project
The example project is referenced in this tutorial.
Building AOT with FluxtionGraphBuilder
To build an event processor container we need to specify the managed instances to the Fluxtion compiler. In previous examples we used the Spring config to supply that information, now we will specify the instances programmatically. Once the components are specified the maven plugin will generate the event processor file as part of the build. Steps for a non-spring aot generation:
- Implement FluxtionGraphBuilder adding user classes programmatically
- Remove all the spring dependencies from the project, both libraries and config
- Add the fluxtion maven plugin to the build
Add user classes with FluxtionGraphBuilder
LotteryEventProcessorBuilder adds user classes to the programmatically in the buildGraph method using the supplied EventProcessorConfig.
EventProcessorConfig gives configuration access to the event processor before the compilation/generation phase. User
classes are added with eventProcessorConfig.addNode(lotteryMachine, "lotteryMachine")
, this adds the lotteryMachine
instance to the processor and sets the variable name in the generated file to lotteryMachine.
We are customising the variable names in the config so the generated file exactly matches the spring aot example.
A single add with eventProcessorConfig.addNode(lotteryMachine)
would be sufficient, as the ticketStore instance would
be included through discovery and variable names are generated by the compiler. Functionally the two are the same but the
variable names in the generated event processor would not match the previous tutorial.
Source file class and package name are configured in the configureGeneration method, via the supplied FluxtionCompilerConfig.
Updating the build
The pom.xml is updated to remove all references to spring and the fluxtion maven plugin scan goal is used to discover and process FluxtionGraphBuilder’s in the project. Additionally, the spring-lottery.xml config file is deleted as it is no longer required.
Build output
Running the build generates the LotteryProcessor.java source file which is exactly the same as the generated version in tutorial 4.
The maven plugin will print to console the FluxtionGraphBuilder instances it has discovered and is processing.
Conclusion
In this tutorial we have seen how user classes can be added to the event processor programmatically for ahead of time compilation. The generated event processor is exactly the same as the spring configured version
- Programmatic access gives the programmer full control of what classes are in the event processor
- Spring config is a configuration layer that is not used at runtime
- Programmatic and spring configurations are completely interchangeable
I hope you have enjoyed reading this tutorial, and it has given you a desire to adding event auditing to your applications . Please send me any comments or suggestions to improve this tutorial