Dubbo Practice (v) extending the spring Schema

First review the dubbo-provider.xml defined in Dubbo Practice (i):

<?XML version= "1.0" encoding= "UTF-8"?><Beansxmlns= "Http://www.springframework.org/schema/beans"Xmlns:xsi= "Http://www.w3.org/2001/XMLSchema-instance"Xmlns:context= "Http://www.springframework.org/schema/context"Xmlns:dubbo= "Http://code.alibabatech.com/schema/dubbo"xsi:schemalocation= "Http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/ Spring-beans-4.3.xsd Http://www.springframework.org/schema/context Http://www.springframework.org/schema/con Text/spring-context-4.3.xsd Http://code.alibabatech.com/schema/dubbo Http://code.alibabatech.com/schema/dub Bo/dubbo.xsd ">    <!--automatically detects and assembles beans -    <Context:component-scanBase-package= "Org.warehouse.component.dubbo.provider" />    <!--provider app information for calculating dependencies -    <dubbo:applicationname= "Provider-of-hello-world-app" />    <!--exposing a service address using the Zookeeper Registration center -    <Dubbo:registryProtocol= "Zookeeper"Address= "192.168.1.103:2181" />        <!--exposing services on 20880 ports with the Dubbo protocol -    <Dubbo:protocolname= "Dubbo"Port= "20880" />    <!--declaring a service interface that needs to be exposed -    <Dubbo:serviceInterface= "Org.warehouse.component.dubbo.facade.DemoFacade"ref= "Demofacadeimpl" /></Beans>

This section analyzes the implementation of this part, that is, how to generate the implementation class object from a configuration file.

In many cases, we need to provide configurable support for the system, which can be configured directly on the basis of spring's standard beans, but it is awkward when the configuration is more complex or requires more rich control. The general approach is to use the original ecological way to parse the defined XML file, and then into the configuration object, which can certainly solve all the problems, but the implementation is cumbersome, especially when the configuration is very complex, parsing work is a burden to consider. Spring provides support for extensible schemas, which is a good compromise, and completing a custom configuration typically requires the following steps:

• Design configuration properties and JavaBean;
• Write an XSD file;
• Write Namespacehandler and Beandefinitionparser to complete parsing work;
• Write Spring.handlers and Spring.schemas all parts in series;
• Applied in the bean file.

The following combination of a small example to combat the above process.

Design Configuration Properties and JavaBean

The first thing to do is to design the configuration items and model them through JavaBean, in this case we need to configure the people entity, the configuration property name and age (ID is required by default):

 Public class people {        private  String ID;         Private String name;         Private Integer age;}

Writing an XSD file

To write an XSD file for the configuration item that was designed in the previous step, XSD is the schema's definition file, and the input and parsing output of the configuration is in XSD as the contract, in this case the XSD is as follows:

<?XML version= "1.0" encoding= "UTF-8"?><Xsd:schemaxmlns= "Http://blog.csdn.net/cutesource/schema/people"xmlns:xsd= "Http://www.w3.org/2001/XMLSchema"Xmlns:beans= "Http://www.springframework.org/schema/beans"targetnamespace= "Http://blog.csdn.net/cutesource/schema/people"elementFormDefault= "qualified"attributeFormDefault= "unqualified">    <Xsd:importnamespace= "Http://www.springframework.org/schema/beans" />    <xsd:elementname= "People">        <Xsd:complextype>            <xsd:complexcontent>                <xsd:extensionBase= "Beans:identifiedtype">                    <Xsd:attributename= "Name"type= "Xsd:string" />                    <Xsd:attributename= "Age"type= "Xsd:int" />                </xsd:extension>            </xsd:complexcontent>        </Xsd:complextype>    </xsd:element></Xsd:schema>

The specific meanings of the individual attributes of Xsd:schema are not explained too much, see XSD-<schema> elements.

<xsd:element name= "People" > corresponds to the name of the configuration item node, so this configuration is referenced in the app with people as the nodes named <xsd:attribute name= "name" Type= "xsd: String "/> and <xsd:attribute name=" age "type=" Xsd:int "/> Corresponds to the two attribute names of the configuration item people, so you can configure name and age two properties in your app. After the string and int types are completed, the XSD is stored under classpath, which is typically placed under the Meta-inf directory (this is where the example is located).

Write Namespacehandler and Beandefinitionparser to complete the parsing work

The following need to complete the parsing work, will use the Namespacehandler and Beandefinitionparser two concepts. Specifically, Namespacehandler will find a beandefinitionparser based on the schema and node name, and then beandefinitionparser to complete the specific parsing work. Therefore, the implementation classes of Namespacehandler and Beandefinitionparser need to be completed separately, Spring provides the default implementation classes Namespacehandlersupport and Abstractsinglebeandefinitionparser, and the simple way to do this is to inherit the two classes. This example is done in this way:

Import Org.springframework.beans.factory.xml.NamespaceHandlerSupport;  Public class extends Namespacehandlersupport {    publicvoid  init () {        Registerbeandefinitionparser (new  peoplebeandefinitionparser ());}    }

Where Registerbeandefinitionparser ("People", New Peoplebeandefinitionparser ()) is used to associate the node name and the parsing class, and when the People configuration item is referenced in the configuration, You will use Peoplebeandefinitionparser to parse the configuration. Peoplebeandefinitionparser is the parsing class in this example:

ImportOrg.springframework.beans.factory.support.BeanDefinitionBuilder;ImportOrg.springframework.beans.factory.xml.AbstractSingleBeanDefinitionParser;Importorg.springframework.util.StringUtils;Importorg.w3c.dom.Element; Public classPeoplebeandefinitionparserextendsAbstractsinglebeandefinitionparser {protectedClass Getbeanclass (element Element) {returnPeople.class; }    protected voidDoparse (element element, Beandefinitionbuilder Bean) {String name= Element.getattribute ("name"); String Age= Element.getattribute ("Age"); String ID= Element.getattribute ("id"); if(Stringutils.hastext (id)) {bean.addpropertyvalue ("id", id); }        if(Stringutils.hastext (name)) {Bean.addpropertyvalue ("Name", name); }        if(Stringutils.hastext (age)) {Bean.addpropertyvalue ("Age", integer.valueof (age)); }    }}

Where Element.getattribute is to get the attribute value in the configuration, Bean.addpropertyvalue is to put the attribute value into the bean.

Write Spring.handlers and Spring.schemas all parts in tandem

A few steps down the road will find that the development of handler and XSD can not make the application sense, so it is impossible to put the previous work into the system, Spring provides both the spring.handlers and Spring.schemas configuration files to do this, and these two files need to be written by ourselves and put into the Meta-inf folder, and the addresses of these two files must be meta-inf/ Spring.handlers and meta-inf/spring.schemas,spring will load them by default, in this case the spring.handlers is as follows:

Http\://Blog.csdn.net/cutesource/schema/people=study.schemaext.mynamespacehandler

The above means that when using a schema reference named "Http://blog.csdn.net/cutesource/schema/people", parsing is done through Study.schemaExt.MyNamespaceHandler.

The Spring.schemas is as follows:

Http\://blog.csdn.net/cutesource/schema/people.xsd=meta-inf/people.xsd

The above is to load the XSD file.

Apply in Bean file

This concludes with a simple custom configuration to complete and can be used in specific applications. The use of this method is simple, similar to configuring a normal spring bean, except that we need to customize the schema based on our own, in this case the reference is as follows:

<Beansxmlns= "Http://www.springframework.org/schema/beans"Xmlns:xsi= "Http://www.w3.org/2001/XMLSchema-instance"Xmlns:cutesource= "Http://blog.csdn.net/cutesource/schema/people"xsi:schemalocation= "Http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/ Spring-beans-2.5.xsd Http://blog.csdn.net/cutesource/schema/people http://blog.csdn.net/cutesource/schema/ People.xsd ">    <Cutesource:peopleID= "Cutesource"name= "Zhang San" Age= "+"/></Beans>

where xmlns:cutesource= "Http://blog.csdn.net/cutesource/schema/people" is used to specify the custom schema,xsi:schemalocation used to specify the XSD file. <cutesource:people id= "Cutesource" Name= "Zhang San" age= "/>" is a specific use instance of custom configuration.

Finally, you can load our custom configuration objects in a specific program using the basic bean loading method, such as:

ApplicationContext ctx=New classpathxmlapplicationcontext ("Application.xml"); People p= (people) Ctx.getbean ("Cutesource"); System.out.println (P.getid ()); System.out.println (P.getname ()); System.out.println (P.getage ());

The above is a spring-extensible schema that provides custom configuration support for the actual combat process.

Dubbo Practice (v) extending the spring Schema