附录A.XML Schema-based configuration

附录 A. XML Schema-based configuration

目录

A.1. Introduction

A.2. XML Schema-based configuration

A.2.1. Referencing the schemas

A.2.2. The util schema

A.2.3. The jee schema

A.2.4. The lang schema

A.2.5. The tx (transaction) schema

A.2.6. The aop schema

A.2.7. The tool schema

A.3. Setting up your IDE

A.3.1. Integration issues

A.1. Introduction

This section of the reference documentation details the XML Schema based configuration introduced in Spring 2.0.

DTD support?

Authoring Spring configuration files using the older DTD style is still fully supported.

Nothing will break if you forego the use of the new XML Schema-based approach to authoring Spring XML configuration files. All that you lose out on is more succinct and clearer configuration. In the end, all of the XML configuration, be it DTD- or Schema-based, all boils down to the same object model in the container.

The central motivation for moving to XML Schema based configuration files was to make Spring XML configuration easier. The 'classic' <bean/>-based approach is good, but its generic-nature comes with a price in terms of configuration overhead.

From the Spring IoC containers point-of-view, everything is a bean. That's great news for the Spring IoC container, because if everything is a bean then everything can be treated in the exact same fashion. The same, however, is not true from a developer's point-of-view. The objects defined in a Spring XML configuration file are not all generic, vanilla beans. Usually, each bean requires some degree of specific configuration.

Spring 2.0's new XML Schema-based configuration addresses this issue. The <bean/> element is still present, and if you wanted to, you could continue to write the exact same style of Spring XML configuration using only <bean/> elements. The new XML Schema-based configuration does, however, make Spring XML configuration files substantially clearer to read. In addition, it allows you to express the intent of a bean definition.

The key thing to remember is that the new custom tags work best for infrastructure or integration beans: for example, AOP, collections, transactions, integration with 3rd-party frameworks such as Mule, etc, while the existing bean tags are best suited to application-specific beans, such as DAOs, service layer objects, validators, etc.

The examples included below will hopefully convince you that the inclusion of XML Schema support in Spring 2.0 was a good idea. The reception in the community has been encouraging; something that is not covered in this section (at least not right now) is the fact that this new 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.