diff --git a/spring-framework-reference/src/overview.xml b/spring-framework-reference/src/overview.xml
index 358eda7476..b90310a804 100644
--- a/spring-framework-reference/src/overview.xml
+++ b/spring-framework-reference/src/overview.xml
@@ -765,16 +765,16 @@ TR: OK. Added to diagram.-->
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
+ commons-logging (and what has made it unpopular with new
+ tools) is its 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
+ different logging dependency. The first choice would probably be the
Simple Logging Facade 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
+ Switching 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.
@@ -889,7 +889,7 @@ TR: OK. Added to diagram.-->
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
+ 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.