The purpose of the previous chapter is to describe the structure of extension point loading key classes. This chapter focuses on the prominent features and some technical details of Dubbo extension point loading.
1. Enhanced version of JDK spi
The official description is as follows:
Dubbo improves the following problems of the JDK standard SPI: The
JDK standard SPI will instantiate all the implementations of the extension point at one time. If there is an extension implementation, it is time-consuming to initialize
, but if it is not used, it will also be loaded, which will waste resources.
If the extension point fails to load, even the extension point name will not be available. For example: JDK standard
ScriptEngine, get the name of the script type through getName(), but if
RubyScriptEngine fails to load the RubyScriptEngine class because the jruby.jar it depends on does not exist,
the reason for this failure is eaten, and it does not correspond to ruby. When the user executes a ruby script
, it will report that ruby is not supported, not the real reason for the failure.
2. Implementation of IOC and decorator pattern in dubbo
The IOC function in dubbo is completed by the objectFactory property in ExtensionLoader. In the last article describing the ExtensionLoader structure, it was mentioned that objectFactory holds an instance of AdaptiveExtensionFactory. AdaptiveExtensionFactory is an adaptive extension implementation. This adaptive extension implementation does not really complete the action of instance generation and loading. , but use SpiExtensionFactory and SpringExtensionFactory to load beans through keywords; SpiExtensionFactory uses ExtensionLoader.getExtensionLoader(type).getAdaptiveExtension() to get the adaptive extension class of the corresponding interface, and SpringExtensionFactory gets the extension through context.getBean(name) point instance. Currently, objectFactory is only used in the injectExtension method
The most direct manifestation of dubbo's use of the decorator pattern is to use the wrapper class to hold the actual extension point implementation class when creating an extension point instance, if there is a wrapper class for the extension point.
instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
What is obtained from ExtensionLoader is actually an instance of the wrapper class. Through the decorator pattern, the public logic of the extension point can be moved to the wrapper class without interfering with the specific extension point instance. A bit similar to AOP