diff --git a/spring-framework-reference/src/aop.xml b/spring-framework-reference/src/aop.xml
index 7dcace3496..5b6c53e2cb 100644
--- a/spring-framework-reference/src/aop.xml
+++ b/spring-framework-reference/src/aop.xml
@@ -3115,7 +3115,7 @@ public class Account {
without making any modifications to the application server's
launch script that will be needed to add
-javaagent:path/to/aspectjweaver.jar or (as we describe later in this
- section) -javaagent:path/to/org.springframework.instrument.jar (previously named
+ section) -javaagent:path/to/spring-instrument.jar (previously named
spring-agent.jar). Developers simply modify
one or more files that form the application context to enable load-time
weaving instead of relying on administrators who typically are in charge
@@ -3258,7 +3258,7 @@ public final class Main {
(supplied with Spring) to switch on the LTW. This is the command line
we will use to run the above Main class:
- java -javaagent:C:/projects/foo/lib/global/org.springframework.instrument.jar foo.Main
+ java -javaagent:C:/projects/foo/lib/global/spring-instrument.jar foo.MainThe '-javaagent' is a Java 5+ flag for
specifying and enabling . The Spring
Framework ships with such an agent, the
InstrumentationSavingAgent, which is packaged
- in the org.springframework.instrument.jar (previously
- named spring-agent.jar) that
+ in the spring-instrument.jar
+ that
was supplied as the value of the -javaagent
argument in the above example.
@@ -3368,8 +3368,8 @@ public final class Main {
- spring.jar (version
- 2.5 or later)
+ spring-aop.jar (version
+ 2.5 or later, plus all mandatory dependencies)
@@ -3390,8 +3390,7 @@ public final class Main {
org.springframework.instrument.jar (previously named
- spring-agent.jar)
+ class="libraryfile">spring-instrument.jar
@@ -3509,7 +3508,7 @@ http://www.springframework.org/schema/context
JVM started with Spring
InstrumentationSavingAgent(java
- -javaagent:path/to/org.springframework.instrument.jar)
+ -javaagent:path/to/spring-instrument.jar)
InstrumentationLoadTimeWeaver
@@ -3623,8 +3622,7 @@ http://www.springframework.org/schema/context
(standalone as well as application server based) through the use of
the Spring-provided instrumentation agent. To do so, start
the VM by by specifying the
- -javaagent:path/to/org.springframework.instrument.jar option
- (the jar was previously named spring-agent.jar).
+ -javaagent:path/to/spring-instrument.jar option.
Note that this requires modification of the VM launch script
which may prevent you from using this in application server
environments (depending on your operation policies).
@@ -3639,8 +3637,7 @@ http://www.springframework.org/schema/context
looks as follows, to be included either in Tomcat's central
server.xml file or in an application-specific
META-INF/context.xml file within the WAR root.
- Spring's org.springframework.instrument.tomcat.jar
- (previously named spring-tomcat-weaver.jar) needs to be
+ Spring's spring-instrument-tomcat.jar needs to be
included in Tomcat's common lib directory in order to make this
setup work.
@@ -3677,7 +3674,7 @@ http://www.springframework.org/schema/context
You can enable LTW by simply activating context:load-time-weaver
as described earlier. Specifically, you do not
need to modify the launch script to add
- -javaagent:path/to/org.springframework.instrument.jar.
+ -javaagent:path/to/spring-instrument.jar.
GlassFish provides an instrumentation-capable ClassLoader as well,
but only in its EAR environment. For GlassFish web applications,
diff --git a/spring-framework-reference/src/overview.xml b/spring-framework-reference/src/overview.xml
index 231f33d3d1..5c16eafd2c 100644
--- a/spring-framework-reference/src/overview.xml
+++ b/spring-framework-reference/src/overview.xml
@@ -74,9 +74,9 @@
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
+ 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). Nu
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-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
@@ -346,10 +345,565 @@ TR: OK. Added to diagram.-->
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
+ 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.
+
+
+ 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 shot 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.
+
+
+
+ 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.
+
+
+ Comparison of Maven Central and SpringSource EBR
+ Repositories
+
+
+
+
+ Feature
+
+ Maven Central
+
+ EBR
+
+
+
+
+
+ OSGi Compatible
+
+ Not explicit
+
+ Yes
+
+
+
+ Number of Artifacts
+
+ Tens of thousands; all kinds
+
+ Hundreds; those that Spring integrates with
+
+
+
+ Consistent Naming Conventions
+
+ No
+
+ Yes
+
+
+
+ Naming Convention: GroupId
+
+ Varies. Newer artifacts often use domain name, e.g.
+ org.slf4j. Older ones often just use the artifact name, e.g.
+ log4j.
+
+ Domain name of origin or main package root, e.g.
+ org.springframework
+
+
+
+ Naming Convention: ArtifactId
+
+ Varies. Generally the project or module name, using a
+ hyphen "-" separator, e.g. spring-core, logj4.
+
+ Bundle Symbolic Name, derived from the main package
+ root, e.g. org.springframework.beans. If the jar had to be
+ patched to ensure OSGi compliance then com.springsource is
+ appended, e.g. com.springsource.org.apache.log4j
+
+
+
+ Naming Convention: Version
+
+ Varies. Many new artifacts use m.m.m or m.m.m.X (with
+ m=digit, X=text). Older ones use m.m. Some neither. Ordering
+ is defined but not often relied on, so not strictly
+ reliable.
+
+ OSGi version number m.m.m.X, e.g. 3.0.0.RC3. The text
+ qualifier imposes alphabetic ordering on versions with the
+ same numeric values.
+
+
+
+ Publishing
+
+ Usually automatic via rsync or source control updates.
+ Project authors can upload individual jars to JIRA.
+
+ Manual (JIRA processed by SpringSource)
+
+
+
+ Quality Assurance
+
+ By policy. Accuracy is responsibility of
+ authors.
+
+ Extensive for OSGi manifest, Maven POM and Ivy
+ metadata. QA performed by Spring team.
+
+
+
+ Hosting
+
+ Contegix. Funded by Sonatype with several
+ mirrors.
+
+ S3 funded by SpringSource.
+
+
+
+ Search Utilities
+
+ Various
+
+ http://www.springsource.com/repository
+
+
+
+ Integration with SpringSource Tools
+
+ Integration through STS with Maven dependency
+ management
+
+ Extensive integration through STS with Maven, Roo,
+ CloudFoundry
+
+
+
+
+
+
+ Spring Dependencies and Depending on Spring
+
+ Although Spring provides integration and support for a huge
+ range of enterprise and other external tools, it intentionally keeps
+ its mandatory dependencies to an absolute minimum: you shouldn't have
+ to locate and download (even automatically) a large number of jar
+ libraries in order to use Spring for simple use cases. For basic
+ dependency injection there is only one mandatory external dependency,
+ and that is for logging (see below for a more detailed description of
+ logging options). If you are using Maven for dependency management you
+ don't even need to supply the logging dependency explicitly. For
+ example, to create an application context and use dependency injection
+ to configure an application, your Maven dependencies will look like
+ this:
+
+ <dependencies>
+ <dependency>
+ <groupId>org.springframework</groupId>
+ <artifactId>spring-context</artifactId>
+ <version>3.0.0.RELEASE</version>
+ <scope>runtime</scope>
+ </dependency>
+</dependencies>
+
+ That's it. Note the scope can be declared as runtime if you
+ don't need to compile against Spring APIs, which is typically the case
+ for basic dependency injection use cases.
+
+ We used the Maven Central naming conventions in the example
+ above, so that works with Maven Central or the SpringSource S3 Maven
+ repository. To use the S3 Maven repository (e.g. for milestones or
+ developer snaphots), you need to specify the repository location in
+ your Maven configuration. For full releases:
+
+ <repositories>
+ <repository>
+ <id>com.springsource.repository.maven.release</id>
+ <url>http://s3.amazonaws.com/maven.springsource.com/release/</url>
+ <snapshots><enabled>false</enabled></snapshots>
+ </repository>
+</repositories>
+
+ For milestones:
+
+ <repositories>
+ <repository>
+ <id>com.springsource.repository.maven.milestone</id>
+ <url>http://s3.amazonaws.com/maven.springsource.com/milestone/</url>
+ <snapshots><enabled>false</enabled></snapshots>
+ </repository>
+</repositories>
+
+ And for snapshots:
+
+ <repositories>
+ <repository>
+ <id>com.springsource.repository.maven.snapshot</id>
+ <url>http://s3.amazonaws.com/maven.springsource.com/snapshot/</url>
+ <snapshots><enabled>true</enabled></snapshots>
+ </repository>
+</repositories>
+
+ To use the SpringSource EBR you would need to use a different
+ naming convention for the dependencies. The names are usually easy to
+ guess, e.g. in this case it is:
+
+ <dependencies>
+ <dependency>
+ <groupId>org.springframework</groupId>
+ <artifactId>org.springframework.context</artifactId>
+ <version>3.0.0.RELEASE</version>
+ <scope>runtime</scope>
+ </dependency>
+</dependencies>
+
+ You also need to declare the location of the repository
+ explicitly (only the URL is important):
+
+ <repositories>
+ <repository>
+ <id>com.springsource.repository.bundles.release</id>
+ <url>http://repository.springsource.com/maven/bundles/release/</url>
+ </repository>
+</repositories>
+
+ If you are managing your dependencies by hand, the URL in the
+ repository declaration above is not browseable, but there is a user
+ interface at http://www.springsource.com/repository
+ that can be used to search for and download dependencies. It also has
+ handy snippets of Maven and Ivy configuration that you can copy and
+ paste if you are using those tools.
+
+ If you prefer to use
+ Ivy to manage dependencies then there are
+ similar names and configuration options there (refer to the
+ documentation of your dependency management system, or look at some
+ sample code - Spring itself uses Ivy to manage dependencies when it is
+ building).
+
+
+
+
+
+ Logging
+
+ Logging is a very important dependency for Spring because a) it is
+ the only mandatory external dependency, b) everyone likes to see some
+ output from the tools they are using, and c) Spring integrates with lots
+ of other tools all of which have also made a choice of logging
+ dependency. One of the goals of an application developer is often to
+ have unified logging configured in a central place for the whole
+ application, including all external components. This is more difficult
+ than it might have been since there are so many choices of logging
+ framework.
+
+ The mandatory logging dependency in Spring is the Jakarta Commons
+ Logging API (JCL). We compile against JCL and we also make JCL
+ Log objects visible for classes that extend the
+ Spring Framework. It's important to users that all versions of Spring
+ use the same logging library: migration is easy because backwards
+ compatibility is preserved even with applications that extend Spring.
+ The way we do this is to make one of the modules in Spring depend
+ explicitly on commons-logging (the canonical implementation
+ of JCL), and then make all the other modules depend on that at compile
+ time. If you are using Maven for example, and wondering where you picked
+ up the dependency on commons-logging, then it is from
+ Spring and specifically from the central module called
+ spring-core.
+
+ The nice thing about commons-logging is that you don't need
+ anything else to make your application work. It has a runtime discovery
+ algorithm that looks for other logging frameworks in well known places
+ on the classpath and uses one that it thinks is appropriate (or you can
+ tell it which one if you need to). If nothing else is available you get
+ pretty nice looking logs just from the JDK (java.util.logging or JUL for
+ short). You should find that your Spring application works and logs
+ happily to the console out of the box in most situations, and that's
+ important.
+
+
+ Not Using Commons Logging
+
+ Unfortunately, the worst thing about commons-logging, and what
+ has made it unpopular with new tools, is also the runtime discovery
+ algorithm. If we could turn back the clock and start Spring now as a
+ new project it would use a different logging dependency. Probably the
+ first choice would be the Simple Logging Framework for Java (SLF4J),
+ which is also used by a lot of other tools
+ that people use with Spring inside their applications.
+
+ To switch off commons-logging is easy: just make sure it isn't
+ on the classpath at runtime. In Maven terms you exclude the
+ dependency, and because of the way that the Spring dependencies are
+ declared, you only have to do that once.
+
+ <dependencies>
+ <dependency>
+ <groupId>org.springframework</groupId>
+ <artifactId>spring-context</artifactId>
+ <version>3.0.0.RELEASE</version>
+ <scope>runtime</scope>
+ <exclusions>
+ <exclusion>
+ <groupId>commons-logging</groupId>
+ <artifactId>commons-logging</artifactId>
+ </exclusion>
+ </exclusions>
+ </dependency>
+</dependencies>
+
+ Now this application is probably broken because there is no
+ implementation of the JCL API on the classpath, so to fix it a new one
+ has to be prvided. In the next section we show you how to provide an
+ alternative implementation of JCL using SLF4J as an example.
+
+
+
+ Using SLF4J
+
+
+ SLF4J is a cleaner dependency and more efficient at runtime than
+ commons-logging because it uses compile-time bindings instead of runtime
+ discovery of the other logging frameworks it integrates. This also means
+ that you have to be more explicit about what you want to happen at
+ runtime, and declare it or configure it accordingly. SLF4J provides
+ bindings to many common logging frameworks, so you can usually choose
+ one that you already use, and bind to that for configuration and
+ management.
+
+ SLF4J provides bindings to many common logging frameworks,
+ including JCL, and it also does the reverse: bridges between other
+ logging frameworks and itself. So to use SLF4J with Spring you need to
+ replace the commons-logging dependency with the SLF4J-JCL bridge. Once
+ you have done that then logging calls from within Spring will be
+ translated into logging calls to the SLF4J API, so if other libraries in
+ your application use that API, then you have a single place to configure
+ and manage logging.
+
+ A common choice might be to bridge Spring to SLF4J, and then
+ provide explicit binding from SLF4J to Log4J. You need to supply 4
+ dependencies (and exclude the existing commons-logging): the bridge, the
+ SLF4J API, the binding to Log4J, and the Log4J implementation itself. In
+ Maven you would do that like this
+
+ <dependencies>
+ <dependency>
+ <groupId>org.springframework</groupId>
+ <artifactId>spring-context</artifactId>
+ <version>3.0.0.RELEASE</version>
+ <scope>runtime</scope>
+ <exclusions>
+ <exclusion>
+ <groupId>commons-logging</groupId>
+ <artifactId>commons-logging</artifactId>
+ </exclusion>
+ </exclusions>
+ </dependency>
+ <dependency>
+ <groupId>org.slf4j</groupId>
+ <artifactId>jcl-slf4j</artifactId>
+ <version>1.5.8</version>
+ <scope>runtime</scope>
+ </dependency>
+ <dependency>
+ <groupId>org.slf4j</groupId>
+ <artifactId>slf4j-api</artifactId>
+ <version>1.5.8</version>
+ <scope>runtime</scope>
+ </dependency>
+ <dependency>
+ <groupId>org.slf4j</groupId>
+ <artifactId>slf4j-log4j12</artifactId>
+ <version>1.5.8</version>
+ <scope>runtime</scope>
+ </dependency>
+ <dependency>
+ <groupId>log4j</groupId>
+ <artifactId>log4j</artifactId>
+ <version>1.2.14</version>
+ <scope>runtime</scope>
+ </dependency>
+</dependencies>
+
+ That might seem like a lot of dependencies just to get some
+ logging. Well it is, but it is optional, and it
+ should behave better than the vanilla commons-logging with
+ respect to classloader issues, notably if you are in a strict container
+ like an OSGi platform. Allegedly there is also a performance benefit
+ because the bindings are at compile-time not runtime.
+
+ A more common choice amongst SLF4J users, which uses fewer steps
+ and generates fewer dependencies, is to bind directly to Logback.
+ This removes the extra binding step because
+ Logback implements SLF4J directly, so you only need to depend on two
+ libaries not four (jcl-slf4j and logback). If
+ you do that you might also need to exlude the slf4j-api dependency from
+ other external dependencies (not Spring), because you only want one
+ version of that API on the classpath.
+
+
+ Using Log4J
+
+ Many people use Log4j as a logging
+ framework for configuration and management purposes. It's efficient
+ and well established, and in fact it's what we use at runtime when we
+ build and test Spring. Spring also provides some utilities for
+ configuring and initializing Log4j, so it have an optional compile
+ time dependency on Log4j in some modules.
+
+ To make Log4j work with the default JCL dependency
+ (commons-logging) all you need to do is put Log4j on the
+ classpath, and provide it with a configuration file
+ (log4j.properties or log4j.xml in the root
+ of the classpath). So for Maven users this is your dependency
+ declaration:
+
+ <dependencies>
+ <dependency>
+ <groupId>org.springframework</groupId>
+ <artifactId>spring-context</artifactId>
+ <version>3.0.0.RELEASE</version>
+ <scope>runtime</scope>
+ </dependency>
+ <dependency>
+ <groupId>log4j</groupId>
+ <artifactId>log4j</artifactId>
+ <version>1.2.14</version>
+ <scope>runtime</scope>
+ </dependency>
+</dependencies>
+
+ And here's a sample log4j.properties for logging to the
+ console:
+
+ log4j.rootCategory=INFO, stdout
+
+log4j.appender.stdout=org.apache.log4j.ConsoleAppender
+log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
+log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %t %c{2}:%L - %m%n
+
+log4j.category.org.springframework.beans.factory=DEBUG
+
+
+ Runtime Containers with Native JCL
+
+ Many people run their Spring applications in a container that
+ itself provides an implementation of JCL. IBM Websphere Application
+ Server (WAS) is the archetype. This often causes problems, and
+ unfortunately there is no silver bullet solution; simply excluding
+ commons-logging from your application is not enough in
+ most situations.
+
+ To be clear about this: the problems reported are usually not
+ with JCL per se, or even with commons-logging: rather
+ they are to do with binding commons-logging to another
+ framework (often Log4J). This can fail because
+ commons-logging changed the way they do the runtime
+ discovery in between the older versions (1.0) found in some
+ containers and the modern versions that most people use now (1.1).
+ Spring does not use any unusual parts of the JCL API, so nothing
+ breaks there, but as soon as Spring or your application tries to do
+ any logging you can find that the bindings to Log4J are not
+ working.
+
+ In such cases with WAS the easiest thing to do is to invert
+ the class loader hierarchy (IBM calls it "parent last") so that the
+ application controls the JCL dependency, not the container. That
+ option isn't always open, but there are plenty of other suggestions
+ in the public domain for alternative approaches, and your mileage
+ may vary depending on the exact version and feature set of the
+ container.
+
+
+
diff --git a/spring-framework-reference/src/spring-framework-reference.xml b/spring-framework-reference/src/spring-framework-reference.xml
index ad643499c1..fbb25d07e0 100644
--- a/spring-framework-reference/src/spring-framework-reference.xml
+++ b/spring-framework-reference/src/spring-framework-reference.xml
@@ -1,374 +1,503 @@
+"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
+
+
+ Reference Documentation
-
-
- Reference Documentation
- Spring Framework
- 3.0.RC3
-
-
-
-
-
-
-
- Rod
- Johnson
-
-
- Juergen
- Hoeller
-
-
- Keith
- Donald
-
-
- Colin
- Sampaleanu
-
-
- Rob
- Harrop
-
-
- Thomas
- Risberg
-
-
- Alef
- Arendsen
-
-
- Darren
- Davison
-
-
- Dmitriy
- Kopylenko
-
-
- Mark
- Pollack
-
-
- Thierry
- Templier
-
-
- Erwin
- Vervaet
-
-
- Portia
- Tung
-
-
- Ben
- Hale
-
-
- Adrian
- Colyer
-
-
- John
- Lewis
-
-
- Costin
- Leau
-
-
- Mark
- Fisher
-
-
- Sam
- Brannen
-
-
- Ramnivas
- Laddad
-
-
- Arjen
- Poutsma
-
-
- Chris
- Beams
-
-
- Tareq
- Abedrabbo
-
-
- Andy
- Clement
-
-
-
- 2004-2009
- Rod Johnson, Juergen Hoeller, Keith Donald, Colin Sampaleanu, Rob Harrop, Alef Arendsen, Thomas Risberg, Darren Davison,
- Dmitriy Kopylenko, Mark Pollack, Thierry Templier, Erwin Vervaet, Portia Tung, Ben Hale, Adrian Colyer, John Lewis,
- Costin Leau, Mark Fisher, Sam Brannen, Ramnivas Laddad, Arjen Poutsma, Chris Beams, Tareq Abedrabbo, Andy Clement
-
-
-
- Copies of this document may be made for your own use and for
- distribution to others, provided that you do not charge any
- fee for such copies and further provided that each copy
- contains this Copyright Notice, whether distributed in print
- or electronically.
-
-
-
-
-
- Overview of Spring Framework
-
- The Spring Framework is a lightweight solution and a potential
- one-stop-shop for building your enterprise-ready applications. However,
- Spring is modular, allowing you to use only those parts that you need,
- without having to bring in the rest. You can use the IoC container, with
- Struts on top, but you can also use only the Hibernate integration code or the JDBC abstraction layer. The Spring
- Framework supports declarative transaction management, remote access to your
- logic through RMI or web services, and various options for persisting your
- data. It offers a full-featured MVC
- framework, and enables you to integrate AOP transparently into your
- software.
+ Spring Framework
- Spring is designed to be non-intrusive, meaning that your domain logic
- code generally has no dependencies on the framework itself. In your
- integration layer (such as the data access layer), some dependencies on the
- data access technology and the Spring libraries will exist. However, it
- should be easy to isolate these dependencies from the rest of your code
- base.
+ 3.0.RC3
- This document is a reference guide to Spring Framework features. If
- you have any requests, comments, or questions on this document, please post
- them on the user mailing list or on the support forums at .
-
-
-
-
- What's New in Spring 3.0
-
-
-
- Core Technologies
-
-
- This part of the reference documentation covers
- all of those technologies that are absolutely integral
- to the Spring Framework.
-
-
- Foremost amongst these is the Spring Framework's
- Inversion of Control (IoC) container. A thorough treatment
- of the Spring Framework's IoC container is closely followed
- by comprehensive coverage of Spring's Aspect-Oriented
- Programming (AOP) technologies. The Spring Framework has
- its own AOP framework, which is conceptually easy to understand,
- and which successfully addresses the 80% sweet spot of AOP
- requirements in Java enterprise programming.
-
-
- Coverage of Spring's integration with AspectJ (currently
- the richest - in terms of features - and certainly most
- mature AOP implementation in the Java enterprise space)
- is also provided.
-
-
- Finally, the adoption of the test-driven-development (TDD)
- approach to software development is certainly advocated by
- the Spring team, and so coverage of Spring's support for
- integration testing is covered (alongside best practices for
- unit testing). The Spring team has found that the correct
- use of IoC certainly does make both unit and integration
- testing easier (in that the presence of setter methods and
- appropriate constructors on classes makes them
- easier to wire together in a test without having to set up
- service locator registries and suchlike)... the chapter
- dedicated solely to testing will hopefully convince you of
- this as well.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Data Access
-
-
- This part of the reference documentation is concerned
- with data access and the interaction between the data access
- layer and the business or service layer.
-
-
- Spring's comprehensive transaction management support is
- covered in some detail, followed by thorough coverage of
- the various data access frameworks and
- technologies that the Spring Framework integrates with.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- The Web
-
-
- This part of the reference documentation covers the
- Spring Framework's support for the presentation tier
- (and specifically web-based presentation tiers).
-
-
- The Spring Framework's own web framework,
- Spring Web MVC, is covered in
- the first couple of chapters. A number of the remaining
- chapters in this part of the reference documentation are
- concerned with the Spring Framework's integration with
- other web technologies, such as Struts
- and JSF (to name but two).
-
-
- This section concludes with coverage of Spring's MVC
- portlet framework.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Integration
-
-
- This part of the reference documentation covers
- the Spring Framework's integration with a number of Java EE
- (and related) technologies.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Appendices
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+ Rod
+
+ Johnson
+
+
+
+ Juergen
+
+ Hoeller
+
+
+
+ Keith
+
+ Donald
+
+
+
+ Colin
+
+ Sampaleanu
+
+
+
+ Rob
+
+ Harrop
+
+
+
+ Thomas
+
+ Risberg
+
+
+
+ Alef
+
+ Arendsen
+
+
+
+ Darren
+
+ Davison
+
+
+
+ Dmitriy
+
+ Kopylenko
+
+
+
+ Mark
+
+ Pollack
+
+
+
+ Thierry
+
+ Templier
+
+
+
+ Erwin
+
+ Vervaet
+
+
+
+ Portia
+
+ Tung
+
+
+
+ Ben
+
+ Hale
+
+
+
+ Adrian
+
+ Colyer
+
+
+
+ John
+
+ Lewis
+
+
+
+ Costin
+
+ Leau
+
+
+
+ Mark
+
+ Fisher
+
+
+
+ Sam
+
+ Brannen
+
+
+
+ Ramnivas
+
+ Laddad
+
+
+
+ Arjen
+
+ Poutsma
+
+
+
+ Chris
+
+ Beams
+
+
+
+ Tareq
+
+ Abedrabbo
+
+
+
+ Andy
+
+ Clement
+
+
+
+ Dave
+
+ Syer
+
+
+
+
+ 2004-2009
+
+ Rod Johnson, Juergen Hoeller, Keith Donald, Colin Sampaleanu,
+ Rob Harrop, Alef Arendsen, Thomas Risberg, Darren Davison, Dmitriy
+ Kopylenko, Mark Pollack, Thierry Templier, Erwin Vervaet, Portia Tung,
+ Ben Hale, Adrian Colyer, John Lewis, Costin Leau, Mark Fisher, Sam
+ Brannen, Ramnivas Laddad, Arjen Poutsma, Chris Beams, Tareq Abedrabbo,
+ Andy Clement
+
+
+
+ Copies of this document may be made for your own use and for
+ distribution to others, provided that you do not charge any fee for such
+ copies and further provided that each copy contains this Copyright
+ Notice, whether distributed in print or electronically.
+
+
+
+
+
+
+
+
+ Overview of Spring Framework
+
+
+ The Spring Framework is a lightweight solution and a potential
+ one-stop-shop for building your enterprise-ready applications. However,
+ Spring is modular, allowing you to use only those parts that you need,
+ without having to bring in the rest. You can use the IoC container, with
+ Struts on top, but you can also use only the Hibernate integration code or the JDBC abstraction layer. The Spring
+ Framework supports declarative transaction management, remote access to
+ your logic through RMI or web services, and various options for
+ persisting your data. It offers a full-featured MVC framework, and enables you to
+ integrate AOP transparently into
+ your software.
+
+ Spring is designed to be non-intrusive, meaning that your domain
+ logic code generally has no dependencies on the framework itself. In
+ your integration layer (such as the data access layer), some
+ dependencies on the data access technology and the Spring libraries will
+ exist. However, it should be easy to isolate these dependencies from the
+ rest of your code base.
+
+ This document is a reference guide to Spring Framework features.
+ If you have any requests, comments, or questions on this document,
+ please post them on the user mailing list or on the support forums at
+ .
+
+
+
+
+
+
+ What's New in Spring 3.0
+
+
+
+
+
+ Core Technologies
+
+
+ This part of the reference documentation covers all of those
+ technologies that are absolutely integral to the Spring
+ Framework.
+
+ Foremost amongst these is the Spring Framework's Inversion of
+ Control (IoC) container. A thorough treatment of the Spring Framework's
+ IoC container is closely followed by comprehensive coverage of Spring's
+ Aspect-Oriented Programming (AOP) technologies. The Spring Framework has
+ its own AOP framework, which is conceptually easy to understand, and
+ which successfully addresses the 80% sweet spot of AOP requirements in
+ Java enterprise programming.
+
+ Coverage of Spring's integration with AspectJ (currently the
+ richest - in terms of features - and certainly most mature AOP
+ implementation in the Java enterprise space) is also provided.
+
+ Finally, the adoption of the test-driven-development (TDD)
+ approach to software development is certainly advocated by the Spring
+ team, and so coverage of Spring's support for integration testing is
+ covered (alongside best practices for unit testing). The Spring team has
+ found that the correct use of IoC certainly does make both unit and
+ integration testing easier (in that the presence of setter methods and
+ appropriate constructors on classes makes them easier to wire together
+ in a test without having to set up service locator registries and
+ suchlike)... the chapter dedicated solely to testing will hopefully
+ convince you of this as well.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Data Access
+
+
+ This part of the reference documentation is concerned with data
+ access and the interaction between the data access layer and the
+ business or service layer.
+
+ Spring's comprehensive transaction management support is covered
+ in some detail, followed by thorough coverage of the various data access
+ frameworks and technologies that the Spring Framework integrates
+ with.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The Web
+
+
+ This part of the reference documentation covers the Spring
+ Framework's support for the presentation tier (and specifically
+ web-based presentation tiers).
+
+ The Spring Framework's own web framework, Spring Web MVC, is covered in the first couple of
+ chapters. A number of the remaining chapters in this part of the
+ reference documentation are concerned with the Spring Framework's
+ integration with other web technologies, such as Struts and JSF (to
+ name but two).
+
+ This section concludes with coverage of Spring's MVC portlet framework.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Integration
+
+
+ This part of the reference documentation covers the Spring
+ Framework's integration with a number of Java EE (and related)
+ technologies.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Appendices
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/spring-framework-reference/src/testing.xml b/spring-framework-reference/src/testing.xml
index a7f4697904..65f21c749c 100644
--- a/spring-framework-reference/src/testing.xml
+++ b/spring-framework-reference/src/testing.xml
@@ -157,7 +157,7 @@
The Spring Framework provides first class support for integration
testing in the org.springframework.test-VERSION.jar
+ class="libraryfile">spring-test.jar
library (where VERSION is the release version). This
library includes the org.springframework.test
package, which contains valuable classes for integration testing with a
diff --git a/spring-framework-reference/src/view.xml b/spring-framework-reference/src/view.xml
index d5116d9ca9..0bfb9ac5e4 100644
--- a/spring-framework-reference/src/view.xml
+++ b/spring-framework-reference/src/view.xml
@@ -100,7 +100,7 @@ productList.url=/WEB-INF/jsp/productlist.jsp
escaping of characters.The tag library descriptor (TLD) is included in the org.springframework.web.servlet-3.0.0.RELEASE.jar.
+ class="libraryfile">spring-webmvc.jar.
Further information about the individual tags can be found in
the appendix entitled .
@@ -129,7 +129,7 @@ productList.url=/WEB-INF/jsp/productlist.jsp
ConfigurationThe form tag library comes bundled in
- org.springframework.web.servlet-3.0.0.RELEASE.jar.
+ spring-webmvc.jar.
The library descriptor is called
spring-form.tld.
@@ -1004,7 +1004,7 @@ findOwnersForm.url=/WEB-INF/jsp/findOwners.jsp
WEB-INF/lib folder where they are guaranteed to be
found by a Java EE server and added to the classpath for your application.
It is of course assumed that you already have the spring.jar in your spring-webmvc.jar in your 'WEB-INF/lib' directory too! If you make use of
Spring's 'dateToolAttribute' or 'numberToolAttribute' in your Velocity
views, you will also need to include the VelocityConfigurer bean definition above.<bean id="velocityConfig" class="org.springframework.web.servlet.view.velocity.VelocityConfigurer">
- <property name="configLocation value="/WEB-INF/velocity.properties"/>
+ <property name="configLocation" value="/WEB-INF/velocity.properties"/>
</bean>Alternatively, you can specify velocity properties directly in
@@ -1170,7 +1170,7 @@ findOwnersForm.url=/WEB-INF/jsp/findOwners.jsp
The bind macrosA standard set of macros are maintained within the
- spring.jar file for both languages, so they are
+ spring-webmvc.jar file for both languages, so they are
always available to a suitably configured application.Some of the macros defined in the Spring libraries are
@@ -1865,7 +1865,7 @@ home.root=words
|
+- lib
| |
- | +- spring.jar
+ | +- spring-*.jar
|
+- xsl
| |