This appendix details the XML Schema-based configuration introduced in Spring 2.0.
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.
<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
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; also, please note 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; the process involved in doing so is covered in the appendix entitled Appendix B, Extensible XML authoring.