polishing JavaDoc

This commit is contained in:
Sam Brannen 2011-02-08 22:08:38 +00:00
parent 2d76dde611
commit e7c2713fd4
1 changed files with 4 additions and 4 deletions

View File

@ -28,7 +28,7 @@ import org.springframework.beans.factory.parsing.ProblemReporter;
* either the {@code <context:component-scan>} XML element or (as of Spring 3.1) the * either the {@code <context:component-scan>} XML element or (as of Spring 3.1) the
* {@code @ComponentScan} annotation. These two options are equivalent to one another, and users may * {@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 * choose between them as a matter of convention or preference. Fundamentally, both are declarative
* mechanisms for <em>specifying</em> how the Spring container should be configured. A {@code * mechanisms for <em>specifying</em> how the Spring container should be configured. A {@code
* FeatureSpecification} object, then, is a way of representing this configuration information independent * FeatureSpecification} object, then, is a way of representing this configuration information independent
* of its original source format be it XML, annotations, or otherwise. * of its original source format be it XML, annotations, or otherwise.
* *
@ -79,7 +79,7 @@ import org.springframework.beans.factory.parsing.ProblemReporter;
* <p>Typically, a user will call only the constructor and 'mutator' methods of a specification * <p>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 * object. The accessor/getter methods, however, are typically called only by the specification's
* {@linkplain FeatureSpecificationExecutor executor} for the purpose of populating and registering * {@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 * 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 * an IDE content-assist point of view as they will see only the public mutator methods, reducing
* any possible confusion. * any possible confusion.
@ -87,10 +87,10 @@ import org.springframework.beans.factory.parsing.ProblemReporter;
* <p>Implementations should take care to allow for use of string-based bean names, placeholder * <p>Implementations should take care to allow for use of string-based bean names, placeholder
* (<code>"${...}"</code>) and SpEL (<code>"#{...}</code>) expressions wherever they may be useful. * (<code>"${...}"</code>) and SpEL (<code>"#{...}</code>) expressions wherever they may be useful.
* While it is generally desirable to refer to dependent beans in pure Java, in certain cases a * 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 * 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 * {@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 * 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 * 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. * a bean instance, specification executors will not support such use unless explicitly indicated.