From e7c2713fd40ff8b8bdf7675b58c76cd915eabb6f Mon Sep 17 00:00:00 2001 From: Sam Brannen Date: Tue, 8 Feb 2011 22:08:38 +0000 Subject: [PATCH] polishing JavaDoc --- .../context/config/FeatureSpecification.java | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/org.springframework.context/src/main/java/org/springframework/context/config/FeatureSpecification.java b/org.springframework.context/src/main/java/org/springframework/context/config/FeatureSpecification.java index 9942c36131..7a0936c639 100644 --- a/org.springframework.context/src/main/java/org/springframework/context/config/FeatureSpecification.java +++ b/org.springframework.context/src/main/java/org/springframework/context/config/FeatureSpecification.java @@ -28,7 +28,7 @@ import org.springframework.beans.factory.parsing.ProblemReporter; * either the {@code } XML element or (as of Spring 3.1) the * {@code @ComponentScan} annotation. These two options are equivalent to one another, and users may * choose between them as a matter of convention or preference. Fundamentally, both are declarative - * mechanisms for specifying how the Spring container should be configured. A {@code + * mechanisms for specifying how the Spring container should be configured. A {@code * FeatureSpecification} object, then, is a way of representing this configuration information independent * of its original source format be it XML, annotations, or otherwise. * @@ -79,7 +79,7 @@ import org.springframework.beans.factory.parsing.ProblemReporter; *

Typically, a user will call only the constructor and 'mutator' methods of a specification * object. The accessor/getter methods, however, are typically called only by the specification's * {@linkplain FeatureSpecificationExecutor executor} for the purpose of populating and registering - * bean definitions with the Spring container.For this reason, it is recommended that accessor + * bean definitions with the Spring container. For this reason, it is recommended that accessor * methods be given package-private visibility. This creates a better experience for users from * an IDE content-assist point of view as they will see only the public mutator methods, reducing * any possible confusion. @@ -87,10 +87,10 @@ import org.springframework.beans.factory.parsing.ProblemReporter; *

Implementations should take care to allow for use of string-based bean names, placeholder * ("${...}") and SpEL ("#{...}) expressions wherever they may be useful. * While it is generally desirable to refer to dependent beans in pure Java, in certain cases a - * user may wish or need to refer by bean name. For example, the {@code TxAnnotationDriven} specification + * user may wish or need to refer to a bean by name. For example, the {@code TxAnnotationDriven} specification * referenced above allows for specifying its transaction-manager reference by {@code String} or by * {@code PlatformTransactionManager} reference. Such strings should always be candidates for placeholder - * replacement and SpEL evaluation for maximum configurability as well as parity with the featureset + * replacement and SpEL evaluation for maximum configurability as well as parity with the feature set * available in Spring XML. With regard to SpEL expressions, users should assume that only expressions * evaluating to a bean name will be supported. While it is technically possible with SpEL to resolve * a bean instance, specification executors will not support such use unless explicitly indicated.