Home > Java > javaTutorial > body text

The setApplicationContext method execution issue of the applicationContextAware interface and failed to get Spring beans

Linda Hamilton
Release: 2024-11-23 07:53:34
Original
133 people have browsed it

In this article I would like to share a problem I encountered recently, which I think may be of interest to you.

What is the issue?

The source code for both the testing and production environments is same, and both the local and testing environments run well, only the production environment run with an NPE of a service class failed to load, which added for the new requirements. This class inherits the interface from the Customize package (a self-developed toolkit).

The Project Structure

The setApplicationContext method execution issue of the applicationContextAware interface and failed to get Spring beans

The design of Customize relies on Spring to manage APIs and services. With Spring automatic scanning, the common classes of ApiEnhancer and ServiceEnhancer are loaded when initializing classes, and obtain instances by ApplicationContext. Debugging found that when loading them, the ApplicationContext is null and has not been initialized yet. It is initialized in the setApplicationContext method by implementing ApplicationContextAware, so it is speculated that the setApplicationContext method has not been executed.

During the loading process of the ApplicationContextProvider class, the static methods are loaded into the Method Area during the initialization phase. However, when using the ApplicationContext to get instances of beans, the static methods are directly invoked by the class name. As long as the API is created before the ApplicationContextProvider been allocated memory in the heap and instantiated, the setApplicationContext method will not be invoked to initialize.

The applicationContextProvider uses the annotation @Component, and the Api uses the annotation @RestController, and the two classes are in the same path. However, when Spring scans and loads them, there is no specific order, which means each of both classes may be created before another. In the production environment, the Api is created before the applicationContextProvider, resulting that when the static method invoked directly by the class name to obtain beans, the applicationContext has NOT been initialized.

The solutions

If the setApplicationContext method of the implementation class of the ApplicationContextAware interface has not been executed, first check whether the implementation class has been set to lazy loading or whether the project has configured global lazy loading.

In this project, the problem was caused by the creation order of the implementation classes of the ApiEnhancer and ApplicationContextAware interfaces, and the Api class is just a regular RESTful API that handles business logic and can be loaded when invoked by the front-end page. Therefore, changing to lazy loading solved the problem.

It is advisable to minimize the dependency relationship between classes in terms of loading order. If unavoidable, lazy loading, or annotations such as @DependsOn, @Order, @Priority can be used to control the loading order of beans.


Why are the creation order of production environment and testing environment different?

Let's debug to check the scanning process of Spring.

Starting with the scan method of ClassPathBeanDeterminationScanner.

The setApplicationContext method execution issue of the applicationContextAware interface and failed to get Spring beans

doScan method

The setApplicationContext method execution issue of the applicationContextAware interface and failed to get Spring beans

scanCandidateComponents method of ClassPathScanningCandidateComponentProvider

The setApplicationContext method execution issue of the applicationContextAware interface and failed to get Spring beans

findAllClassPathResources method of PathMatchingResourcePatternResolver

The setApplicationContext method execution issue of the applicationContextAware interface and failed to get Spring beans

doFindPathMatchingJarResources method

The setApplicationContext method execution issue of the applicationContextAware interface and failed to get Spring beans

JarFile is a class in the Java Standard Library under the package java.util.jar, which inherits and extends ZipFile. jarFile.entries() returns an iterator named JarEntryIterator.

The setApplicationContext method execution issue of the applicationContextAware interface and failed to get Spring beans

JarExitIterator is an implementation of the Iterator Pattern, which iterates on the entries of the parent class of JarFile.

The setApplicationContext method execution issue of the applicationContextAware interface and failed to get Spring beans

The entries method of ZipFile return an iterator named ZipExitIterator.

The setApplicationContext method execution issue of the applicationContextAware interface and failed to get Spring beans

The nextElement method of ZipExitIterator invokes the next method, which in turn invokes the getNextEntry method.

The setApplicationContext method execution issue of the applicationContextAware interface and failed to get Spring beans

getNextEntry is a native method.

The setApplicationContext method execution issue of the applicationContextAware interface and failed to get Spring beans

The native method is implemented in non Java languages and invoked within the Java Virtual Machine to implement underlying functionality, which may vary depending on the environment (Operating System or JDK version). JAR packages themselves do not have an order, so the actual traversal order may vary depending on different JAR packaging tools and environments.

The above is the detailed content of The setApplicationContext method execution issue of the applicationContextAware interface and failed to get Spring beans. For more information, please follow other related articles on the PHP Chinese website!

source:dev.to
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Latest Articles by Author
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template