Fix some typos and mistakes in ref docs
Closes gh-27388
This commit is contained in:
committed by
Sam Brannen
parent
674dc2f203
commit
c46cc666d6
@@ -366,7 +366,7 @@ the https://www.eclipse.org/aspectj/doc/released/progguide/index.html[AspectJ
|
||||
Programming Guide] (and, for extensions, the
|
||||
https://www.eclipse.org/aspectj/doc/released/adk15notebook/index.html[AspectJ 5
|
||||
Developer's Notebook]) or one of the books on AspectJ (such as _Eclipse AspectJ_, by Colyer
|
||||
et. al., or _AspectJ in Action_, by Ramnivas Laddad).
|
||||
et al., or _AspectJ in Action_, by Ramnivas Laddad).
|
||||
|
||||
|
||||
[[aop-pointcuts-designators]]
|
||||
@@ -893,7 +893,7 @@ scoping). You can include the contextual designators to match based on
|
||||
join point context or bind that context for use in the advice. Supplying only a
|
||||
kinded designator or only a contextual designator works but could affect weaving
|
||||
performance (time and memory used), due to extra processing and analysis. Scoping
|
||||
designators are very fast to match, and using them usage means AspectJ can very quickly
|
||||
designators are very fast to match, and using them means AspectJ can very quickly
|
||||
dismiss groups of join points that should not be further processed. A good
|
||||
pointcut should always include one if possible.
|
||||
|
||||
|
||||
@@ -1024,7 +1024,7 @@ by type without help. Consider the following class:
|
||||
|
||||
class ExampleBean(
|
||||
private val years: Int, // Number of years to calculate the Ultimate Answer
|
||||
private val ultimateAnswer: String// The Answer to Life, the Universe, and Everything
|
||||
private val ultimateAnswer: String // The Answer to Life, the Universe, and Everything
|
||||
)
|
||||
----
|
||||
|
||||
@@ -1608,7 +1608,7 @@ listings shows how to use the `parent` attribute:
|
||||
----
|
||||
<!-- in the parent context -->
|
||||
<bean id="accountService" class="com.something.SimpleAccountService">
|
||||
<!-- insert dependencies as required as here -->
|
||||
<!-- insert dependencies as required here -->
|
||||
</bean>
|
||||
----
|
||||
|
||||
@@ -1690,7 +1690,7 @@ respectively. The following example shows how to use them:
|
||||
<property name="someMap">
|
||||
<map>
|
||||
<entry key="an entry" value="just some string"/>
|
||||
<entry key ="a ref" value-ref="myDataSource"/>
|
||||
<entry key="a ref" value-ref="myDataSource"/>
|
||||
</map>
|
||||
</property>
|
||||
<!-- results in a setSomeSet(java.util.Set) call -->
|
||||
@@ -1834,7 +1834,7 @@ class SomeClass {
|
||||
When the `accounts` property of the `something` bean is prepared for injection, the generics
|
||||
information about the element type of the strongly-typed `Map<String, Float>` is
|
||||
available by reflection. Thus, Spring's type conversion infrastructure recognizes the
|
||||
various value elements as being of type `Float`, and the string values (`9.99, 2.75`, and
|
||||
various value elements as being of type `Float`, and the string values (`9.99`, `2.75`, and
|
||||
`3.99`) are converted into an actual `Float` type.
|
||||
|
||||
|
||||
@@ -2028,7 +2028,7 @@ not commonly used since the plain order of declaration is usually sufficient the
|
||||
In practice, the constructor resolution
|
||||
<<beans-factory-ctor-arguments-resolution,mechanism>> is quite efficient in matching
|
||||
arguments, so unless you really need to, we recommend using the name notation
|
||||
through-out your configuration.
|
||||
throughout your configuration.
|
||||
|
||||
|
||||
[[beans-compound-property-names]]
|
||||
@@ -2503,13 +2503,13 @@ declared return type of the lookup method:
|
||||
public abstract class CommandManager {
|
||||
|
||||
public Object process(Object commandState) {
|
||||
MyCommand command = createCommand();
|
||||
Command command = createCommand();
|
||||
command.setState(commandState);
|
||||
return command.execute();
|
||||
}
|
||||
|
||||
@Lookup
|
||||
protected abstract MyCommand createCommand();
|
||||
protected abstract Command createCommand();
|
||||
}
|
||||
----
|
||||
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
|
||||
@@ -2604,9 +2604,9 @@ interface provides the new method definition, as the following example shows:
|
||||
.Kotlin
|
||||
----
|
||||
/**
|
||||
* meant to be used to override the existing computeValue(String)
|
||||
* implementation in MyValueCalculator
|
||||
*/
|
||||
* meant to be used to override the existing computeValue(String)
|
||||
* implementation in MyValueCalculator
|
||||
*/
|
||||
class ReplacementComputeValue : MethodReplacer {
|
||||
|
||||
override fun reimplement(obj: Any, method: Method, args: Array<out Any>): Any {
|
||||
@@ -2806,7 +2806,7 @@ prototype-scoped bean repeatedly at runtime. You cannot dependency-inject a
|
||||
prototype-scoped bean into your singleton bean, because that injection occurs only
|
||||
once, when the Spring container instantiates the singleton bean and resolves
|
||||
and injects its dependencies. If you need a new instance of a prototype bean at
|
||||
runtime more than once, see <<beans-factory-method-injection>>
|
||||
runtime more than once, see <<beans-factory-method-injection>>.
|
||||
|
||||
|
||||
|
||||
@@ -2984,7 +2984,7 @@ The Spring container creates a new instance of the `AppPreferences` bean by usin
|
||||
`appPreferences` bean is scoped at the `ServletContext` level and stored as a regular
|
||||
`ServletContext` attribute. This is somewhat similar to a Spring singleton bean but
|
||||
differs in two important ways: It is a singleton per `ServletContext`, not per Spring
|
||||
'ApplicationContext' (for which there may be several in any given web application),
|
||||
`ApplicationContext` (for which there may be several in any given web application),
|
||||
and it is actually exposed and therefore visible as a `ServletContext` attribute.
|
||||
|
||||
When using annotation-driven components or Java configuration, you can use the
|
||||
@@ -3100,7 +3100,7 @@ to the HTTP `Session`-scoped bean (`userPreferences`). The salient point here is
|
||||
`userManager` bean is a singleton: it is instantiated exactly once per
|
||||
container, and its dependencies (in this case only one, the `userPreferences` bean) are
|
||||
also injected only once. This means that the `userManager` bean operates only on the
|
||||
exact same `userPreferences` object (that is, the one with which it was originally injected.
|
||||
exact same `userPreferences` object (that is, the one with which it was originally injected).
|
||||
|
||||
This is not the behavior you want when injecting a shorter-lived scoped bean into a
|
||||
longer-lived scoped bean (for example, injecting an HTTP `Session`-scoped collaborating
|
||||
@@ -3928,7 +3928,7 @@ shows the definition of the BeanNameAware interface:
|
||||
----
|
||||
|
||||
The callback is invoked after population of normal bean properties but before an
|
||||
initialization callback such as `InitializingBean`, `afterPropertiesSet`, or a custom
|
||||
initialization callback such as `InitializingBean.afterPropertiesSet()` or a custom
|
||||
init-method.
|
||||
|
||||
|
||||
@@ -3960,7 +3960,7 @@ dependency type. The following table summarizes the most important `Aware` inter
|
||||
|
||||
| `BeanFactoryAware`
|
||||
| Declaring `BeanFactory`.
|
||||
| <<beans-factory-aware>>
|
||||
| <<beans-beanfactory>>
|
||||
|
||||
| `BeanNameAware`
|
||||
| Name of the declaring bean.
|
||||
@@ -4142,7 +4142,7 @@ or it may wrap a bean with a proxy. Some Spring AOP infrastructure classes are
|
||||
implemented as bean post-processors in order to provide proxy-wrapping logic.
|
||||
|
||||
An `ApplicationContext` automatically detects any beans that are defined in the
|
||||
configuration metadata that implements the `BeanPostProcessor` interface. The
|
||||
configuration metadata that implement the `BeanPostProcessor` interface. The
|
||||
`ApplicationContext` registers these beans as post-processors so that they can be called
|
||||
later, upon bean creation. Bean post-processors can be deployed in the container in the
|
||||
same fashion as any other beans.
|
||||
@@ -4673,11 +4673,11 @@ example:
|
||||
----
|
||||
class SimpleMovieLister {
|
||||
|
||||
@Required
|
||||
lateinit var movieFinder: MovieFinder
|
||||
@Required
|
||||
lateinit var movieFinder: MovieFinder
|
||||
|
||||
// ...
|
||||
}
|
||||
// ...
|
||||
}
|
||||
----
|
||||
|
||||
This annotation indicates that the affected bean property must be populated at
|
||||
@@ -5373,7 +5373,7 @@ Letting qualifier values select against target bean names, within the type-match
|
||||
candidates, does not require a `@Qualifier` annotation at the injection point.
|
||||
If there is no other resolution indicator (such as a qualifier or a primary marker),
|
||||
for a non-unique dependency situation, Spring matches the injection point name
|
||||
(that is, the field name or parameter name) against the target bean names and choose the
|
||||
(that is, the field name or parameter name) against the target bean names and chooses the
|
||||
same-named candidate, if any.
|
||||
====
|
||||
|
||||
@@ -6042,14 +6042,14 @@ example shows:
|
||||
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
|
||||
.Java
|
||||
----
|
||||
@Configuration
|
||||
public class AppConfig {
|
||||
@Configuration
|
||||
public class AppConfig {
|
||||
|
||||
@Bean
|
||||
public static PropertySourcesPlaceholderConfigurer propertyPlaceholderConfigurer() {
|
||||
return new PropertySourcesPlaceholderConfigurer();
|
||||
}
|
||||
}
|
||||
@Bean
|
||||
public static PropertySourcesPlaceholderConfigurer propertyPlaceholderConfigurer() {
|
||||
return new PropertySourcesPlaceholderConfigurer();
|
||||
}
|
||||
}
|
||||
----
|
||||
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
|
||||
.Kotlin
|
||||
@@ -6075,7 +6075,7 @@ will get properties from `application.properties` and `application.yml` files.
|
||||
|
||||
Built-in converter support provided by Spring allows simple type conversion (to `Integer`
|
||||
or `int` for example) to be automatically handled. Multiple comma-separated values can be
|
||||
automatically converted to String array without extra effort.
|
||||
automatically converted to `String` array without extra effort.
|
||||
|
||||
It is possible to provide a default value as following:
|
||||
|
||||
@@ -6099,8 +6099,8 @@ It is possible to provide a default value as following:
|
||||
class MovieRecommender(@Value("\${catalog.name:defaultCatalog}") private val catalog: String)
|
||||
----
|
||||
|
||||
A Spring `BeanPostProcessor` uses a `ConversionService` behind the scene to handle the
|
||||
process for converting the String value in `@Value` to the target type. If you want to
|
||||
A Spring `BeanPostProcessor` uses a `ConversionService` behind the scenes to handle the
|
||||
process for converting the `String` value in `@Value` to the target type. If you want to
|
||||
provide conversion support for your own custom type, you can provide your own
|
||||
`ConversionService` bean instance as the following example shows:
|
||||
|
||||
@@ -6126,7 +6126,7 @@ provide conversion support for your own custom type, you can provide your own
|
||||
|
||||
@Bean
|
||||
fun conversionService(): ConversionService {
|
||||
return DefaultFormattingConversionService().apply {
|
||||
return DefaultFormattingConversionService().apply {
|
||||
addConverter(MyCustomConverter())
|
||||
}
|
||||
}
|
||||
@@ -6315,7 +6315,7 @@ is meta-annotated with `@Component`, as the following example shows:
|
||||
// ...
|
||||
}
|
||||
----
|
||||
<1> The `Component` causes `@Service` to be treated in the same way as `@Component`.
|
||||
<1> The `@Component` causes `@Service` to be treated in the same way as `@Component`.
|
||||
|
||||
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
|
||||
.Kotlin
|
||||
@@ -6329,7 +6329,7 @@ is meta-annotated with `@Component`, as the following example shows:
|
||||
// ...
|
||||
}
|
||||
----
|
||||
<1> The `Component` causes `@Service` to be treated in the same way as `@Component`.
|
||||
<1> The `@Component` causes `@Service` to be treated in the same way as `@Component`.
|
||||
|
||||
You can also combine meta-annotations to create "`composed annotations`". For example,
|
||||
the `@RestController` annotation from Spring MVC is composed of `@Controller` and
|
||||
@@ -6591,7 +6591,7 @@ and using "`stub`" repositories instead:
|
||||
includeFilters = @Filter(type = FilterType.REGEX, pattern = ".*Stub.*Repository"),
|
||||
excludeFilters = @Filter(Repository.class))
|
||||
public class AppConfig {
|
||||
...
|
||||
// ...
|
||||
}
|
||||
----
|
||||
[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
|
||||
@@ -7157,7 +7157,7 @@ configuration, as shown in the following example:
|
||||
With Gradle 4.6 and later, the dependency should be declared in the `annotationProcessor`
|
||||
configuration, as shown in the following example:
|
||||
|
||||
[source,groovy,indent=0subs="verbatim,quotes,attributes"]
|
||||
[source,groovy,indent=0,subs="verbatim,quotes,attributes"]
|
||||
----
|
||||
dependencies {
|
||||
annotationProcessor "org.springframework:spring-context-indexer:{spring-version}"
|
||||
@@ -7631,7 +7631,7 @@ to reduce subtle bugs that can be hard to track down when operating in "`lite`"
|
||||
****
|
||||
|
||||
The `@Bean` and `@Configuration` annotations are discussed in depth in the following sections.
|
||||
First, however, we cover the various ways of creating a spring container using by
|
||||
First, however, we cover the various ways of creating a spring container by using
|
||||
Java-based configuration.
|
||||
|
||||
|
||||
@@ -7758,7 +7758,7 @@ To enable component scanning, you can annotate your `@Configuration` class as fo
|
||||
@Configuration
|
||||
@ComponentScan(basePackages = "com.acme") // <1>
|
||||
public class AppConfig {
|
||||
...
|
||||
// ...
|
||||
}
|
||||
----
|
||||
<1> This annotation enables component scanning.
|
||||
@@ -7892,6 +7892,7 @@ init-param):
|
||||
|
||||
`@Bean` is a method-level annotation and a direct analog of the XML `<bean/>` element.
|
||||
The annotation supports some of the attributes offered by `<bean/>`, such as:
|
||||
|
||||
* <<beans-factory-lifecycle-initializingbean, init-method>>
|
||||
* <<beans-factory-lifecycle-disposablebean, destroy-method>>
|
||||
* <<beans-factory-autowire,autowiring>>
|
||||
@@ -7980,7 +7981,7 @@ return type, as the following example shows:
|
||||
|
||||
However, this limits the visibility for advance type prediction to the specified
|
||||
interface type (`TransferService`). Then, with the full type (`TransferServiceImpl`)
|
||||
known to the container only once, the affected singleton bean has been instantiated.
|
||||
known to the container only once the affected singleton bean has been instantiated.
|
||||
Non-lazy singleton beans get instantiated according to their declaration order,
|
||||
so you may see different type matching results depending on when another component
|
||||
tries to match by a non-declared type (such as `@Autowired TransferServiceImpl`,
|
||||
@@ -8295,7 +8296,7 @@ as the following example shows:
|
||||
@Configuration
|
||||
public class AppConfig {
|
||||
|
||||
@Bean(name = "myThing")
|
||||
@Bean("myThing")
|
||||
public Thing thing() {
|
||||
return new Thing();
|
||||
}
|
||||
@@ -8388,7 +8389,7 @@ annotation, as the following example shows:
|
||||
=== Using the `@Configuration` annotation
|
||||
|
||||
`@Configuration` is a class-level annotation indicating that an object is a source of
|
||||
bean definitions. `@Configuration` classes declare beans through `@Bean` annotated
|
||||
bean definitions. `@Configuration` classes declare beans through `@Bean`-annotated
|
||||
methods. Calls to `@Bean` methods on `@Configuration` classes can also be used to define
|
||||
inter-bean dependencies. See <<beans-java-basic-concepts>> for a general introduction.
|
||||
|
||||
@@ -9137,7 +9138,7 @@ method that returns `true` or `false`. For example, the following listing shows
|
||||
val attrs = metadata.getAllAnnotationAttributes(Profile::class.java.name)
|
||||
if (attrs != null) {
|
||||
for (value in attrs["value"]!!) {
|
||||
if (context.environment.acceptsProfiles(Profiles .of(*value as Array<String>))) {
|
||||
if (context.environment.acceptsProfiles(Profiles.of(*value as Array<String>))) {
|
||||
return true
|
||||
}
|
||||
}
|
||||
@@ -9901,7 +9902,7 @@ as a way to provide a default definition for one or more beans. If any
|
||||
profile is enabled, the default profile does not apply.
|
||||
|
||||
You can change the name of the default profile by using `setDefaultProfiles()` on
|
||||
the `Environment` or ,declaratively, by using the `spring.profiles.default` property.
|
||||
the `Environment` or, declaratively, by using the `spring.profiles.default` property.
|
||||
|
||||
|
||||
|
||||
@@ -10720,7 +10721,7 @@ following example shows how to do so:
|
||||
----
|
||||
|
||||
It is also possible to add additional runtime filtering by using the `condition` attribute
|
||||
of the annotation that defines a <<expressions, `SpEL` expression>> , which should match
|
||||
of the annotation that defines a <<expressions, `SpEL` expression>>, which should match
|
||||
to actually invoke the method for a particular event.
|
||||
|
||||
The following example shows how our notifier can be rewritten to be invoked only if the
|
||||
@@ -10832,10 +10833,12 @@ The following example shows how to do so:
|
||||
Be aware of the following limitations when using asynchronous events:
|
||||
|
||||
* If an asynchronous event listener throws an `Exception`, it is not propagated to the
|
||||
caller. See `AsyncUncaughtExceptionHandler` for more details.
|
||||
caller. See
|
||||
{api-spring-framework}/aop/interceptor/AsyncUncaughtExceptionHandler.html[`AsyncUncaughtExceptionHandler`]
|
||||
for more details.
|
||||
* Asynchronous event listener methods cannot publish a subsequent event by returning a
|
||||
value. If you need to publish another event as the result of the processing, inject an
|
||||
{api-spring-framework}/aop/interceptor/AsyncUncaughtExceptionHandler.html[`ApplicationEventPublisher`]
|
||||
{api-spring-framework}/context/ApplicationEventPublisher.html[`ApplicationEventPublisher`]
|
||||
to publish the event manually.
|
||||
|
||||
|
||||
@@ -11093,8 +11096,8 @@ For a simple deployment of a Spring ApplicationContext as a Java EE RAR file:
|
||||
. Package
|
||||
all application classes into a RAR file (which is a standard JAR file with a different
|
||||
file extension).
|
||||
.Add all required library JARs into the root of the RAR archive.
|
||||
.Add a
|
||||
. Add all required library JARs into the root of the RAR archive.
|
||||
. Add a
|
||||
`META-INF/ra.xml` deployment descriptor (as shown in the {api-spring-framework}/jca/context/SpringContextResourceAdapter.html[javadoc for `SpringContextResourceAdapter`])
|
||||
and the corresponding Spring XML bean definition file(s) (typically
|
||||
`META-INF/applicationContext.xml`).
|
||||
|
||||
@@ -12,7 +12,7 @@ APIs as follows:
|
||||
* <<databuffers-buffer>> represents a byte buffer, which may be
|
||||
<<databuffers-buffer-pooled, pooled>>.
|
||||
* <<databuffers-utils>> offers utility methods for data buffers.
|
||||
* <<Codecs>> decode or encode streams data buffer streams into higher level objects.
|
||||
* <<Codecs>> decode or encode data buffer streams into higher level objects.
|
||||
|
||||
|
||||
|
||||
@@ -127,9 +127,9 @@ others that prefetch and cache data items internally, or is using operators such
|
||||
`filter`, `skip`, and others that leave out items, then
|
||||
`doOnDiscard(PooledDataBuffer.class, DataBufferUtils::release)` must be added to the
|
||||
composition chain to ensure such buffers are released prior to being discarded, possibly
|
||||
also as a result an error or cancellation signal.
|
||||
also as a result of an error or cancellation signal.
|
||||
. If a `Decoder` holds on to one or more data buffers in any other way, it must
|
||||
ensure they are released when fully read, or in case an error or cancellation signals that
|
||||
ensure they are released when fully read, or in case of an error or cancellation signals that
|
||||
take place before the cached data buffers have been read and released.
|
||||
|
||||
Note that `DataBufferUtils#join` offers a safe and efficient way to aggregate a data
|
||||
|
||||
@@ -357,7 +357,7 @@ the list:
|
||||
// Turn on:
|
||||
// - auto null reference initialization
|
||||
// - auto collection growing
|
||||
SpelParserConfiguration config = new SpelParserConfiguration(true,true);
|
||||
SpelParserConfiguration config = new SpelParserConfiguration(true, true);
|
||||
|
||||
ExpressionParser parser = new SpelExpressionParser(config);
|
||||
|
||||
@@ -465,7 +465,7 @@ following example shows how to do so:
|
||||
.Java
|
||||
----
|
||||
SpelParserConfiguration config = new SpelParserConfiguration(SpelCompilerMode.IMMEDIATE,
|
||||
this.getClass().getClassLoader());
|
||||
this.getClass().getClassLoader());
|
||||
|
||||
SpelExpressionParser parser = new SpelExpressionParser(config);
|
||||
|
||||
|
||||
@@ -382,7 +382,7 @@ properties:
|
||||
----
|
||||
|
||||
The following code snippets show some examples of how to retrieve and manipulate some of
|
||||
the properties of instantiated `Companies` and `Employees`:
|
||||
the properties of instantiated ``Company``s and ``Employee``s:
|
||||
|
||||
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
|
||||
.Java
|
||||
@@ -629,7 +629,7 @@ Note that all bean factories and application contexts automatically use a number
|
||||
built-in property editors, through their use of a `BeanWrapper` to
|
||||
handle property conversions. The standard property editors that the `BeanWrapper`
|
||||
registers are listed in the <<beans-beans-conversion, previous section>>.
|
||||
Additionally, `ApplicationContexts` also override or add additional editors to handle
|
||||
Additionally, ``ApplicationContext``s also override or add additional editors to handle
|
||||
resource lookups in a manner appropriate to the specific application context type.
|
||||
|
||||
Standard JavaBeans `PropertyEditor` instances are used to convert property values
|
||||
@@ -790,7 +790,7 @@ The following example shows how to create your own `PropertyEditorRegistrar` imp
|
||||
|
||||
See also the `org.springframework.beans.support.ResourceEditorRegistrar` for an example
|
||||
`PropertyEditorRegistrar` implementation. Notice how in its implementation of the
|
||||
`registerCustomEditors(..)` method ,it creates new instances of each property editor.
|
||||
`registerCustomEditors(..)` method, it creates new instances of each property editor.
|
||||
|
||||
The next example shows how to configure a `CustomEditorConfigurer` and inject an instance of our
|
||||
`CustomPropertyEditorRegistrar` into it:
|
||||
@@ -1347,6 +1347,7 @@ listing shows the definition of the `AnnotationFormatterFactory` interface:
|
||||
----
|
||||
|
||||
To create an implementation:
|
||||
|
||||
. Parameterize A to be the field `annotationType` with which you wish to associate
|
||||
formatting logic -- for example `org.springframework.format.annotation.DateTimeFormat`.
|
||||
. Have `getFieldTypes()` return the types of fields on which the annotation can be used.
|
||||
@@ -1470,7 +1471,7 @@ The following example uses `@DateTimeFormat` to format a `java.util.Date` as an
|
||||
.Kotlin
|
||||
----
|
||||
class MyModel(
|
||||
@DateTimeFormat(iso= ISO.DATE) private val date: Date
|
||||
@DateTimeFormat(iso=ISO.DATE) private val date: Date
|
||||
)
|
||||
----
|
||||
|
||||
|
||||
Reference in New Issue
Block a user