diff --git a/spring-framework-reference/src/new-in-3.xml b/spring-framework-reference/src/new-in-3.xml index b75ab8772cf..bcd109de348 100644 --- a/spring-framework-reference/src/new-in-3.xml +++ b/spring-framework-reference/src/new-in-3.xml @@ -5,36 +5,207 @@
Introduction - *** WORK IN PROGRESS *** - If you have been using the Spring Framework for some time, you will be aware that Spring has undergone two major revisions: Spring 2.0, - released in October 2006, and Spring 2.5, released in November 2007. + released in October 2006, and Spring 2.5, released in November 2007. It is + now time for a third overhaul resulting in Spring 3.0. Java SE and Java EE Support - The Spring Framework is now based on Java 5 and Java 6 is fully supported. + The Spring Framework is now based on Java 5 and Java 6 is fully + supported. Furthermore, Spring is compatible with J2EE 1.4 and Java EE 5, - while at the same time introducing dedicated support for Java EE 6. + while at the same time introducing some early support for Java EE + 6. -
-
+
Improved documentation + + Note: + + The current documentation is a *** WORK IN PROGRESS + *** and is currently being re-written to reflect all the + changes in the framework and from now relying on Java 5 features. + + The Spring reference documentation has also substantially been - updated to reflect all of the changes and new features for Spring 3.0. - While every effort has been made to ensure that there are no errors in this - documentation, some errors may nevertheless have crept in. If you do spot - any typos or even more serious errors, and you can spare a few cycles + updated to reflect all of the changes and new features for Spring 3.0. + While every effort has been made to ensure that there are no errors in + this documentation, some errors may nevertheless have crept in. If you do + spot any typos or even more serious errors, and you can spare a few cycles during lunch, please do bring the error to the attention of the Spring - team by raising an + team by raising an issue. +
+ +
+ New module organization and build system + + The framework modules have been revised and are now managed + separately with one source-tree per module jar: + + + + org.springframework.aop + + + + org.springframework.beans + + + + org.springframework.context + + + + org.springframework.context.support + + + + org.springframework.expression + + + + org.springframework.instrument + + + + org.springframework.jdbc + + + + org.springframework.jms + + + + org.springframework.orm + + + + org.springframework.oxm + + + + org.springframework.test + + + + org.springframework.transaction + + + + org.springframework.web + + + + org.springframework.web.portlet + + + + org.springframework.web.servlet + + + + + Note: + + The spring.jar artifact that contained almost the entire framework + is no longer provided. + + + We are now using a new Spring build system as known from Spring Web + Flow 2.0. This gives us: + + + + Ivy-based "Spring Build" system + + + + consistent deployment procedure + + + consistent dependency management + + + + consistent generation of OSGi manifests + +
- +
+ Overview of new features + + This is a list of new features for Spring 3.0. We will cover these + features in more detail in the following sections. + + + + Java 5+ foundation + + compatible with J2EE 1.4 and Java EE 5 + + + + Spring Expression Language + + Unified EL++ + + + + Container enhancements + + Core JavaConfigfeatures added + + + + Comprehensive REST support + + and other Spring @MVC additions + + + + Declarative model validation + + Hibernate Validator, JSR 303 + + + + Early support for Java EE 6 + + JSF 2.0, JPA 2.0, etc + + +
+
+ Java 5+ foundation + *** WORK IN PROGRESS *** +
+
+ Spring Expression Language + *** WORK IN PROGRESS *** +
+
+ Container enhancements + *** WORK IN PROGRESS *** +
+
+ Comprehensive REST support + *** WORK IN PROGRESS *** +
+
+ Declarative model validation + *** WORK IN PROGRESS *** +
+
+ Early support for Java EE 6 + *** WORK IN PROGRESS *** +
+ \ No newline at end of file diff --git a/spring-framework-reference/src/overview.xml b/spring-framework-reference/src/overview.xml index ca4641f9ca0..01babea0a7f 100644 --- a/spring-framework-reference/src/overview.xml +++ b/spring-framework-reference/src/overview.xml @@ -2,70 +2,105 @@ Introduction - - Background - - In early 2004, Martin Fowler asked the readers of his site: when - talking about Inversion of Control: the question is, what - aspect of control are [they] inverting?. Fowler then - suggested renaming the principle (or at least giving it a more - self-explanatory name), and started to use the term Dependency - Injection. His article then continued to explain the ideas - underpinning the Inversion of Control (IoC) and - Dependency Injection (DI) principle. - - If you need a decent insight into IoC and DI, please do refer to - said article : http://martinfowler.com/articles/injection.html. - - - Java applications (a loose term which runs the gamut from constrained - applets to full-fledged n-tier server-side enterprise applications) - typically are composed of a number of objects that collaborate with one - another to form the application proper. The objects in an application can - thus be said to have dependencies between - themselves. - - The Java language and platform provides a wealth of functionality for - architecting and building applications, ranging all the way from the very - basic building blocks of primitive types and classes (and the means to - define new classes), to rich full-featured application servers and web - frameworks. One area that is decidedly conspicuous by its absence is any - means of taking the basic building blocks and composing them into a coherent - whole; this area has typically been left to the purvey of the architects and - developers tasked with building an application (or applications). Now to be - fair, there are a number of design patterns devoted to the business of - composing the various classes and object instances that makeup an - all-singing, all-dancing application. Design patterns such as - Factory, Abstract Factory, - Builder, Decorator, and - Service Locator (to name but a few) have widespread - recognition and acceptance within the software development industry - (presumably that is why these patterns have been formalized as patterns in - the first place). This is all very well, but these patterns are just that: - best practices given a name, typically together with a description of what - the pattern does, where the pattern is typically best applied, the problems - that the application of the pattern addresses, and so forth. Notice that the - last paragraph used the phrase ... a description - of what the pattern does...; pattern books and wikis are typically - listings of such formalized best practice that you can certainly take away, - mull over, and then implement yourself in your - application. - - The IoC component of the Spring Framework addresses the enterprise - concern of taking the classes, objects, and services that are to compose an - application, by providing a formalized means of composing these various - disparate components into a fully working application ready for use. The - Spring Framework takes best practices that have been proven over the years - in numerous applications and formalized as design patterns, and actually - codifies these patterns as first class objects that you as an architect and - developer can take away and integrate into your own application(s). This is - a Very Good Thing Indeed as attested to by the - numerous organizations and institutions that have used the Spring Framework - to engineer robust, maintainable applications. - -
- Overview + Fundamentally, what is Spring? We think of it as a Platform for your Java code. It provides + comprehensive infrastructural support for developing Java applications. Spring deals with the plumbing + so you can focus on solving the domain problem + + Spring as a platform allows applications to be built from “plain old Java objects” (POJOs). This is true + for the Java SE programming model as well as within a number of other environments including full and partial Java EE. + Spring allows enterprise services to be applied to POJOs in a non-invasive way + + Examples of Spring as a platform: + + + + Make a Java method execute in a database transaction; without the implementer dealing with transaction + APIs + + + + Make a local Java method a remote-procedure; without the implementer dealing with remoting APIs + + + + Make a local Java method a management operation; without the implementer dealing with JMX APIs + + + + Make a local Java method a message handler; without the implementer dealing with JMS APIs + + + + +
+ Dependency Injection + + + Background + + In early 2004, Martin Fowler asked the readers of his site: when + talking about Inversion of Control: the question is, what + aspect of control are [they] inverting?. Fowler then + suggested renaming the principle (or at least giving it a more + self-explanatory name), and started to use the term Dependency + Injection. His article then continued to explain the ideas + underpinning the Inversion of Control (IoC) and + Dependency Injection (DI) principle. + + If you need a decent insight into IoC and DI, please do refer to + said article: http://martinfowler.com/articles/injection.html. + + + Java applications (a loose term which runs the gamut from constrained + applets to full-fledged n-tier server-side enterprise applications) + typically are composed of a number of objects that collaborate with one + another to form the application proper. The objects in an application can + thus be said to have dependencies between + themselves. + + The Java language and platform provides a wealth of functionality for + architecting and building applications, ranging all the way from the very + basic building blocks of primitive types and classes (and the means to + define new classes), to rich full-featured application servers and web + frameworks. One area that is decidedly conspicuous by its absence is any + means of taking the basic building blocks and composing them into a coherent + whole; this area has typically been left to the purvey of the architects and + developers tasked with building an application (or applications). Now to be + fair, there are a number of design patterns devoted to the business of + composing the various classes and object instances that makeup an + all-singing, all-dancing application. Design patterns such as + Factory, Abstract Factory, + Builder, Decorator, and + Service Locator (to name but a few) have widespread + recognition and acceptance within the software development industry + (presumably that is why these patterns have been formalized as patterns in + the first place). This is all very well, but these patterns are just that: + best practices given a name, typically together with a description of what + the pattern does, where the pattern is typically best applied, the problems + that the application of the pattern addresses, and so forth. Notice that the + last paragraph used the phrase ... a description + of what the pattern does...; pattern books and wikis are typically + listings of such formalized best practice that you can certainly take away, + mull over, and then implement yourself in your + application. + + The IoC component of the Spring Framework addresses the enterprise + concern of taking the classes, objects, and services that are to compose an + application, by providing a formalized means of composing these various + disparate components into a fully working application ready for use. The + Spring Framework takes best practices that have been proven over the years + in numerous applications and formalized as design patterns, and actually + codifies these patterns as first class objects that you as an architect and + developer can take away and integrate into your own application(s). This is + a Very Good Thing Indeed as attested to by the + numerous organizations and institutions that have used the Spring Framework + to engineer robust, maintainable applications. + +
+ +
+ Modules The Spring Framework contains a lot of features, which are well-organized in six modules shown in the diagram below. This chapter @@ -86,7 +121,7 @@ The Core package is + linkend="beans-introduction">Core module is the most fundamental part of the framework and provides the IoC and Dependency Injection features. The basic concept here is the BeanFactory, which provides a sophisticated