diff --git a/spring-framework-reference/src/web-integration.xml b/spring-framework-reference/src/web-integration.xml
index bb4d39dd11..f03be4da32 100644
--- a/spring-framework-reference/src/web-integration.xml
+++ b/spring-framework-reference/src/web-integration.xml
@@ -39,7 +39,7 @@
details of integrating your favorite web framework with Spring. One thing
that is often commented upon by developers coming to Java from other
languages is the seeming super-abundance of web frameworks available in
- Java... there are indeed a great number of web frameworks in the Java
+ Java. There are indeed a great number of web frameworks in the Java
space; in fact there are far too many to cover with any semblance of
detail in a single chapter. This chapter thus picks four of the more
popular web frameworks in Java, starting with the Spring configuration
@@ -63,15 +63,15 @@
Common configuration
Before diving into the integration specifics of each supported web
- framework, let us first take a look at the Spring configuration that
+ framework, let us first take a look at the Spring configuration that is
not specific to any one web framework. (This section
is equally applicable to Spring's own web framework, Spring MVC.)
One of the concepts (for want of a better word) espoused by
(Spring's) lightweight application model is that of a layered
architecture. Remember that in a 'classic' layered architecture, the web
- layer is but one of many layers... it serves as one of the entry points
- into a server side application, and it delegates to service objects
+ layer is but one of many layers; it serves as one of the entry points
+ into a server side application and it delegates to service objects
(facades) defined in a service layer to satisfy business specific (and
presentation-technology agnostic) use cases. In Spring, these service
objects, any other business-specific objects, data access objects, etc.
@@ -82,7 +82,7 @@
a Spring container (a WebApplicationContext) that
contains all of the 'business beans' in one's application.
- Onto specifics... all that one need do is to declare a On to specifics: all that one need do is to declare a ContextLoaderListener
in the standard Java EE servlet web.xml file of one's web
application, and add a contextConfigLocation
@@ -117,7 +117,7 @@
to load. Once the context files are loaded, Spring creates a WebApplicationContext
object based on the bean definitions and stores it in the
- ServletContext of one's web application.
+ ServletContext of the web application.
All Java web frameworks are built on top of the Servlet API, and so
one can use the following code snippet to get access to this 'business
@@ -141,7 +141,7 @@
Once you have a reference to the
WebApplicationContext, you can retrieve beans by
- their name or type. Most developers retrieve beans by name, then cast them
+ their name or type. Most developers retrieve beans by name and then cast them
to one of their implemented interfaces.
Fortunately, most of the frameworks in this section have simpler
@@ -209,7 +209,7 @@
The DelegatingVariableResolver will first
delegate value lookups to the default resolver of the underlying JSF
- implementation, and then to Spring's 'business context'
+ implementation and then to Spring's 'business context'
WebApplicationContext. This allows one to easily
inject dependencies into one's JSF-managed beans.
@@ -235,7 +235,7 @@
SpringBeanVariableResolver is a variant of
DelegatingVariableResolver. It delegates to the
Spring's 'business context' WebApplicationContext
- first, then to the default resolver of the
+ first and then to the default resolver of the
underlying JSF implementation. This is useful in particular when using
request/session-scoped beans with special Spring resolution rules, e.g.
Spring FactoryBean
@@ -541,10 +541,10 @@
The recommended strategy is to use the approach that best suits
your project. Subclassing makes your code more readable, and you know
- exactly how your dependencies are resolved. However, using the
- ContextLoaderPlugin allow you to easily add new
+ exactly how your dependencies are resolved. In contrast, using the
+ ContextLoaderPlugin allows you to easily add new
dependencies in your context XML file. Either way, Spring provides some
- nice options for integrating the two frameworks.
+ nice options for integrating with Struts.
@@ -566,8 +566,9 @@
WebWork is (in the opinion of this author) a very clean, elegant web
- framework. Its architecture and key concepts are not only very easy to
- understand, it has a rich tag library, nicely decoupled validation, and it
+ framework. Its architecture and key concepts are very easy to
+ understand, and the framework also has a rich tag library as well as
+ nicely decoupled validation. It
is (again, in the opinion of this author) quite easy to be productive in
next to no time at all (the documentation and tutorials are pretty good
too).
@@ -577,17 +578,17 @@
IoC container to manage Webwork Actions, handle the "wiring" of
business objects, etc. Prior to WebWork version 2.2, WebWork used its own
proprietary IoC container (and provided integration points so that one
- could integrate an IoC container such as Springs into the mix). However,
+ could integrate an IoC container such as Spring's into the mix). However,
as of WebWork version 2.2, the default IoC container that is used within
WebWork is Spring. This is obviously great news if
one is a Spring developer, because it means that one is immediately
- familiar with the basics of IoC configuration, idioms and suchlike within
+ familiar with the basics of IoC configuration, idioms, and suchlike within
WebWork.
- Now in the interests of adhering to the DRY (Dont Repeat Yourself)
- principle, it would be foolish to writeup the Spring-WebWork integration
+ Now in the interests of adhering to the DRY (Don't Repeat Yourself)
+ principle, it would be foolish to document the Spring-WebWork integration
in light of the fact that the WebWork team have already written such a
- writeup. Please do consult the Spring-WebWork
integration page on the WebWork wiki
@@ -595,11 +596,11 @@
Note that the Spring-WebWork integration code was developed (and
continues to be maintained and improved) by the WebWork developers
- themselves, so in the first instance please do refer to the WebWork site
- and forums if you are having issues with the integration. Do feel free to
+ themselves. So please refer first to the WebWork site and forums if you are
+ having issues with the integration. But feel free to
post comments and queries regarding the Spring-WebWork integration on the
Spring
- support forums too.
+ support forums, too.
- The key question then is... how does one supply Tapestry pages with
+ The key question then is: how does one supply Tapestry pages with
collaborating services? The answer, ideally, is that one would want to
dependency inject those services directly into one's Tapestry pages. In
Tapestry, one can effect this dependency injection by a variety of
@@ -745,9 +746,9 @@ http://www.springframework.org/schema/beans http://www.springframework.org/schem
WebApplicationContext appContext = WebApplicationContextUtils.getApplicationContext(
getRequestCycle().getRequestContext().getServlet().getServletContext());
UserService userService = (UserService) appContext.getBean("userService");
-... some code which uses UserService
+// ... some code which uses UserService
- This mechanism does work... having said that, it can be made a lot
+ This mechanism does work. Having said that, it can be made a lot
less verbose by encapsulating most of the functionality in a method in
the base class for the page or component. However, in some respects it
goes against the IoC principle; ideally you would like the page to not
@@ -785,7 +786,7 @@ UserService userService = (UserService) appContext.getBean("userService");
package com.whatever.web.xportal;
-import ...
+// import ...
public class MyEngine extends org.apache.tapestry.engine.BaseEngine {
@@ -1042,7 +1043,7 @@ public abstract class Login extends BasePage implements ErrorProperty, PageRende
annotate the appropriate getter methods in order to dependency inject
the Spring-managed userService and
authenticationService objects (lots of the class
- definition has been elided for clarity)...
+ definition has been elided for clarity).
package com.whatever.web.xportal.pages;
@@ -1056,7 +1057,7 @@ public abstract class Login extends BasePage implements ErrorProperty, PageRende
}
- We are almost done... all that remains is the HiveMind
+ We are almost done. All that remains is the HiveMind
configuration that exposes the Spring container stored in the
ServletContext as a HiveMind service;
for example: