Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about the use of advanced features of jarslink1.6.1. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

Use of jarslink advanced features

Jarslink has added a lot of advanced features since the 1.6.1 update, so let's take a look at how these advanced features are used.

Use of annotations

The new version adds annotation support. Users only need to call the ModuleConfig.addScanPackage (String) method when building ModuleConfig. You can call this method multiple times to add multiple scan package configurations, which will be used by spring as scan package configuration.

Some points for attention after the annotation is opened

If you want to use xml to define bean after the annotation is enabled, as in an ordinary spring project, you only need to have one configuration class (this class needs to be in the scan path of spring), that is, the class annotated as @ Configuration, and then annotate @ ImportResource ("your spring bean defines the xml file location") on this class. It should be noted that because this method is limited to the implementation of spring, the bean defined in xml cannot rely on the bean defined by the annotation. The bean defined by annotations can rely on the bean defined in xml.

If a bean whose name value is the same as the name value in xml is defined by annotations, the annotated bean will be replaced by the bean defined in xml.

Can be implemented but not recommended

If the bean that the annotation depends on does not exist at run time (that is, the bean was introduced into the maven, but the set scope is test or provide will be excluded at compile time), then you can define the same bean in the parent container at this time, and module A can still use the bean. The description is as follows:

Module A depends on bean B in other jar packages

The jar package is deleted during packaging or deleted after packaging.

A bean C with the same definition as bean B is provided in the parent container

Module A running in the parent container can still use bean B transparently (in fact, it is a function provided by bean C at this time)

What if the same bean is defined in both the parent container and the module? At this point, the module's bean will still be used in the module instead of the bean in the parent container.

Do not use this feature if it is not necessary

When should priority be given to using annotations to load

If there is such a situation in the module project: the xml file of spring bean exists in the dependent jar package to be introduced, the location is the same as that in the module project, and the xml file is not needed, then loading the file using xml cannot be excluded, and the bean in the xml file will still be loaded, while loading using annotations will not have the problem (annotations actually have A similar problem occurs if the scanned package name is the same, but normally the package name is not the same as the third-party jar package.

How to use the multi-version registration function

Version 1.6.1 supports registering multiple versions at the same time. This feature is turned off by default. If you need to enable it, you can use ModuleConfig.setNeedUnloadOldVersion (false) to enable multiple versions. When enabled, the register (Module) method of ModuleManager will be able to register multiple versions of the same module. If it is not enabled, the newly registered module will be replaced.

Known problem

The default implementation of version 1.6.1 of ModuleManager has concurrency problems. Even if the multi-version feature is enabled, if a module registers with two or more threads at the same time when registering for the first time, some modules may be lost, that is, one or more modules may fail to register. The problem will be fixed in the next version.

This problem occurs only when the module is registered for the first time, but not if it is registered concurrently after the module has been registered before.

The sample code opens the annotation ModuleLoader moduleLoader = null; ModuleManager moduleManager = null; ModuleConfig config = new ModuleConfig (); / / * / configure other options for config / / * config.addScanPackage ("com.alipay") / / loading Module with this configuration will recursively scan class Module module = moduleLoader.load (config) under all com.alipay directories in the jar package; use the multi-version registration function ModuleConfig config = new ModuleConfig (); / / * / configure other options of config / / * config.withName ("demo"). WithVersion ("1.0"). WithNeedUnloadOldVersion (false) Module module = moduleLoader.load (config); moduleManager.register (module); config.withName ("demo"). WithVersion ("2.0"). WithNeedUnloadOldVersion (false); module = moduleLoader.load (config); moduleManager.register (module); / / the version number of the module here is 2.0, and the later registered module will be set to the default module module = moduleManager.find ("demo"). / / the previously registered version can be obtained by specifying the version number (because version 2.0 is configured to allow multiple versions of module, version 1.0 can still be found at this time) module = moduleManager.find ("demo", "1.0"); details of multi-version registration (implementation mechanism)

If you look at the source code, you can see that the needUnloadOldVersion option is only valid in this registration, that is, if the currently registered module configuration allows multiple versions, then even if the previous module is not allowed to exist multiple versions will be ignored, only using the configuration of this registered module, on the contrary, if the previous module allows multiple versions to exist, but the currently registered module does not allow it, then the previous module will be uninstalled. How will the system uninstall the module when the currently registered module does not allow multiple versions? If the currently registered module does not allow multiple versions, only the previous default version module will be deleted, and other modules will not be deleted. Please see the following example for details.

ModuleConfig config = new ModuleConfig (); / / * / configure other options for config / / * config.withName ("demo"). WithVersion ("1.0"). WithNeedUnloadOldVersion (true); Module module = moduleLoader.load (config); moduleManager.register (module); config.withName ("demo"). WithVersion ("2.0"). WithNeedUnloadOldVersion (false) Module = moduleLoader.load (config); moduleManager.register (module)

In the above example, at the end of the system, there will be modules of version 1.0 and version 2.0.

ModuleConfig config = new ModuleConfig (); / / * / configure other options for config / / * config.withName ("demo"). WithVersion ("1.0"). WithNeedUnloadOldVersion (true); Module module = moduleLoader.load (config); moduleManager.register (module); config.withName ("demo"). WithVersion ("2.0"). WithNeedUnloadOldVersion (false) Module = moduleLoader.load (config); moduleManager.register (module)

In the above example, in the end, the system will only have version 2.0, and version 1.0 will be uninstalled when version 2.0 is registered.

ModuleConfig config = new ModuleConfig (); / / * / configure other options for config / / * config.withName ("demo"). WithVersion ("1.0"). WithNeedUnloadOldVersion (true); Module module = moduleLoader.load (config); moduleManager.register (module); moduleManager.activeVersion ("demo", "1.1") Config.withName ("demo") .withVersion ("2.0"). WithNeedUnloadOldVersion (false); module = moduleLoader.load (config); moduleManager.register (module)

In the above example, there will still be both version 1.0 and version 2.0, because after the registration of version 1.0, the system switches the default version of the default demo module to a version 1.1 that does not exist. When the version 2.0 demo module is registered, although multiple versions are not allowed to exist in version 2.0 configuration, the default version will be uninstalled at this time. But at this point the default version of the demo module is a non-existent 1.1, so no actual version will be uninstalled, and 1.0 will therefore be retained.

This is how the advanced features of jarslink1.6.1 shared by the editor are used. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.