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 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.
doScan method
scanCandidateComponents method of ClassPathScanningCandidateComponentProvider
findAllClassPathResources method of PathMatchingResourcePatternResolver
doFindPathMatchingJarResources method
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.
JarExitIterator is an implementation of the Iterator Pattern, which iterates on the entries of the parent class of JarFile.
The entries method of ZipFile return an iterator named ZipExitIterator.
The nextElement method of ZipExitIterator invokes the next method, which in turn invokes the getNextEntry method.
getNextEntry is a native method.
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.
Top comments (0)