XML Schema-based configurationIntroductionThis appendix details the XML Schema-based configuration introduced in Spring 2.0 and enhanced and extended in Spring 2.5 and 3.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 the opportunity to have more succinct and clearer configuration.
Regardless of whether the XML configuration is DTD- or Schema-based, in the end
it all boils down to the same object model in the container (namely one or
more BeanDefinition instances).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; 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 .XML Schema-based configurationReferencing the schemasTo switch over from the DTD-style to the new XML Schema-style, you need
to make the following change.
]]><!-- bean definitions here -->]]>The equivalent file in the XML Schema-style would be...
]]><!-- bean definitions here -->]]>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).The above Spring XML configuration fragment is boilerplate that you can copy and paste
(!) and then plug <bean/> definitions into like you have always
done. However, the entire point of switching over is to
take advantage of the new Spring 2.0 XML tags since they make configuration easier. The
section entitled demonstrates how you can
start immediately by using some of the more common utility tags.The rest of this chapter is devoted to showing examples of the new Spring XML Schema
based configuration, with at least one example for every new tag. The format follows
a before and after style, with a before snippet of XML showing
the old (but still 100% legal and supported) style, followed immediately
by an after example showing the equivalent in the new XML Schema-based
style.The util schemaFirst up is coverage of the util tags. As the name
implies, the util tags deal with common, utility
configuration issues, such as configuring collections, referencing constants,
and suchlike.To use the tags in the util schema, you need to have
the following preamble at the top of your Spring XML configuration file;
the text in the snippet below references the correct schema so that
the tags in the util namespace are available to you.xmlns:util="http://www.springframework.org/schema/util"http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd"
]]><!-- bean definitions here -->]]><util:constant/>Before...
]]>The above configuration uses a Spring FactoryBean
implementation, the FieldRetrievingFactoryBean, to
set the value of the 'isolation' property on a bean
to the value of the 'java.sql.Connection.TRANSACTION_SERIALIZABLE'
constant. This is all well and good, but it is a tad verbose and (unnecessarily)
exposes Spring's internal plumbing to the end user.
The following XML Schema-based version is more concise
and clearly expresses the developer's intent ('inject this constant
value'), and it just reads better.
]]>Setting a bean property or constructor arg from a field valueFieldRetrievingFactoryBean
is a FactoryBean which retrieves a
static or non-static field value. It is typically
used for retrieving publicstaticfinal constants, which may then be used to set a
property value or constructor arg for another bean.
Find below an example which shows how a static field is exposed, by
using the staticField
property:
]]>There is also a convenience usage form where the static
field is specified as the bean name:]]>
This does mean that there is no longer any choice in what the bean id is (so
any other bean that refers to it will also have to use this longer name),
but this form is very concise to define, and very convenient to use as an
inner bean since the id doesn't have to be specified for the bean
reference:
]]>
It is also possible to access a non-static (instance) field of another bean,
as described in the API documentation for the
FieldRetrievingFactoryBean
class.
Injecting enum values into beans as either property or constructor arguments is very
easy to do in Spring, in that you don't actually have to do
anything or know anything about the Spring internals (or even about classes such
as the FieldRetrievingFactoryBean). Let's look at an example
to see how easy injecting an enum value is; consider this JDK 5 enum:
Now consider a setter of type PersistenceContextType:.. and the corresponding bean definition:
]]>
This works for classic type-safe emulated enums (on JDK 1.4 and JDK 1.3) as well;
Spring will automatically attempt to match the string property value to a constant
on the enum class.
<util:property-path/>Before...<!-- target bean to be referenced by name -->
]]><!-- will result in 10, which is the value of property 'age' of bean 'testBean' -->]]>The above configuration uses a Spring FactoryBean
implementation, the PropertyPathFactoryBean, to
create a bean (of type int) called
'testBean.age' that has a value equal to the 'age'
property of the 'testBean' bean.
After...<!-- target bean to be referenced by name -->
]]><!-- will result in 10, which is the value of property 'age' of bean 'testBean' -->]]>The value of the 'path' attribute of the
<property-path/> tag follows the form 'beanName.beanProperty'.Using <util:property-path/> to set a bean property or constructor-argumentPropertyPathFactoryBean is a
FactoryBean that evaluates a property path on a given
target object. The target object can be specified directly or via a bean
name. This value may then be used in another bean definition as a property
value or constructor argument.Here's an example where a path is used against another bean, by name:
]]>// will result in 11, which is the value of property 'spouse.age' of bean 'person'
]]>In this example, a path is evaluated against an inner bean:<!-- will result in 12, which is the value of property 'age' of the inner bean -->
]]>There is also a shortcut form, where the bean name is the property path.<!-- will result in 10, which is the value of property 'age' of bean 'person' -->]]>This form does mean that there is no choice in the name of the bean.
Any reference to it will also have to use the same id, which is the path.
Of course, if used as an inner bean, there is no need to refer to it at
all:
]]>The result type may be specifically set in the actual definition.
This is not necessary for most use cases, but can be of use for some.
Please see the Javadocs for more info on this feature.<util:properties/>Before...<!-- creates a java.util.Properties instance with values loaded from the supplied location -->
]]>The above configuration uses a Spring FactoryBean
implementation, the PropertiesFactoryBean, to
instantiate a java.util.Properties instance with values loaded from
the supplied Resource location).
After...<!-- creates a java.util.Properties instance with values loaded from the supplied location -->]]><util:list/>Before...<!-- creates a java.util.List instance with values loaded from the supplied 'sourceList' -->pechorin@hero.orgraskolnikov@slums.orgstavrogin@gov.orgporfiry@gov.org
]]>The above configuration uses a Spring FactoryBean
implementation, the ListFactoryBean, to
create a java.util.List instance initialized
with values taken from the supplied 'sourceList'.
After...<!-- creates a java.util.List instance with the supplied values -->pechorin@hero.orgraskolnikov@slums.orgstavrogin@gov.orgporfiry@gov.org
]]>You can also explicitly control the exact type of List
that will be instantiated and populated via the use of the 'list-class'
attribute on the <util:list/> element. For example, if we
really need a java.util.LinkedList to be instantiated, we could
use the following configuration:jackshaftoe@vagabond.orgeliza@thinkingmanscrumpet.orgvanhoek@pirate.orgd'Arcachon@nemesis.org
]]>If no 'list-class' attribute is supplied, a
List implementation will be chosen by the container.<util:map/>Before...<!-- creates a java.util.Map instance with values loaded from the supplied 'sourceMap' -->
]]>The above configuration uses a Spring FactoryBean
implementation, the MapFactoryBean, to
create a java.util.Map instance initialized
with key-value pairs taken from the supplied 'sourceMap'.
After...<!-- creates a java.util.Map instance with the supplied key-value pairs -->
]]>You can also explicitly control the exact type of Map
that will be instantiated and populated via the use of the 'map-class'
attribute on the <util:map/> element. For example, if we
really need a java.util.TreeMap to be instantiated, we could
use the following configuration:
]]>If no 'map-class' attribute is supplied, a
Map implementation will be chosen by the container.<util:set/>Before...<!-- creates a java.util.Set instance with values loaded from the supplied 'sourceSet' -->pechorin@hero.orgraskolnikov@slums.orgstavrogin@gov.orgporfiry@gov.org
]]>The above configuration uses a Spring FactoryBean
implementation, the SetFactoryBean, to
create a java.util.Set instance initialized
with values taken from the supplied 'sourceSet'.
After...<!-- creates a java.util.Set instance with the supplied values -->pechorin@hero.orgraskolnikov@slums.orgstavrogin@gov.orgporfiry@gov.org
]]>You can also explicitly control the exact type of Set
that will be instantiated and populated via the use of the 'set-class'
attribute on the <util:set/> element. For example, if we
really need a java.util.TreeSet to be instantiated, we could
use the following configuration:pechorin@hero.orgraskolnikov@slums.orgstavrogin@gov.orgporfiry@gov.org
]]>If no 'set-class' attribute is supplied, a
Set implementation will be chosen by the container.The jee schemaThe jee tags deal with Java EE (Java Enterprise Edition)-related
configuration issues, such as looking up a JNDI object and defining EJB references.To use the tags in the jee schema, you need to have
the following preamble at the top of your Spring XML configuration file;
the text in the following snippet references the correct schema so that
the tags in the jee namespace are available to you.xmlns:jee="http://www.springframework.org/schema/jee"http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee.xsd"
]]><!-- bean definitions here -->]]><jee:jndi-lookup/> (simple)Before...
]]><!-- Spring will do the cast automatically (as usual) -->dataSource"/>]]>After...
]]><!-- Spring will do the cast automatically (as usual) -->dataSource"/>]]><jee:jndi-lookup/> (with single JNDI environment setting)Before...bar
]]>After...foo=bar
]]><jee:jndi-lookup/> (with multiple JNDI environment settings)Before...barpong
]]>After...
]]><!-- newline-separated, key-value pairs for the environment (standard Properties format) -->
foo=bar
ping=pong
]]><jee:jndi-lookup/> (complex)Before...
]]>After...]]><jee:local-slsb/> (simple)The <jee:local-slsb/> tag configures a
reference to an EJB Stateless SessionBean.Before...
]]>After...]]><jee:local-slsb/> (complex)
]]>After...]]><jee:remote-slsb/>The <jee:remote-slsb/> tag configures a
reference to a remote EJB Stateless SessionBean.Before...
]]>After...]]>The lang schemaThe lang tags deal with exposing objects that have been
written in a dynamic language such as JRuby or Groovy as beans in the Spring
container.These tags (and the dynamic language support) are comprehensively covered
in the chapter entitled . Please do consult that
chapter for full details on this support and the lang tags
themselves.In the interest of completeness, to use the tags in the lang
schema, you need to have the following preamble at the top of your Spring XML
configuration file; the text in the following snippet references the
correct schema so that the tags in the lang namespace are
available to you.xmlns:lang="http://www.springframework.org/schema/lang"http://www.springframework.org/schema/lang http://www.springframework.org/schema/lang/spring-lang.xsd"
]]><!-- bean definitions here -->]]>The jms schemaThe jms tags deal with configuring JMS-related
beans such as Spring's MessageListenerContainers.
These tags are detailed in the section of the JMS chapter
entitled . Please do consult that
chapter for full details on this support and the jms tags
themselves.In the interest of completeness, to use the tags in the jms
schema, you need to have the following preamble at the top of your Spring XML
configuration file; the text in the following snippet references the
correct schema so that the tags in the jms namespace are
available to you.xmlns:jms="http://www.springframework.org/schema/jms"http://www.springframework.org/schema/jms http://www.springframework.org/schema/jms/spring-jms.xsd"
]]><!-- bean definitions here -->]]>The tx (transaction) schemaThe tx tags deal with configuring all of those
beans 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-3.0.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 text in the following snippet references the
correct schema so that the tags in the tx namespace are
available to you.xmlns:tx="http://www.springframework.org/schema/tx"http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd
]]><!-- bean definitions here -->]]>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.The aop schemaThe aop tags deal with configuring all things
AOP in Spring: this includes Spring's own proxy-based AOP framework and Spring's
integration with the AspectJ AOP framework. 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 text in the following snippet references the
correct schema so that the tags in the aop namespace are
available to you.xmlns:aop="http://www.springframework.org/schema/aop"http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd"
]]><!-- bean definitions here -->]]>The context schemaThe context tags deal with ApplicationContext
configuration that relates to plumbing - that is, not usually beans that are important to an end-user
but rather beans that do a lot of grunt work in Spring, such as BeanfactoryPostProcessors.
The following snippet references the correct schema so that the tags in the context
namespace are available to you.xmlns:context="http://www.springframework.org/schema/context"http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd"
]]><!-- bean definitions here -->]]>The context schema was only introduced in Spring 2.5.<property-placeholder/>This element activates the replacement of ${...} placeholders, resolved
against the specified properties file (as a Spring resource location).
This element is a convenience mechanism that sets up a
PropertyPlaceholderConfigurer
for you; if you need more control over the PropertyPlaceholderConfigurer, just
define one yourself explicitly.<annotation-config/>Activates the Spring infrastructure for various annotations to be detected in bean classes:
Spring's @Required
and @Autowired, as well as
JSR 250's @PostConstruct, @PreDestroy and
@Resource (if available), and JPA's
@PersistenceContext and @PersistenceUnit
(if available). Alternatively, you can choose to activate the individual
BeanPostProcessors for those annotations explicitly.This element does not activate processing of Spring's
@Transactional
annotation. Use the
<tx:annotation-driven/> element
for that purpose.<component-scan/>This element is detailed in .<load-time-weaver/>This element is detailed in .<spring-configured/>This element is detailed in .<mbean-export/>This element is detailed in .The tool schemaThe tool tags are for use when you want to add
tooling-specific metadata to your custom configuration elements. This metadata
can then be consumed by tools that are aware of this metadata, and the tools can
then do pretty much whatever they want with it (validation, etc.).The tool tags are not documented in this release of
Spring as they are currently undergoing review. If you are a third party tool
vendor and you would like to contribute to this review process, then do mail
the Spring mailing list. The currently supported tool
tags can be found in the file 'spring-tool-3.0.xsd' in the
'src/org/springframework/beans/factory/xml' directory of the
Spring source distribution.The jdbc schemaThe jdbc tags allow you to quickly configure an
embedded database or initialize an existing data source. These tags are
documented in and
respectively.To use the tags in the jdbc
schema, you need to have the following preamble at the top of your Spring XML
configuration file; the text in the following snippet references the
correct schema so that the tags in the jdbc namespace are
available to you.xmlns:jdbc="http://www.springframework.org/schema/jdbc"http://www.springframework.org/schema/jdbc http://www.springframework.org/schema/jdbc/spring-jdbc.xsd"
]]><!-- bean definitions here -->]]>The cache schemaThe cache tags can be used to enable support for Spring's
@CacheEvict, @CachePut
and @Caching annotations. It it also supports declarative
XML-based caching. See and
for details.To use the tags in the cache
schema, you need to have the following preamble at the top of your Spring XML
configuration file; the text in the following snippet references the
correct schema so that the tags in the cache namespace are
available to you.xmlns:jdbc="http://www.springframework.org/schema/cache"http://www.springframework.org/schema/cache http://www.springframework.org/schema/jdbc/spring-cache.xsd"
]]><!-- bean definitions here -->]]>The beans schemaLast but not least we have the tags in the beans schema.
These are the same tags that have been in Spring since the very dawn of the framework.
Examples of the various tags in the beans schema are not shown here
because they are quite comprehensively covered in
(and indeed in that entire chapter).One thing that is new to the beans tags themselves in Spring 2.0 is the idea
of arbitrary bean metadata. In Spring 2.0 it is now possible to add zero or more
key / value pairs to <bean/> XML definitions. What, if
anything, is done with this extra metadata is totally up to your own custom logic (and
so is typically only of use if you are writing your own custom tags as described in
the appendix entitled ).Find below an example of the <meta/> tag in the context
of a surrounding <bean/> (please note that without any logic
to interpret it the metadata is effectively useless as-is).
]]>]]>]]>In the case of the above example, you would assume that there is some
logic that will consume the bean definition and set up some caching infrastructure
using the supplied metadata.