XML Schema-based configuration
Introduction This appendix details the use of XML Schema-based configuration in Spring. The 'classic' <object/>-based schema is good, but its generic-nature comes with a price in terms of configuration overhead. Creating a custom XML Schema-based configuration makes Spring XML configuration files substantially clearer to read. In addition, it allows you to express the intent of an object definition. The key thing to remember is that creating custom schema tags work best for infrastructure or integration objects: for example, AOP, collections, transactions, integration with 3rd-party frameworks, etc., while the existing object tags are best suited to application-specific objects, such as DAOs, service layer objects, etc. Please note the fact that the XML configuration mechanism is totally customisable and extensible. This means you can write your own domain-specific configuration tags that would better represent your application's domain; the process involved in doing so is covered in the appendix entitled .
XML Schema-based configuration
Referencing the schemas As a reminder, you reference the standard objects schema as shown below <?xml version="1.0" encoding="UTF-8"?> <objects xmlns="http://www.springframework.net" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.net http://www.springframework.net/schema/objects/spring-objects-1.1.xsd"> <!-- <object/> definitions here --> </objects> The 'xsi:schemaLocation' fragment is not actually required, but can be included to reference a local copy of a schema (which can be useful during development) and assumes the XML editor will look to that location and load the schema. The above Spring XML configuration fragment is boilerplate that you can copy and paste (!) and then plug <object/> definitions into like you have always done. However, the entire point of using custom schema tags is to make configuration easier. The rest of this chapter gives an overview of custom XML Schema based configuration that are included with the release. As of Spring.NET 1.2.0 it is no longer necessary to explicitly configure the namespace parsers that come with Spring via a custom section in App.config. You will still need to register custom namespace parsers if you are writing your own.
The <literal>tx</literal> (transaction) schema The tx tags deal with configuring objects in Spring's comprehensive support for transactions. These tags are covered in the chapter entitled . You are strongly encouraged to look at the 'spring-tx-1.1.xsd' file that ships with the Spring distribution. This file is (of course), the XML Schema for Spring's transaction configuration, and covers all of the various tags in the tx namespace, including attribute defaults and suchlike. This file is documented inline, and thus the information is not repeated here in the interests of adhering to the DRY (Don't Repeat Yourself) principle. In the interest of completeness, to use the tags in the tx schema, you need to have the following preamble at the top of your Spring XML configuration file; the emboldened text in the following snippet references the correct schema so that the tags in the tx namespace are available to you. <?xml version="1.0" encoding="UTF-8"?> <object xmlns="http://www.springframework.net" xmlns:aop="http://www.springframework.net/aop" xmlns:tx="http://www.springframework.net/tx"> <!-- <object/> definitions here --> <!-- <tx/> transaction definitions here --> <!-- <aop/> AOP definitions here --> </object> Often when using the tags in the tx namespace you will also be using the tags from the aop namespace (since the declarative transaction support in Spring is implemented using AOP). The above XML snippet contains the relevant lines needed to reference the aop schema so that the tags in the aop namespace are available to you. You will also need to configure the AOP and Transaction namespace parsers in the main .NET application configuration file as shown below As of Spring.NET 1.2.0 it is no longer necessary to explicitly configure the namespace parsers that come with Spring via a custom section in App.config. You will still need to register custom namespace parsers if you are writing your own. <configuration> <configSections> <sectionGroup name="spring"> <!-- other Spring config sections handler like context, typeAliases, etc not shown for brevity --> <section name="parsers" type="Spring.Context.Support.NamespaceParsersSectionHandler, Spring.Core"/> </sectionGroup> </configSections> <spring> <parsers> <parser type="Spring.Aop.Config.AopNamespaceParser, Spring.Aop" /> <parser type="Spring.Transaction.Config.TxNamespaceParser, Spring.Data" /> </parsers> </spring> </configuration>
The <literal>aop</literal> schema The aop tags deal with configuring all things AOP in Spring. These tags are comprehensively covered in the chapter entitled . In the interest of completeness, to use the tags in the aop schema, you need to have the following preamble at the top of your Spring XML configuration file; the emboldened text in the following snippet references the correct schema so that the tags in the aop namespace are available to you. <?xml version="1.0" encoding="UTF-8"?> <objects xmlns="http://www.springframework.net" xmlns:aop="http://www.springframework.net/aop"> <!-- <object/> definitions here --> <!-- <aop/> AOP definitions here --> </objects> You will also need to configure the AOP namespace parser in the main .NET application configuration file as shown below As of Spring.NET 1.2.0 it is no longer necessary to explicitly configure the namespace parsers that come with Spring via a custom section in App.config. You will still need to register custom namespace parsers if you are writing your own. <configuration> <configSections> <sectionGroup name="spring"> <!-- other Spring config sections handler like context, typeAliases, etc not shown for brevity --> <section name="parsers" type="Spring.Context.Support.NamespaceParsersSectionHandler, Spring.Core"/> </sectionGroup> </configSections> <spring> <parsers> <parser type="Spring.Aop.Config.AopNamespaceParser, Spring.Aop" /> </parsers> </spring> </configuration>
The <literal>db</literal> schema The db tags deal with creating IDbProvider instances for a given database client library. The following snippet references the correct schema so that the tags in the db namespace are available to you. The tags are comprehensively covered in the chapter entitled . <?xml version="1.0" encoding="UTF-8"?> <objects xmlns="http://www.springframework.net" xmlns:db="http://www.springframework.net/db"> <!-- <object/> definitions here --> <!-- <db/> database definitions here --> </objects> You will also need to configure the Database namespace parser in the main .NET application configuration file as shown below As of Spring.NET 1.2.0 it is no longer necessary to explicitly configure the namespace parsers that come with Spring via a custom section in App.config. You will still need to register custom namespace parsers if you are writing your own. <configuration> <configSections> <sectionGroup name="spring"> <!-- other Spring config sections handler like context, typeAliases, etc not shown for brevity --> <section name="parsers" type="Spring.Context.Support.NamespaceParsersSectionHandler, Spring.Core"/> </sectionGroup> </configSections> <spring> <parsers> <parser type="Spring.Data.Config.DatabaseNamespaceParser, Spring.Data" /> </parsers> </spring> </configuration>
The <literal>wcf</literal> schema The wcf schema is used when you would like to create a client channel to invoke a WCF service as compared to generating a proxy using svcutil.exe. The channel factory approach requires that you have a known interface which describes the service. This approach is quite common to use when you are controlling both the client and the server code, but is not exclusive to that case. The advantage of coding to the interface is that it can be easily replaced with another implementation, perhaps for testing purposes to facilitate unit testing. For example, the following code can be used to create an instance of the ICaclulator interface that invokes the remote service. ICalculator calculator = ChannelFactory<ICalculator>("calculatorEndpoint").CreateChannel(); int result = calculator.Add(1,2); You need to configure the remoting namespace parser in the main .NET application configuration file as shown below As of Spring.NET 1.2.0 it is no longer necessary to explicitly configure the namespace parsers that come with Spring via a custom section in App.config. You will still need to register custom namespace parsers if you are writing your own. <configuration> <configSections> <sectionGroup name="spring"> <!-- other Spring config sections handler like context, typeAliases, etc not shown for brevity --> <section name="parsers" type="Spring.Context.Support.NamespaceParsersSectionHandler, Spring.Core"/> </sectionGroup> </configSections> <spring> <parsers> <parser type="Spring.ServiceModel.Config.WcfNamespaceParser, Spring.Services" /> </parsers> </spring> </configuration>
The <literal>remoting</literal> schema The remoting tags are for use when you want to export an existing POCO object as a .NET remoted object or to create a client side .NET remoting proxy. The tags are comprehensively covered in the chapter <?xml version="1.0" encoding="UTF-8"?> <objects xmlns="http://www.springframework.net" xmlns:r="http://www.springframework.net/remoting"> <!-- <object/> definitions here --> <!-- <r/> remoting definitions here --> </objects> You will also need to configure the remoting namespace parser in the main .NET application configuration file as shown below As of Spring.NET 1.2.0 it is no longer necessary to explicitly configure the namespace parsers that come with Spring via a custom section in App.config. You will still need to register custom namespace parsers if you are writing your own. <configuration> <configSections> <sectionGroup name="spring"> <!-- other Spring config sections handler like context, typeAliases, etc not shown for brevity --> <section name="parsers" type="Spring.Context.Support.NamespaceParsersSectionHandler, Spring.Core"/> </sectionGroup> </configSections> <spring> <parsers> <parser type="Spring.Remoting.Config.RemotingNamespaceParser, Spring.Services" /> </parsers> </spring> </configuration>
The <literal>nms</literal> messaging schema The nms tags are for use when you want to configure Spring's messaging support. The tags are comprehensively covered in the chapter <?xml version="1.0" encoding="UTF-8"?> <objects xmlns="http://www.springframework.net" xmlns:r="http://www.springframework.net/nms"> <!-- <object/> definitions here --> <!-- <nms/> remoting definitions here --> </objects> You will also need to configure the remoting namespace parser in the main .NET application configuration file as shown below As of Spring.NET 1.2.0 it is no longer necessary to explicitly configure the namespace parsers that come with Spring via a custom section in App.config. You will still need to register custom namespace parsers if you are writing your own. <configuration> <configSections> <sectionGroup name="spring"> <!-- other Spring config sections handler like context, typeAliases, etc not shown for brevity --> <section name="parsers" type="Spring.Context.Support.NamespaceParsersSectionHandler, Spring.Core"/> </sectionGroup> </configSections> <spring> <parsers> <parser type="Spring.Messaging.Nms.Config.NmsNamespaceParser, Spring.Messaging.Nms" /> </parsers> </spring> </configuration>
The <literal>validation</literal> schema The validation tags are for use when you want definte IValidator object instances. The tags are comprehensively covered in the chapter <?xml version="1.0" encoding="UTF-8"?> <objects xmlns="http://www.springframework.net" xmlns:v="http://www.springframework.net/validation"> <!-- <object/> definitions here --> <!-- <v/> valdiation definitions here --> </objects> You will also need to configure the validation namespace parser in the main .NET application configuration file as shown below As of Spring.NET 1.2.0 it is no longer necessary to explicitly configure the namespace parsers that come with Spring via a custom section in App.config. You will still need to register custom namespace parsers if you are writing your own. <configuration> <configSections> <sectionGroup name="spring"> <!-- other Spring config sections handler like context, typeAliases, etc not shown for brevity --> <section name="parsers" type="Spring.Context.Support.NamespaceParsersSectionHandler, Spring.Core"/> </sectionGroup> </configSections> <spring> <parsers> <parser type="Spring.Validation.Config.ValidationNamespaceParser, Spring.Core" /> </parsers> </spring> </configuration>
The <literal>objects</literal> schema Last but not least we have the tags in the objects schema. Examples of the various tags in the objects schema are not shown here because they are quite comprehensively covered in the section entitled (and indeed in that entire chapter). <?xml version="1.0" encoding="UTF-8"?> <objects xmlns="http://www.springframework.net" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.net http://www.springframework.net/schema/objects/spring-objects-1.1.xsd"> <object id="foo" class="X.Y.Foo, X"> <property name="name" value="Rick"/> </object> </objects>
Setting up your IDE To setup VS.NET to provide intellisence while editing XML file for your custom XML schemas you will need to copy your XSD files to an appropriate VS.NET directory. Refer to the following chapter for details, For SharpDevelop, follow the directions on the "Editing XML" product documentation.