Spring Source Framework
One of the areas that contains a considerable number of 2.0 and 2.5 improvements is Spring's IoC container.
Previous versions of Spring had IoC container level support for exactly two distinct bean scopes (singleton and prototype). Spring 2.0 improves on this by not only providing a number of additional scopes depending on the environment in which Spring is being deployed (for example, request and session scoped beans in a web environment), but also by providing integration points so that Spring users can create their own scopes.
It should be noted that although the underlying (and internal) implementation for singleton- and prototype-scoped beans has been changed, this change is totally transparent to the end user... no existing configuration needs to change, and no existing configuration will break.
Both the new and the original scopes are detailed in the section entitled Section 3.4, “Bean scopes”.
Spring XML configuration is now even easier, thanks to the advent of the new XML configuration syntax based on XML Schema. If you want to take advantage of the new tags that Spring provides (and the Spring team certainly suggest that you do because they make configuration less verbose and easier to read), then do read the section entitled Appendix A, XML Schema-based configuration.
On a related note, there is a new, updated DTD for Spring 2.0 that you may wish to reference if you cannot take advantage of the XML Schema-based configuration. The DOCTYPE declaration is included below for your convenience, but the interested reader should definitely read the 'spring-beans-2.0.dtd' DTD included in the 'dist/resources' directory of the Spring 2.5 distribution.
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN"
"http://www.springframework.org/dtd/spring-beans-2.0.dtd">
Not only is XML configuration easier to write, it is now also extensible.
What 'extensible' means in this context is that you, as an application developer, or (more likely) as a third party framework or product vendor, can write custom tags that other developers can then plug into their own Spring configuration files. This allows you to have your own domain specific language (the term is used loosely here) of sorts be reflected in the specific configuration of your own components.
Implementing custom Spring tags may not be of interest to every single application developer or enterprise architect using Spring in their own projects. We expect third-party vendors to be highly interested in developing custom configuration tags for use in Spring configuration files.
The extensible configuration mechanism is documented in Appendix B, Extensible XML authoring.
Spring 2.0 introduced support for various annotations for configuration purposes, such as @Transactional, @Required and @PersistenceContext /@PersistenceUnit.
Spring 2.5 introduces support for a complete set of configuration annotations: @Autowired in combination with support for the JSR-250 annotations @Resource, @PostConstruct and @PreDestroy .
Annotation-driven bean configuration is discussed in Section 3.11, “Annotation-based configuration”. Check out annotation support for Spring MVC as well: Section 2.5.3, “Annotation-based controllers”
Spring 2.5 introduces support component scanning: autodetecting annotated components in the classpath. Typically, such component classes will be annotated with stereotypes such as @Component, @Repository, @Service, @Controller. Depending on the application context configuration, such component classes will be autodetected and turned into Spring bean definitions, not requiring explicit configuration for each such bean.
Annotation-driven bean configuration is discussed in Section 3.12.1, “@Component and further stereotype annotations”.
Spring 2.0 has a much improved AOP offering. The Spring AOP framework itself is markedly easier to configure in XML, and significantly less verbose as a result; and Spring 2.0 integrates with the AspectJ pointcut language and @AspectJ aspect declaration style. The chapter entitled Chapter 6, Aspect Oriented Programming with Spring is dedicated to describing this new support.
Spring 2.0 introduces new schema support for defining aspects backed by regular Java objects. This support takes advantage of the AspectJ pointcut language and offers fully typed advice (i.e. no more casting and Object[] argument manipulation). Details of this support can be found in the section entitled Section 6.3, “Schema-based AOP support”.
Spring 2.0 also supports aspects defined using the @AspectJ annotations. These aspects can be shared between AspectJ and Spring AOP, and require (honestly!) only some simple configuration. Said support for @AspectJ aspects is discussed in Section 6.2, “@AspectJ support”.
Spring 2.5 introduces support for the bean(...) pointcut element, matching specific named beans according to Spring-defined bean names. See Section 6.2.3.1, “Supported Pointcut Designators” for details.
Spring 2.5 introduces explicit support AspectJ load-time weaving, as alternative to the proxy-based AOP framework. The new context:load-time-weaver configuration element automatically activates AspectJ aspects as defined in AspectJ's META-INF/aop.xml descriptor, applying them to the current application context through registering a transformer with the underlying ClassLoader. Note that this only works in environments with class transformation support. Check out Section 6.8.4, “Load-time weaving with AspectJ in the Spring Framework” for the capabilities and limitations.
The way that transactions are configured in Spring 2.0 has been changed significantly. The previous 1.2.x style of configuration continues to be valid (and supported), but the new style is markedly less verbose and is the recommended style. Spring 2.0 also ships with an AspectJ aspects library that you can use to make pretty much any object transactional - even objects not created by the Spring IoC container.
Spring 2.5 supports convenient annotation-driven transaction management in combination with load-time weaving, through the use of context:load-time-weaver in combination with tx:annotation-driven mode="aspectj".
The chapter entitled Chapter 9, Transaction management contains all of the details.
Spring 2.5 explicitly supports IBM's WebSphere Application Server, in particular with respect to WebSphere's transaction manager. Transaction suspension is now fully supported through the use of WebSphere's new UOWManager API, which is available on WAS 6.0.2.19+ and 6.0.1.9+.
So if you run a Spring-based application on the WebSphere Application Server, we highly recommend to use Spring 2.5's WebSphereUowTransactionManager as your PlatformTransactionManager of choice. This is also IBM's official recommendation.
For automatic detection of the underlying JTA-based transaction platform, consider the use of Spring 2.5's new tx:jta-transaction-manager configuration element. This will autodetect BEA WebLogic and IBM WebSphere, registering the appropriate PlatformTransactionManager.
Spring 2.0 ships with a JPA abstraction layer that is similar in intent to Spring's JDBC abstraction layer in terms of scope and general usage patterns.
If you are interested in using a JPA-implementation as the backbone of your persistence layer, the section entitled Section 12.6, “JPA” is dedicated to detailing Spring's support and value-add in this area.
Spring 2.5 upgrades its OpenJPA support to OpenJPA 1.0, with support for advanced features such as savepoints.
Prior to Spring 2.0, Spring's JMS offering was limited to sending messages and the synchronous receiving of messages. This functionality (encapsulated in the JmsTemplate class) is great, but it doesn't address the requirement for the asynchronous receiving of messages.
Spring 2.0 now ships with full support for the reception of messages in an asynchronous fashion, as detailed in the section entitled Section 19.4.2, “Asynchronous Reception - Message-Driven POJOs”.
As of Spring 2.5, the JCA style of setting up asynchronous message listeners is supported as well, through the GenericMessageEndpointManager facility. This is an alternative to the standard JMS listener facility, allowing closer integration with message brokers such as ActiveMQ and JORAM. See Section 19.5, “Support for JCA Message Endpoints”.
Spring 2.5 also introduces an XML namespace for simplifying JMS configuration, offering concise configuration of a large numbers of listeners. This namespace supports both the standard JMS listener facility as well as the JCA setup style, with minimal changes in the configuration. See Section 19.6, “JMS Namespace Support”.
There are some small (but nevertheless notable) new classes in the Spring Framework's JDBC support library. The first, NamedParameterJdbcTemplate, provides support for programming JDBC statements using named parameters (as opposed to programming JDBC statements using only classic placeholder ('?') arguments.
Another of the new classes, the SimpleJdbcTemplate, is aimed at making using the JdbcTemplate even easier to use when you are developing against Java 5+ (Tiger).
Spring 2.5 significantly extends the functionality of SimpleJdbcTemplate and introduces SimpleJdbcCall and SimpleJdbcInsert operation objects.
The web tier support has been substantially improved and expanded in Spring 2.0, with annotation-based controllers introduced in Spring 2.5.
For a lot of projects, sticking to established conventions and having reasonable defaults is just what the projects need... this theme of convention-over-configuration now has explicit support in Spring MVC. What this means is that if you establish a set of naming conventions for your Controllers and views, you can substantially cut down on the amount of XML configuration that is required to setup handler mappings, view resolvers, ModelAndView instances, etc. This is a great boon with regards to rapid prototyping, and can also lend a degree of (always good-to-have) consistency across a codebase.
Spring MVC's convention-over-configuration support is detailed in the section entitled Section 13.10, “Convention over configuration”
Spring 2.0 ships with a Portlet framework that is conceptually similar to the Spring MVC framework. Detailed coverage of the Spring Portlet framework can be found in the section entitled Chapter 16, Portlet MVC Framework.
Spring 2.5 introduces an annotation-based programming model for MVC controllers, using annotations such as @RequestMapping, @RequestParam, @ModelAttribute, etc. This annotation support is available for both Servlet MVC and Portlet MVC. Controllers implemented in this style do not have to extend specific base classes or implement specific interfaces. Furthermore, they do not usually have direct dependencies on Servlet or Portlet API's, although they can easily get access to Servlet or Portlet facilities if desired. For further details, see Section 13.11, “Annotation-based controller configuration”.
A rich JSP tag library for Spring MVC was the JIRA issue that garnered the most votes from Spring users (by a wide margin).
Spring 2.0 ships with a full featured JSP tag library that makes the job of authoring JSP pages much easier when using Spring MVC; the Spring team is confident it will satisfy all of those developers who voted for the issue on JIRA. The new tag library is itself covered in the section entitled Section 14.2.4, “Using Spring's form tag library”, and a quick reference to all of the new tags can be found in the appendix entitled Appendix E, spring-form.tld.
Spring 2.5 ships support for Tiles 2, the next generation of the popular Tiles templating framework. This supersedes Spring's former support for Tiles 1, as included in Struts 1.x. See Section 14.3, “Tiles” for details.
Spring 2.5 supports JSF 1.2, providing a JSF 1.2 variant of Spring's DelegatingVariableResolver in the form of the new SpringBeanFacesELResolver.
Spring 2.5 fully supports JAX-WS 2.0/2.1, as included in Java 6 and Java EE 5. JAX-WS is the successor of JAX-RPC, allowing access to WSDL/SOAP-based web services as well as JAX-WS style exposure of web services.
This final section outlines all of the other new and improved Spring 2.0/2.5 features and functionality.
Spring 2.0 introduced support for beans written in languages other than Java, with the currently supported dynamic languages being JRuby, Groovy and BeanShell. This dynamic language support is comprehensively detailed in the section entitled Chapter 24, Dynamic language support.
Spring 2.5 refines the dynamic languages support with autowiring and support for the recently released JRuby 1.0.
Spring 2.5 introduces the Spring TestContext Framework which provides annotation-driven unit and integration testing support that is agnostic of the actual testing framework in use. The same techniques and annotation-based configuration used in, for example, a JUnit 3.8 environment can also be applied to tests written with JUnit 4.4, TestNG, etc.
In addition to providing generic and extensible testing infrastructure, the Spring TestContext Framework provides out-of-the-box support for Spring-specific integration testing functionality such as context management and caching, dependency injection of test fixtures, and transactional test management with default rollback semantics.
To discover how this new testing support can assist you with writing unit and integration tests, consult Section 8.3.7, “Spring TestContext Framework” of the revised testing chapter.
The Spring Framework 2.0 has support for Notifications; it is also possible to exercise declarative control over the registration behavior of MBeans with an MBeanServer.
Section 20.7, “Notifications”
Section 20.2.5, “Controlling the registration behavior”
Furthermore, Spring 2.5 provides a context:mbean-export configuration element for convenient registration of annotated bean classes, detecting Spring's @ManagedResource annotation.
Spring 2.5 supports the deployment of a Spring application context as JCA resource adapter, packaged as a JCA RAR file. This allows headless application modules to be deployed into J2EE servers, getting access to all the server's infrastructure e.g. for executing scheduled tasks, listening for incoming messages, etc.
Spring 2.0 offers an abstraction around the scheduling of tasks. For the interested developer, the section entitled Section 23.4, “The Spring TaskExecutor abstraction” contains all of the details.
The TaskExecutor abstraction is used throughout the framework itself as well, e.g. for the asynchronous JMS support. In Spring 2.5, it is also used in the JCA environment support.
Find below pointers to documentation describing some of the new Java 5 support in Spring 2.0 and 2.5.
Section 3.11, “Annotation-based configuration”
Section 25.3.1, “@Required”
Section 9.5.6, “Using @Transactional”
Section 11.2.3, “SimpleJdbcTemplate”
Section 12.6, “JPA”
Section 6.2, “@AspectJ support”
Section 6.8.1, “Using AspectJ to dependency inject domain objects with Spring”
Table 3.4. Bean scopes
Scope | Description |
Scopes a single bean definition to a single object instance per Spring IoC container. | |
Scopes a single bean definition to any number of object instances. | |
Scopes a single bean definition to the lifecycle of a single HTTP request; that is each and every HTTP request will have its own instance of a bean created off the back of a single bean definition. Only valid in the context of a web-aware Spring ApplicationContext. | |
Scopes a single bean definition to the lifecycle of a HTTP Session. Only valid in the context of a web-aware Spring ApplicationContext. | |
Scopes a single bean definition to the lifecycle of a global HTTP Session. Typically only valid when used in a portlet context. Only valid in the context of a web-aware Spring ApplicationContext. |
Table 3.6. Built-in Events
Event | Explanation |
ContextRefreshedEvent | Published when the ApplicationContext is initialized or refreshed, e.g. using the refresh() method on the ConfigurableApplicationContext interface. "Initialized" here means that all beans are loaded, post-processor beans are detected and activated, singletons are pre-instantiated, and the ApplicationContext object is ready for use. A refresh may be triggered multiple times, as long as the context hasn't been closed - provided that the chosen ApplicationContext actually supports such "hot" refreshes (which e.g. XmlWebApplicationContext does but GenericApplicationContext doesn't). |
ContextStartedEvent | Published when the ApplicationContext is started, using the start() method on the ConfigurableApplicationContext interface. "Started" here means that all Lifecycle beans will receive an explicit start signal. This will typically be used for restarting after an explicit stop, but may also be used for starting components that haven't been configured for autostart (e.g. haven't started on initialization already). |
ContextStoppedEvent | Published when the ApplicationContext is stopped, using the stop() method on the ConfigurableApplicationContext interface. "Stopped" here means that all Lifecycle beans will receive an explicit stop signal. A stopped context may be restarted through a start() call. |
ContextClosedEvent | Published when the ApplicationContext is closed, using the close() method on the ConfigurableApplicationContext interface. "Closed" here means that all singleton beans are destroyed. A closed context has reached its end of life; it cannot be refreshed or restarted. |
RequestHandledEvent | A web-specific event telling all beans that an HTTP request has been serviced (this will be published after the request has been finished). Note that this event is only applicable for web applications using Spring's DispatcherServlet. |
Table 3.7. Filter Types
Filter Type | Example Expression | Description |
annotation | org.example.SomeAnnotation | An annotation to be present at the type level in target components. |
assignable | org.example.SomeClass | A class (or interface) that the target components are assignable to (extend/implement). |
aspectj | org.example..*Service+ | An AspectJ type expression to be matched by the target components. |
regex | org\.example\.Default.* | A regex expression to be matched by the target components' class names. |
custom | org.example.MyCustomTypeFilter | A custom implementation of the org.springframework.core.type.TypeFilter interface. |
Table 4.1. Resource strings
Prefix | Example | Explanation |
classpath: | classpath:com/myapp/config.xml | Loaded from the classpath. |
file: | file:/data/config.xml | Loaded as a URL, from the filesystem. [a] |
http: | http://myserver/logo.png | Loaded as a URL. |
(none) | /data/config.xml | Depends on the underlying ApplicationContext. |
[a] But see also the section entitled Section 4.7.3, “FileSystemResource caveats”. | ||
Table 5.1. Examples of properties
Expression | Explanation |
name | Indicates the property name corresponding to the methods getName() or isName() and setName(..) |
account.name | Indicates the nested property name of the property account corresponding e.g. to the methods getAccount().setName() or getAccount().getName() |
account[2] | Indicates the third element of the indexed property account. Indexed properties can be of type array, list or other naturally ordered collection |
account[COMPANYNAME] | Indicates the value of the map entry indexed by the key COMPANYNAME of the Map property account |
Table 5.2. Built-in PropertyEditors
Class | Explanation |
ByteArrayPropertyEditor | Editor for byte arrays. Strings will simply be converted to their corresponding byte representations. Registered by default by BeanWrapperImpl. |
ClassEditor | Parses Strings representing classes to actual classes and the other way around. When a class is not found, an IllegalArgumentException is thrown. Registered by default by BeanWrapperImpl. |
CustomBooleanEditor | Customizable property editor for Boolean properties. Registered by default by BeanWrapperImpl, but, can be overridden by registering custom instance of it as custom editor. |
CustomCollectionEditor | Property editor for Collections, converting any source Collection to a given target Collection type. |
CustomDateEditor | Customizable property editor for java.util.Date, supporting a custom DateFormat. NOT registered by default. Must be user registered as needed with appropriate format. |
CustomNumberEditor | Customizable property editor for any Number subclass like Integer, Long, Float, Double. Registered by default by BeanWrapperImpl, but can be overridden by registering custom instance of it as a custom editor. |
FileEditor | Capable of resolving Strings to java.io.File objects. Registered by default by BeanWrapperImpl. |
InputStreamEditor | One-way property editor, capable of taking a text string and producing (via an intermediate ResourceEditor and Resource) an InputStream, so InputStream properties may be directly set as Strings. Note that the default usage will not close the InputStream for you! Registered by default by BeanWrapperImpl. |
LocaleEditor | Capable of resolving Strings to Locale objects and vice versa (the String format is [language]_[country]_[variant], which is the same thing the toString() method of Locale provides). Registered by default by BeanWrapperImpl. |
PatternEditor | Capable of resolving Strings to JDK 1.5 Pattern objects and vice versa. |
PropertiesEditor | Capable of converting Strings (formatted using the format as defined in the Javadoc for the java.lang.Properties class) to Properties objects. Registered by default by BeanWrapperImpl. |
StringTrimmerEditor | Property editor that trims Strings. Optionally allows transforming an empty string into a null value. NOT registered by default; must be user registered as needed. |
URLEditor | Capable of resolving a String representation of a URL to an actual URL object. Registered by default by BeanWrapperImpl. |
public class ExampleBean {
private AnotherBean beanOne;
private YetAnotherBean beanTwo;
private int i;
public void setBeanOne(AnotherBean beanOne) {
this.beanOne = beanOne;
}
public void setBeanTwo(YetAnotherBean beanTwo) {
this.beanTwo = beanTwo;
}
public void setIntegerProperty(int i) {
this.i = i;
}
}
<beans xmlns="http://www.springframework.org/schema/beans"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
<bean id="exampleBean" class="examples.ExampleBean">
<!-- setter injection using the nested <ref/> element -->
<property name="beanOne">
<ref bean="anotherExampleBean" />
</property>
<!-- setter injection using the neater 'ref' attribute -->
<property name="beanTwo" ref="yetAnotherBean" />
<property name="integerProperty" value="1" />
</bean>
<bean id="anotherExampleBean" class="examples.AnotherBean" />
<bean id="yetAnotherBean" class="examples.YetAnotherBean" />
</beans>
public class StandaloneImageTool {
public static final String CONTEXT_CONFIG_LOCATION = "WEB-INF/applicationContext.xml";
private final ImageDatabase imageDatabase;
public StandaloneImageTool(ImageDatabase imageDatabase) {
this.imageDatabase = imageDatabase;
}
public void listImages(int nrOfCalls) throws IOException {
List images = this.imageDatabase.getImages();
StopWatch stopWatch = new StopWatch();
for (Iterator it = images.iterator(); it.hasNext();) {
ImageDescriptor image = (ImageDescriptor) it.next();
stopWatch.start(image.getName());
ByteArrayOutputStream os = null;
for (int i = 0; i < nrOfCalls; i++) {
os = new ByteArrayOutputStream();
this.imageDatabase.streamImage(image.getName(), os);
}
stopWatch.stop();
System.out.println("Found image '" + image.getName() + "' with content size " + os.size() +
" and description length " + image.getDescriptionLength());
}
System.out.println(stopWatch.prettyPrint());
}
public static void main(String[] args) throws IOException {
int nrOfCalls = 1;
if (args.length > 1 && !"".equals(args[1])) {
nrOfCalls = Integer.parseInt(args[1]);
}
ApplicationContext context = new FileSystemXmlApplicationContext(CONTEXT_CONFIG_LOCATION);
ImageDatabase idb = (ImageDatabase) context.getBean("imageDatabase");
StandaloneImageTool tool = new StandaloneImageTool(idb);
tool.listImages(nrOfCalls);
}
}
applicationcontext.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
- Middle tier application context definition for the image database.
-->
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd">
<!-- Configurer that replaces ${...} placeholders with values from a properties file -->
<!-- (in this case, JDBC-related settings for the dataSource definition below) -->
<context:property-placeholder location="WEB-INF/jdbc.properties,WEB-INF/mail.properties"/>
<!-- Local C3P0 DataSource that works in any environment -->
<!-- See JPetStore for an example of using Apache Commons DBCP as alternative -->
<!-- (Both DataSource implementations have a "close" method to be called on shutdown) -->
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
<property name="driverClass" value="${jdbc.driverClassName}"/>
<property name="jdbcUrl" value="${jdbc.url}"/>
<property name="user" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
</bean>
<!-- Transaction manager for a single JDBC DataSource -->
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource"/>
</bean>
<!-- Activates @Transactional for DefaultImageDatabase -->
<tx:annotation-driven transaction-manager="transactionManager"/>
<!-- Default implementation of the ImageDatabase business interface -->
<!-- (refers to a LobHandler for handling BLOBs and CLOBs -->
<bean id="imageDatabase" class="org.springframework.samples.imagedb.DefaultImageDatabase">
<property name="dataSource" ref="dataSource"/>
<property name="lobHandler" ref="${imageDatabase.lobHandler}"/>
</bean>
<!-- MailSender implementation for JavaMail -->
<!-- Used by ListImagesQuartzJob and ListImagesTimerTask; see "scheduling-*.xml" -->
<bean id="mailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
<property name="host" value="${mail.host}"/>
</bean>
<!-- LobHandler for well-behaved JDBC drivers -->
<!-- (simply delegating to corresponding PreparedStatement and ResultSet methods) -->
<bean id="defaultLobHandler" class="org.springframework.jdbc.support.lob.DefaultLobHandler" lazy-init="true"/>
<!-- LobHandler for Oracle JDBC drivers -->
<!-- (refers to the NativeJdbcExtractor above to get access to native OracleConnections) -->
<bean id="oracleLobHandler" class="org.springframework.jdbc.support.lob.OracleLobHandler" lazy-init="true">
<property name="nativeJdbcExtractor" ref="nativeJdbcExtractor"/>
</bean>
<!-- NativeJdbcExtractor for the C3P0 connection pool above -->
<!-- (just needed for oracleLobHandler) -->
<bean id="nativeJdbcExtractor" class="org.springframework.jdbc.support.nativejdbc.C3P0NativeJdbcExtractor"
lazy-init="true"/>
</beans>
web.xml
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/applicationContext.xml /WEB-INF/schedulingContext-quartz.xml
</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<!--
- Spring web MVC servlet that dispatches request to registered handlers.
- Has its own application context, by default defined in "{servlet-name}-servlet.xml",
- i.e. "image-servlet.xml" in this case.
-
- A web app can contain any number of such servlets.
- Note that this web app has a shared root application context, serving as parent
- of all DispatcherServlet contexts.
-->
<servlet>
<servlet-name>image</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>2</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>image</servlet-name>
<url-pattern>/image/*</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
</web-app>