The definition of beans in spring can be programmed, defined in the properties file, or can be defined in XML files, most of which are in XML form, because the XML format has good self-explanatory and easy to write and maintain. The document structure, data definition, and format validation for XML can be done through DTDs and schemas, using a DTD before spring2.0, and using schemaafter spring2.0. Using the schema approach makes spring easier to integrate with third parties, and third parties can provide a simpler and more user-friendly way of personalizing configuration.
There is no introduction to XMLschema specifics, but there is an important conceptual namespace (namespace) in the schema that spring is using to parse the third-party custom configuration format, In spring AOP, transaction is a good example of a 31st implementation of its own custom configuration.
Example: xmlns=http://www.springframework.org/schema/beans is the default namespace
xmlns:aop=HTTP://WWW.SPRINGFRAMEWORK.ORG/SCHEMA/AOP -defined AOP namespaces
xmlns:tx= "Http://www.springframework.org/schema/tx" defines the namespace of things
The format definition file under each namespace is specified by Xsi:schemalocation.
This document is not about spring, so here is a brief explanation of how spring will parse the configuration file by schema.
The Defaultbeandefinitiondocumentreader class will read the spring XML configuration file as a document format.
Each element node is read to determine the namespace of the element, and if it is the default namespace (Http://www.springframework.org/schema/beans), the bean definition is read by default. If not as NamespaceURI as below
HTTP://WWW.SPRINGFRAMEWORK.ORG/SCHEMA/AOP,
Http://www.springframework.org/schema/tx,
Http://code.alibabatech.com/schema/dubbo
Then go through the process of parsing the custom element. According to the namespace to obtain the specific processor Namespacehandler
The Defaultnamespacehandlerresolver class passed key to NamespaceURI, and in the class there is a map storage class for all the custom Namespacehandler, The value in this map is loaded with the tool class propertiesloaderutils all the values in "Meta-inf/spring.handlers"
This document focuses on Dbbo's custom processor Dubbonamespacehandler How to convert Dubbo custom elements into bean definitions and register them in a spring container.
Dubbonamespacehandler has registered so many of the XML element nodes Beandefinitionparser used to parse Dubbo definitions, such as:
<dubbo:applicationname= "Dubbo-admin"/>
<dubbo:registryaddress= "${dubbo.registry.address}" check= "false" file= "false"/>
<dubbo:referenceid= "Registryservice" interface= "Com.alibaba.dubbo.registry.RegistryService" check= "false"/ >
<dubbo:referenceid= "Demoservice" interface= "Com.alibaba.dubbo.demo.DemoService"/>
<dubbo:serviceinterface= "Com.alibaba.dubbo.demo.DemoService" ref= "Demoservice"/>
Each beandefinitionparser converts the XML element above into a data structure beandefinition within spring, and eventually instantiates the corresponding bean when referenced, such as <dubbo:application/> Nodes are applicationconfig.
Of course, the default configuration is also possible, such as:
<dubbo:registryaddress= "${dubbo.registry.address}" check= "false" file= "false"/>
Can also be configured as
<bean id= "Registry" class= "Com.alibaba.dubbo.config.RegistryConfig"/>
<property name= "Address" value= "${dubbo.registry.address}"/>
<property name= "Check" value= "false"/>
<property name= "File" value= "false"/>
<bean/>
The use of custom element parsing is more concise, but also can block some specific implementation types, If you do not need to know com.alibaba.dubbo.config.RegistryConfig this class, just need to know the registration registry This element can be, the user can through the document and the schema of the IDE's automatic prompts can be easily configured.
Dubbo Source Analysis (ix): Integration with spring