1.

Introduction to Spring Framework

Spring Framework is a Java platform that provides comprehensive infrastructure support for
developing Java applications. Spring handles the infrastructure so you can focus on your
application.

Spring enables you to build applications from “plain old Java objects” (POJOs) and to apply
enterprise services non-invasively to POJOs. This capability applies to the Java SE programming
model and to full and partial Java EE.

Examples of how you, as an application developer, can use the Spring platform advantage:

 Make a Java method execute in a database transaction without having to deal with
transaction APIs.
 Make a local Java method a remote procedure without having to deal with remote APIs.
 Make a local Java method a management operation without having to deal with JMX
APIs.
 Make a local Java method a message handler without having to deal with JMS APIs.

1.1 Dependency Injection and Inversion of Control

Background

“The question is, what aspect of control are [they] inverting?” Martin Fowler posed this question
about Inversion of Control (IoC) on his site in 2004. Fowler suggested renaming the principle to
make it more self-explanatory and came up with Dependency Injection.

For insight into IoC and DI, refer to Fowler's article at

http://martinfowler.com/articles/injection.html.

Java applications -- a loose term that runs the gamut from constrained applets to n-tier server-
side enterprise applications -- typically consist of objects that collaborate to form the application
proper. Thus the objects in an application have dependencies on each other.

Although the Java platform provides a wealth of application development functionality, it lacks
the means to organize the basic building blocks into a coherent whole, leaving that task to
architects and developers. True, you can use design patterns such as Factory, Abstract Factory,
Builder, Decorator, and Service Locator to compose the various classes and object instances that
make up an application. However, these patterns are simply that: best practices given a name,
with a description of what the pattern does, where to apply it, the problems it addresses, and so
forth. Patterns are formalized best practices that you must implement yourself in your application.

The Spring Framework Inversion of Control (IoC) component addresses this concern by
providing a formalized means of composing disparate components into a fully working
application ready for use. The Spring Framework codifies formalized design patterns as first-
class objects that you can integrate into your own application(s). Numerous organizations and
institutions use the Spring Framework in this manner to engineer robust, maintainable
applications.

1.2 Modules
The Spring Framework consists of features organized into about 20 modules. These modules are
grouped into Core Container, Data Access/Integration, Web, AOP (Aspect Oriented
Programming), Instrumentation, and Test, as shown in the following diagram.

Overview of the Spring Framework

1.2.1 Core Container

The Core Container consists of the Core, Beans, Context, and Expression Language modules.

The Core and Beans modules provide the fundamental parts of the framework, including the IoC
and Dependency Injection features. The BeanFactory is a sophisticated implementation of the
factory pattern. It removes the need for programmatic singletons and allows you to decouple the
configuration and specification of dependencies from your actual program logic.
The Context module builds on the solid base provided by the Core and Beans modules: it is a
means to access objects in a framework-style manner that is similar to a JNDI registry. The
Context module inherits its features from the Beans module and adds support for
internationalization (using, for example, resource bundles), event-propagation, resource-loading,
and the transparent creation of contexts by, for example, a servlet container. The Context module
also supports Java EE features such as EJB, JMX ,and basic remoting. The
ApplicationContext interface is the focal point of the Context module.

The Expression Language module provides a powerful expression language for querying and
manipulating an object graph at runtime. It is an extension of the unified expression language
(unified EL) as specified in the JSP 2.1 specification. The language supports setting and getting
property values, property assignment, method invocation, accessing the context of arrays,
collections and indexers, logical and arithmetic operators, named variables, and retrieval of
objects by name from Spring's IoC container. It also supports list projection and selection as well
as common list aggregations.

1.2.2 Data Access/Integration

The Data Access/Integration layer consists of the JDBC, ORM, OXM, JMS and Transaction
modules.

The JDBC module provides a JDBC-abstraction layer that removes the need to do tedious JDBC
coding and parsing of database-vendor specific error codes.

The ORM module provides integration layers for popular object-relational mapping APIs,
including JPA, JDO, Hibernate, and iBatis. Using the ORM package you can use all of these
O/R-mapping frameworks in combination with all of the other features Spring offers, such as the
simple declarative transaction management feature mentioned previously.

The OXM module provides an abstraction layer that supports Object/XML mapping
implementations for JAXB, Castor, XMLBeans, JiBX and XStream.

The Java Messaging Service (JMS) module contains features for producing and consuming
messages.

The Transaction module supports programmatic and declarative transaction management for
classes that implement special interfaces and for all your POJOs (plain old Java objects).

1.2.3 Web

The Web layer consists of the Web, Web-Servlet, Web-Struts, and Web-Portlet modules.

Spring's Web module provides basic web-oriented integration features such as multipart file-
upload functionality and the initialization of the IoC container using servlet listeners and a web-
oriented application context. It also contains the web-related parts of Spring's remoting support.
The Web-Servlet module contains Spring's model-view-controller (MVC) implementation for
web applications. Spring's MVC framework provides a clean separation between domain model
code and web forms, and integrates with all the other features of the Spring Framework.

The Web-Struts module contains the support classes for integrating a classic Struts web tier
within a Spring application. Note that this support is now deprecated as of Spring 3.0. Consider
migrating your application to Struts 2.0 and its Spring integration or to a Spring MVC solution.

The Web-Portlet module provides the MVC implementation to be used in a portlet environment
and mirrors the functionality of Web-Servlet module.

1.2.4 AOP and Instrumentation

Spring's AOP module provides an AOP Alliance-compliant aspect-oriented programming

implementation allowing you to define, for example, method-interceptors and pointcuts to
cleanly decouple code that implements functionality that should be separated. Using source-level
metadata functionality, you can also incorporate behavioral information into your code, in a
manner similar to that of .NET attributes.

The separate Aspects module provides integration with AspectJ.

The Instrumentation module provides class instrumentation support and classloader

implementations to be used in certain application servers.

1.2.5 Test

The Test module supports the testing of Spring components with JUnit or TestNG. It provides
consistent loading of Spring ApplicationContexts and caching of those contexts. It also provides
mock objects that you can use to test your code in isolation.

1.3 Usage scenarios

The building blocks described previously make Spring a logical choice in many scenarios, from
applets to full-fledged enterprise applications that use Spring's transaction management
functionality and web framework integration.
 Typical full-fledged Spring web application

Spring's declarative transaction management features make the web application fully
transactional, just as it would be if you used EJB container-managed transactions. All your
custom business logic can be implemented with simple POJOs and managed by Spring's IoC
container. Additional services include support for sending email and validation that is
independent of the web layer, which lets you choose where to execute validation rules. Spring's
ORM support is integrated with JPA, Hibernate, JDO and iBatis; for example, when using
Hibernate, you can continue to use your existing mapping files and standard Hibernate
SessionFactory configuration. Form controllers seamlessly integrate the web-layer with the
domain model, removing the need for ActionForms or other classes that transform HTTP
parameters to values for your domain model.
 Spring middle-tier using a third-party web framework

Sometimes circumstances do not allow you to completely switch to a different framework. The
Spring Framework does not force you to use everything within it; it is not an all-or-nothing
solution. Existing front-ends built with WebWork, Struts, Tapestry, or other UI frameworks can
be integrated with a Spring-based middle-tier, which allows you to use Spring transaction
features. You simply need to wire up your business logic using an ApplicationContext and use
a WebApplicationContext to integrate your web layer.
 Remoting usage scenario

When you need to access existing code through web services, you can use Spring's Hessian-,
Burlap-, Rmi- or JaxRpcProxyFactory classes. Enabling remote access to existing applications
is not difficult.
 EJBs - Wrapping existing POJOs

The Spring Framework also provides an access and abstraction layer for Enterprise JavaBeans,
enabling you to reuse your existing POJOs and wrap them in stateless session beans for use in
scalable, fail-safe web applications that might need declarative security.

1.3.1 Dependency Management and Naming Conventions

Dependency management and dependency injection are different things. To get those nice
features of Spring into your application (like dependency injection) you need to assemble all the
libraries needed (jar files) and get them onto your classpath at runtime, and possibly at compile
time. These dependencies are not virtual components that are injected, but physical resources in a
file system (typically). The process of dependency management involves locating those
resources, storing them and adding them to classpaths. Dependencies can be direct (e.g. my
application depends on Spring at runtime), or indirect (e.g. my application depends on commons-
dbcp which depends on commons-pool). The indirect dependencies are also known as
"transitive" and it is those dependencies that are hardest to identify and manage.

If you are going to use Spring you need to get a copy of the jar libraries that comprise the pieces
of Spring that you need. To make this easier Spring is packaged as a set of modules that separate
the dependencies as much as possible, so for example if you don't want to write a web
application you don't need the spring-web modules. To refer to Spring library modules in this
guide we use a shorthand naming convention spring-* or spring-*.jar, where "*" represents
the short name for the module (e.g. spring-core, spring-webmvc, spring-jms, etc.). The
actual jar file name that you use may be in this form (see below) or it may not, and normally it
also has a version number in the file name (e.g. spring-core-3.0.0.RELEASE.jar).

In general, Spring publishes its artifacts to four different places:

 On the community download site http://www.springsource.org/downloads/community.

Here you find all the Spring jars bundled together into a zip file for easy download. The
names of the jars here since version 3.0 are in the form org.springframework.*-
<version>.jar.
 Maven Central, which is the default repository that Maven queries, and does not require
any special configuration to use. Many of the common libraries that Spring depends on
also are available from Maven Central and a large section of the Spring community uses
Maven for dependency management, so this is convenient for them. The names of the jars
here are in the form spring-*-<version>.jar and the Maven groupId is
org.springframework.
 The Enterprise Bundle Repository (EBR), which is run by SpringSource and also hosts
all the libraries that integrate with Spring. Both Maven and Ivy repositories are available
here for all Spring jars and their dependencies, plus a large number of other common
libraries that people use in applications with Spring. Both full releases and also
milestones and development snapshots are deployed here. The names of the jar files are
in the same form as the community download (org.springframework.*-
<version>.jar), and the dependencies are also in this "long" form, with external
libraries (not from SpringSource) having the prefix com.springsource. See the FAQ for
more information.
 In a public Maven repository hosted on Amazon S3 for development snapshots and
milestone releases (a copy of the final releases is also held here). The jar file names are in
the same form as Maven Central, so this is a useful place to get development versions of
Spring to use with other libraries depoyed in Maven Central.

So the first thing you need to decide is how to manage your dependencies: most people use an
automated system like Maven or Ivy, but you can also do it manually by downloading all the jars
yourself. When obtaining Spring with Maven or Ivy you have then to decide which place you'll
get it from. In general, if you care about OSGi, use the EBR, since it houses OSGi compatible
artifacts for all of Spring's dependencies, such as Hibernate and Freemarker. If OSGi does not
matter to you, either place works, though there are some pros and cons between them. In general,
pick one place or the other for your project; do not mix them. This is particularly important since
EBR artifacts necessarily use a different naming convention than Maven Central artifacts.

Table 1.1. Comparison of Maven Central and SpringSource EBR Repositories

Feature Maven Central EBR

OSGi
Not explicit Yes
Compatible
Number of Tens of thousands; all
Hundreds; those that Spring integrates with
Artifacts kinds
Consistent No Yes
 Feature Maven Central EBR
Naming
Conventions
Varies. Newer artifacts
Naming often use domain name,
Domain name of origin or main package root, e.g.
Convention: e.g. org.slf4j. Older ones
org.springframework
GroupId often just use the artifact
name, e.g. log4j.
Varies. Generally the Bundle Symbolic Name, derived from the main
Naming project or module name, package root, e.g. org.springframework.beans. If the
Convention: using a hyphen "-" jar had to be patched to ensure OSGi compliance then
ArtifactId separator, e.g. spring- com.springsource is appended, e.g.
core, logj4. com.springsource.org.apache.log4j
Varies. Many new
artifacts use m.m.m or
m.m.m.X (with m=digit,
Naming OSGi version number m.m.m.X, e.g. 3.0.0.RC3. The
X=text). Older ones use
Convention: text qualifier imposes alphabetic ordering on versions
m.m. Some neither.
Version with the same numeric values.
Ordering is defined but
not often relied on, so not
strictly reliable.
Usually automatic via
rsync or source control
Publishing updates. Project authors Manual (JIRA processed by SpringSource)
can upload individual jars
to JIRA.
Quality By policy. Accuracy is Extensive for OSGi manifest, Maven POM and Ivy
Assurance responsibility of authors. metadata. QA performed by Spring team.
Contegix. Funded by
Hosting Sonatype with several S3 funded by SpringSource.
mirrors.
Search
Various http://www.springsource.com/repository
Utilities
Integration
Integration through STS
with Extensive integration through STS with Maven, Roo,
with Maven dependency
SpringSource CloudFoundry
management
Tools