Merge branch '6.1.x'

framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-collaborators.adoc

@@ -159,10 +159,12 @@ Kotlin::
 ----
 ======
 
-.[[beans-factory-ctor-arguments-type]]Constructor argument type matching
---
+[discrete]
+[[beans-factory-ctor-arguments-type]]
+==== Constructor argument type matching
+
 In the preceding scenario, the container can use type matching with simple types if
-you explicitly specify the type of the constructor argument by using the `type` attribute,
+you explicitly specify the type of the constructor argument via the `type` attribute,
 as the following example shows:
 
 [source,xml,indent=0,subs="verbatim,quotes"]
@@ -172,10 +174,11 @@ as the following example shows:
 		<constructor-arg type="java.lang.String" value="42"/>
 	</bean>
 ----
---
 
-.[[beans-factory-ctor-arguments-index]]Constructor argument index
---
+[discrete]
+[[beans-factory-ctor-arguments-index]]
+==== Constructor argument index
+
 You can use the `index` attribute to specify explicitly the index of constructor arguments,
 as the following example shows:
 
@@ -191,10 +194,11 @@ In addition to resolving the ambiguity of multiple simple values, specifying an
 resolves ambiguity where a constructor has two arguments of the same type.
 
 NOTE: The index is 0-based.
---
 
-.[[beans-factory-ctor-arguments-name]]Constructor argument name
---
+[discrete]
+[[beans-factory-ctor-arguments-name]]
+==== Constructor argument name
+
 You can also use the constructor parameter name for value disambiguation, as the following
 example shows:
 
@@ -244,7 +248,6 @@ Kotlin::
 	constructor(val years: Int, val ultimateAnswer: String)
 ----
 ======
---
 
 
 [[beans-setter-injection]]

framework-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc

@@ -116,7 +116,7 @@ the configuration model, in that references to other beans must be valid Java sy
 Fortunately, solving this problem is simple. As
 xref:core/beans/java/bean-annotation.adoc#beans-java-dependencies[we already discussed],
 a `@Bean` method can have an arbitrary number of parameters that describe the bean
-dependencies. Consider the following more real-world scenario with several `@Configuration`
+dependencies. Consider the following more realistic scenario with several `@Configuration`
 classes, each depending on beans declared in the others:
 
 [tabs]
@@ -331,8 +331,10 @@ TIP: Constructor injection in `@Configuration` classes is only supported as of S
 Framework 4.3. Note also that there is no need to specify `@Autowired` if the target
 bean defines only one constructor.
 
-.[[beans-java-injecting-imported-beans-fq]]Fully-qualifying imported beans for ease of navigation
---
+[discrete]
+[[beans-java-injecting-imported-beans-fq]]
+==== Fully-qualifying imported beans for ease of navigation
+
 In the preceding scenario, using `@Autowired` works well and provides the desired
 modularity, but determining exactly where the autowired bean definitions are declared is
 still somewhat ambiguous. For example, as a developer looking at `ServiceConfig`, how do
@@ -501,7 +503,6 @@ Now `ServiceConfig` is loosely coupled with respect to the concrete
 get a type hierarchy of `RepositoryConfig` implementations. In this
 way, navigating `@Configuration` classes and their dependencies becomes no different
 than the usual process of navigating interface-based code.
---
 
 
 [[beans-java-startup]]
@@ -631,8 +632,10 @@ that uses Spring XML, it is easier to create `@Configuration` classes on an
 as-needed basis and include them from the existing XML files. Later in this section, we cover the
 options for using `@Configuration` classes in this kind of "`XML-centric`" situation.
 
-.[[beans-java-combining-xml-centric-declare-as-bean]]Declaring `@Configuration` classes as plain Spring `<bean/>` elements
---
+[discrete]
+[[beans-java-combining-xml-centric-declare-as-bean]]
+==== Declaring `@Configuration` classes as plain Spring `<bean/>` elements
+
 Remember that `@Configuration` classes are ultimately bean definitions in the
 container. In this series examples, we create a `@Configuration` class named `AppConfig` and
 include it within `system-test-config.xml` as a `<bean/>` definition. Because
@@ -740,16 +743,16 @@ Kotlin::
 ----
 ======
 
-
 NOTE: In `system-test-config.xml` file, the `AppConfig` `<bean/>` does not declare an `id`
 element. While it would be acceptable to do so, it is unnecessary, given that no other bean
 ever refers to it, and it is unlikely to be explicitly fetched from the container by name.
 Similarly, the `DataSource` bean is only ever autowired by type, so an explicit bean `id`
 is not strictly required.
---
 
-.[[beans-java-combining-xml-centric-component-scan]] Using <context:component-scan/> to pick up `@Configuration` classes
---
+[discrete]
+[[beans-java-combining-xml-centric-component-scan]]
+==== Using <context:component-scan/> to pick up `@Configuration` classes
+
 Because `@Configuration` is meta-annotated with `@Component`, `@Configuration`-annotated
 classes are automatically candidates for component scanning. Using the same scenario as
 described in the previous example, we can redefine `system-test-config.xml` to take advantage of component-scanning.
@@ -773,7 +776,6 @@ The following example shows the modified `system-test-config.xml` file:
 		</bean>
 	</beans>
 ----
---
 
 [[beans-java-combining-java-centric]]
 === `@Configuration` Class-centric Use of XML with `@ImportResource`