Merge branch '6.1.x'

# Conflicts:
#	framework-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc

framework-docs/modules/ROOT/pages/core/beans/definition.adoc

@@ -250,6 +250,10 @@ For details about the mechanism for supplying arguments to the constructor (if r
 and setting object instance properties after the object is constructed, see
 xref:core/beans/dependencies/factory-collaborators.adoc[Injecting Dependencies].
 
+NOTE: In the case of constructor arguments, the container can select a corresponding
+constructor among several overloaded constructors. That said, to avoid ambiguities,
+it is recommended to keep your constructor signatures as straightforward as possible.
+
 
 [[beans-factory-class-static-factory-method]]
 === Instantiation with a Static Factory Method
@@ -310,6 +314,24 @@ For details about the mechanism for supplying (optional) arguments to the factor
 and setting object instance properties after the object is returned from the factory,
 see xref:core/beans/dependencies/factory-properties-detailed.adoc[Dependencies and Configuration in Detail].
 
+NOTE: In the case of factory method arguments, the container can select a corresponding
+method among several overloaded methods of the same name. That said, to avoid ambiguities,
+it is recommended to keep your factory method signatures as straightforward as possible.
+
+[TIP]
+====
+A typical problematic case with factory method overloading is Mockito with its many
+overloads of the `mock` method. Choose the most specific variant of `mock` possible:
+
+[source,xml,indent=0,subs="verbatim,quotes"]
+----
+	<bean id="clientService" class="org.mockito.Mockito" factory-method="mock">
+		<constructor-arg type="java.lang.Class" value="examples.ClientService"/>
+		<constructor-arg type="java.lang.String" value="clientService"/>
+	</bean>
+----
+====
+
 
 [[beans-factory-class-instance-factory-method]]
 === Instantiation by Using an Instance Factory Method
@@ -432,8 +454,8 @@ Kotlin::
 ======
 
 This approach shows that the factory bean itself can be managed and configured through
-dependency injection (DI). See xref:core/beans/dependencies/factory-properties-detailed.adoc[Dependencies and Configuration in Detail]
-.
+dependency injection (DI).
+See xref:core/beans/dependencies/factory-properties-detailed.adoc[Dependencies and Configuration in Detail].
 
 NOTE: In Spring documentation, "factory bean" refers to a bean that is configured in the
 Spring container and that creates objects through an
@@ -460,5 +482,3 @@ cases into account and returns the type of object that a `BeanFactory.getBean` c
 going to return for the same bean name.
 
 
-
-

framework-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc

@@ -74,10 +74,11 @@ Kotlin::
 ----
 ======
 
-Used at the class level as above, the annotation indicates a default for all methods of
-the declaring class (as well as its subclasses). Alternatively, each method can be
-annotated individually. See xref:data-access/transaction/declarative/annotations.adoc#transaction-declarative-annotations-method-visibility[method visibility] for
-further details on which methods Spring considers transactional. Note that a class-level
+Used at the class level as above, the annotation indicates a default for all methods
+of the declaring class (as well as its subclasses). Alternatively, each method can be
+annotated individually. See
+xref:data-access/transaction/declarative/annotations.adoc#transaction-declarative-annotations-method-visibility[method visibility]
+for further details on which methods Spring considers transactional. Note that a class-level
 annotation does not apply to ancestor classes up the class hierarchy; in such a scenario,
 inherited methods need to be locally redeclared in order to participate in a
 subclass-level annotation.
@@ -436,7 +437,8 @@ properties of the `@Transactional` annotation:
 | Optional array of exception name patterns that must not cause rollback.
 |===
 
-TIP: See xref:data-access/transaction/declarative/rolling-back.adoc#transaction-declarative-rollback-rules[Rollback rules]
+TIP: See
+xref:data-access/transaction/declarative/rolling-back.adoc#transaction-declarative-rollback-rules[Rollback rules]
 for further details on rollback rule semantics, patterns, and warnings
 regarding possible unintentional matches for pattern-based rollback rules.
 

framework-docs/modules/ROOT/pages/data-access/transaction/declarative/rolling-back.adoc

@@ -24,8 +24,8 @@ Vavr's `Try` method to trigger transaction rollbacks when it returns a 'Failure'
 This allows you to handle functional-style errors using Try and have the transaction
 automatically rolled back in case of a failure. For more information on Vavr's Try,
 refer to the https://docs.vavr.io/#_try[official Vavr documentation].
-
 Here's an example of how to use Vavr's Try with a transactional method:
+
 [tabs]
 ======
 Java::
@@ -42,6 +42,32 @@ Java::
 ----
 ======
 
+As of Spring Framework 6.1, there is also special treatment of `CompletableFuture`
+(and general `Future`) return values, triggering a rollback for such a handle if it
+was exceptionally completed at the time of being returned from the original method.
+This is intended for `@Async` methods where the actual method implementation may
+need to comply with a `CompletableFuture` signature (auto-adapted to an actual
+asynchronous handle for a call to the proxy by `@Async` processing at runtime),
+preferring exposure in the returned handle rather than rethrowing an exception:
+
+[tabs]
+======
+Java::
++
+[source,java,indent=0,subs="verbatim,quotes",role="primary"]
+----
+	@Transactional @Async
+	public CompletableFuture<String> myTransactionalMethod() {
+		try {
+			return CompletableFuture.completedFuture(delegate.myDataAccessOperation());
+		}
+		catch (DataAccessException ex) {
+			return CompletableFuture.failedFuture(ex);
+		}
+	}
+----
+======
+
 Checked exceptions that are thrown from a transactional method do not result in a rollback
 in the default configuration. You can configure exactly which `Exception` types mark a
 transaction for rollback, including checked exceptions by specifying _rollback rules_.

framework-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-setup-options.adoc

@@ -111,7 +111,8 @@ a mock service with Mockito:
 [source,xml,indent=0,subs="verbatim,quotes"]
 ----
 	<bean id="accountService" class="org.mockito.Mockito" factory-method="mock">
-		<constructor-arg value="org.example.AccountService"/>
+		<constructor-arg type="java.lang.Class" value="org.example.AccountService"/>
+		<constructor-arg type="java.lang.String" value="accountService"/>
 	</bean>
 ----