Spring/spring-framework
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Use discrete headings instead of titled blocks in reference manual

Browse Source 
This code switches from titled blocks to discrete headings in order to
properly format pseudo-section headers in the reference manual.

Closes gh-33447
This commit is contained in:
Sam Brannen
2024-08-29 15:39:10 +02:00
parent 29fdcf56eb
commit acf82e7c6d
2 changed files with 24 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -159,8 +159,10 @@ 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 In the preceding scenario, the container can use type matching with simple types if
you explicitly specify the type of the constructor argument via the `type` attribute, you explicitly specify the type of the constructor argument via the `type` attribute,
as the following example shows: as the following example shows:
@@ -172,10 +174,11 @@ as the following example shows:
<constructor-arg type="java.lang.String" value="42"/> <constructor-arg type="java.lang.String" value="42"/>
</bean> </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, You can use the `index` attribute to specify explicitly the index of constructor arguments,
as the following example shows: 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. resolves ambiguity where a constructor has two arguments of the same type.
NOTE: The index is 0-based. 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 You can also use the constructor parameter name for value disambiguation, as the following
example shows: example shows:
@@ -244,7 +248,6 @@ Kotlin::
constructor(val years: Int, val ultimateAnswer: String) constructor(val years: Int, val ultimateAnswer: String)
---- ----
====== ======
--
[[beans-setter-injection]] [[beans-setter-injection]]

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

@@ -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 Framework 4.3. Note also that there is no need to specify `@Autowired` if the target
bean defines only one constructor. 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 In the preceding scenario, using `@Autowired` works well and provides the desired
modularity, but determining exactly where the autowired bean definitions are declared is 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 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 get a type hierarchy of `RepositoryConfig` implementations. In this
way, navigating `@Configuration` classes and their dependencies becomes no different way, navigating `@Configuration` classes and their dependencies becomes no different
than the usual process of navigating interface-based code. than the usual process of navigating interface-based code.
--
TIP: If you want to influence the startup creation order of certain beans, consider TIP: If you want to influence the startup creation order of certain beans, consider
declaring some of them as `@Lazy` (for creation on first access instead of on startup) declaring some of them as `@Lazy` (for creation on first access instead of on startup)
@@ -594,8 +595,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 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. 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 Remember that `@Configuration` classes are ultimately bean definitions in the
container. In this series examples, we create a `@Configuration` class named `AppConfig` and 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 include it within `system-test-config.xml` as a `<bean/>` definition. Because
@@ -703,16 +706,16 @@ Kotlin::
---- ----
====== ======
NOTE: In `system-test-config.xml` file, the `AppConfig` `<bean/>` does not declare an `id` 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 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. 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` Similarly, the `DataSource` bean is only ever autowired by type, so an explicit bean `id`
is not strictly required. 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 Because `@Configuration` is meta-annotated with `@Component`, `@Configuration`-annotated
classes are automatically candidates for component scanning. Using the same scenario as 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. described in the previous example, we can redefine `system-test-config.xml` to take advantage of component-scanning.
@@ -736,7 +739,6 @@ The following example shows the modified `system-test-config.xml` file:
</bean> </bean>
</beans> </beans>
---- ----
--
[[beans-java-combining-java-centric]] [[beans-java-combining-java-centric]]
=== `@Configuration` Class-centric Use of XML with `@ImportResource` === `@Configuration` Class-centric Use of XML with `@ImportResource`