From 56dcd9296a16d3cd37915e34c9a69b5e42cd3a90 Mon Sep 17 00:00:00 2001 From: Chris Beams Date: Mon, 14 Dec 2009 17:09:52 +0000 Subject: [PATCH] minor usage/grammar improvements in logging section --- spring-framework-reference/src/overview.xml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) 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.