Ark container class loading mechanism
The plugins and business modules are managed in the Ark container. The following figure describes the class loading mechanism:
Class loading mechanism of Ark container
Each Ark plugin has a separate classloader which loads a class in the following order:
- If byte codes generated by reflection are loaded, the system will throw a ClassNotFoundException to terminate the loading process. This primarily comes from our engineering practice: to avoid long time searches for the classes that can never be found.
- Search for the already loaded classes
- Search for classes in the JDK, which mainly consists of two parts: 1) the classes to be loaded by ExtClassloader; 2) the classes that are provided by the JDK but fail to be loaded from the ExtClassloader. When running locally, however, these classes will be added to the SystemClassloader’s classpath or they might be put into some third-party toolkits such as
sun.tools.attach.BsdVirtualMachinein tool.jar at the same time. This part also comes from our engineering practice, avoiding errors caused by loading a class more than once.
- See if the class is an interface from Sofa Ark, such as
com.alipay.sofa.Ark.spi.service.PluginActivator. If so, the class will be delegated to the classloader of the Ark container responsible for loading.
- See if it is located in the plugin import (including import-classes and import-package). If so, the loading will be delegated to the plugin classloader that will export it.
- Load in the plugin’s own classpath
- If the above steps have failed, it will try to load the class in SymtemClassloader to deal with the situation that the agent is used.
If the class fails to be loaded with all the above steps, the ClassNotFoundException will be thrown.
Ark business class loading mechanism
Each Ark business has a separate classloader. Its class loading mechanism is basically consistent with that of Ark plugin, except for the step 5:
For Ark business, no import configuration is provided. Instead, it defaults to importing all classes exported by plug-ins. To deal with some particular business scenarios, however, we do provide the Deny-import configuration so that we can exclude the classes exported by some plugins.
Class loading mechanism of Ark plugin resources
The Ark plugin supports importing and exporting resources. To achieve this, we need to configure the corresponding import and export settings in
sofa-Ark-plugin-maven-plugin. There are two ways to search for resources when using ClassLoader:
ClassLoader.getResource(String): When an Ark Plugin is searching for a single resource, it will delegate the Ark Plugin that will export the resource to load the class first. If multiple plugins export the resource at the same time, then the plugin with higher priority will export the resource first. If the loading fails or no other Ark Plugin has exported the resource, it will have a try from the current Ark Plugin;
ClassLoader.getResources(String): When the Ark Plugin is searching for multiple resources, it will load from all Ark Plugins that export the resources as well as from the current Ark Plugin;
Ark business resource loading mechanism
The Ark Biz will first load the resources exported by Ark Plugin by default. If developers want to search within the project, they can configure
sofa-Ark-maven-plugin. In this way, the Ark Biz will search for the resources inside Ark Biz rather than Ark Plugin.