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.Main The '-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 Configuration The 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 macros A 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 | |