This article briefly talks about the hook interfaces
ApplicationRunner, which are sometimes referred to as
Runner in the following.
Runner callback timing
Refer to the source code of the
org.springframework.boot.SpringApplication#run() method. You can know the timing of the callbacks for
ApplicationRunner callbacks, the following steps have been ensured to be executed.
Environmentbuilt-in variables are created and properties are populated.
Bannerhas been printed.
BeanFactoryare created and the context is refreshed (
refreshContext), meaning that all singleton
Beans have been initialized and their properties assembled.
Servletcontainer is started successfully, such as the built-in
Jettycontainers have been started normally and can receive and process requests normally.
- The startup information is finished printing, you will generally see log output like
Started OrderExportApplication in XXX seconds (JVM running for YYY).
That is, the
ApplicationRunner callback can use all the property values that already exist in the single instance
Environment built-in variables in the context, so many times the
demo project will operate in the
Simple use of ## Runner
The only difference is that
CommandLineRunner#run() receives arguments from the
main method, which is an array of strings (an array of indefinite strings), while
ApplicationRunner#run() receives arguments of type
ApplicationArguments, and the corresponding implementation class is
@Component can be applied directly to the implementation class of
ApplicationRunner, as opposed to adding the corresponding implementation singleton to the
It is also possible to act directly on the methods corresponding to the anonymous classes of
CommandLineRunner through the
@Bean annotation, e.g.
Or implement the
CommandLineRunner interface directly in the startup class (“This approach is not recommended “).
interface or the@Order
annotation to define the order ofRunner` callbacks, the smaller the specified order number, the higher the priority.
Runner usage scenarios
This subsection is a suggestion based on personal programming habits. When the
Runner hook interface calls back “If an exception is thrown, it will directly cause the application process to exit “, so if the
Runner callback method must pay attention to the exception catching and handling. Based on this feature, combined with the previous analysis of the callback timing of the
Runner interface, the main scenarios it applies to are
- Printing a log to mark the successful start of a service or to mark the successful loading of certain properties.
- Setting property values or starting components, e.g., switching on certain components, loading some application-level cache, starting timed tasks, etc.
- Preload data (more commonly used in some testing scenarios and can be used in conjunction with the
@Profileannotation to specify a specific
profilebefore it takes effect).
- Need to use the
The following uses
CommandLineRunner to start all
Quartz (remember to import the dependencies
quartz first), and for simplicity the scheduler uses the in-memory state.
After starting the application, the logs are as follows.