Merge remote-tracking branch 'origin/main' into JettyCoreHttpHandlerA…

…dapter

CODE_OF_CONDUCT.adoc

@@ -34,7 +34,7 @@ This Code of Conduct applies both within project spaces and in public spaces whe
 individual is representing the project or its community.
 
 Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by
-contacting a project maintainer at spring-code-of-conduct@pivotal.io . All complaints will
+contacting a project maintainer at spring-code-of-conduct@spring.io. All complaints will
 be reviewed and investigated and will result in a response that is deemed necessary and
 appropriate to the circumstances. Maintainers are obligated to maintain confidentiality
 with regard to the reporter of an incident.

CONTRIBUTING.md

@@ -18,7 +18,7 @@ First off, thank you for taking the time to contribute! :+1: :tada:
 
 This project is governed by the [Spring Code of Conduct](CODE_OF_CONDUCT.adoc).
 By participating you are expected to uphold this code.
-Please report unacceptable behavior to spring-code-of-conduct@pivotal.io.
+Please report unacceptable behavior to spring-code-of-conduct@spring.io.
 
 ### How to Contribute
 

README.md

@@ -6,7 +6,7 @@ Spring provides everything required beyond the Java programming language for cre
 
 ## Code of Conduct
 
-This project is governed by the [Spring Code of Conduct](CODE_OF_CONDUCT.adoc). By participating, you are expected to uphold this code of conduct. Please report unacceptable behavior to spring-code-of-conduct@pivotal.io.
+This project is governed by the [Spring Code of Conduct](CODE_OF_CONDUCT.adoc). By participating, you are expected to uphold this code of conduct. Please report unacceptable behavior to spring-code-of-conduct@spring.io.
 
 ## Access to Binaries
 

buildSrc/gradle.properties

@@ -1,2 +1,2 @@
 org.gradle.caching=true
-javaFormatVersion=0.0.41
+javaFormatVersion=0.0.42

buildSrc/src/main/java/org/springframework/build/CheckstyleConventions.java

@@ -64,7 +64,7 @@ private static void configureNoHttpPlugin(Project project) {
 		NoHttpExtension noHttp = project.getExtensions().getByType(NoHttpExtension.class);
 		noHttp.setAllowlistFile(project.file("src/nohttp/allowlist.lines"));
 		noHttp.getSource().exclude("**/test-output/**", "**/.settings/**",
-				"**/.classpath", "**/.project", "**/.gradle/**");
+				"**/.classpath", "**/.project", "**/.gradle/**", "**/node_modules/**");
 		List<String> buildFolders = List.of("bin", "build", "out");
 		project.allprojects(subproject -> {
 			Path rootPath = project.getRootDir().toPath();

framework-docs/modules/ROOT/pages/core/beans/annotation-config/autowired-qualifiers.adoc

@@ -154,30 +154,32 @@ 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 chooses the
-same-named candidate, if any.
+(that is, the field name or parameter name) against the target bean names and chooses
+the same-named candidate, if any (either by bean name or by associated alias).
 
 Since version 6.1, this requires the `-parameters` Java compiler flag to be present.
+As of 6.2, the container applies fast shortcut resolution for bean name matches,
+bypassing the full type matching algorithm when the parameter name matches the
+bean name and no type, qualifier or primary conditions override the match. It is
+therefore recommendable for your parameter names to match the target bean names.
 ====
 
-That said, if you intend to express annotation-driven injection by name, do not
-primarily use `@Autowired`, even if it is capable of selecting by bean name among
-type-matching candidates. Instead, use the JSR-250 `@Resource` annotation, which is
-semantically defined to identify a specific target component by its unique name, with
-the declared type being irrelevant for the matching process. `@Autowired` has rather
-different semantics: After selecting candidate beans by type, the specified `String`
+As an alternative for injection by name, consider the JSR-250 `@Resource` annotation
+which is semantically defined to identify a specific target component by its unique name,
+with the declared type being irrelevant for the matching process. `@Autowired` has rather
+different semantics: after selecting candidate beans by type, the specified `String`
 qualifier value is considered within those type-selected candidates only (for example,
 matching an `account` qualifier against beans marked with the same qualifier label).
 
 For beans that are themselves defined as a collection, `Map`, or array type, `@Resource`
 is a fine solution, referring to the specific collection or array bean by unique name.
-That said, as of 4.3, you can match collection, `Map`, and array types through Spring's
+That said, you can match collection, `Map`, and array types through Spring's
 `@Autowired` type matching algorithm as well, as long as the element type information
 is preserved in `@Bean` return type signatures or collection inheritance hierarchies.
 In this case, you can use qualifier values to select among same-typed collections,
 as outlined in the previous paragraph.
 
-As of 4.3, `@Autowired` also considers self references for injection (that is, references
+`@Autowired` also considers self references for injection (that is, references
 back to the bean that is currently injected). Note that self injection is a fallback.
 Regular dependencies on other components always have precedence. In that sense, self
 references do not participate in regular candidate selection and are therefore in

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

@@ -73,23 +73,37 @@ runtime (concurrently with live access to the factory) is not officially support
 lead to concurrent access exceptions, inconsistent state in the bean container, or both.
 ====
 
+
+
 [[beans-definition-overriding]]
 == Overriding Beans
 
-Bean overriding is happening when a bean is registered using an identifier that is
-already allocated. While bean overriding is possible, it makes the configuration harder
-to read and this feature will be deprecated in a future release.
+Bean overriding occurs when a bean is registered using an identifier that is already
+allocated. While bean overriding is possible, it makes the configuration harder to read.
+
+WARNING: Bean overriding will be deprecated in a future release.
 
 To disable bean overriding altogether, you can set the `allowBeanDefinitionOverriding`
-to `false` on the `ApplicationContext` before it is refreshed. In such setup, an
+flag to `false` on the `ApplicationContext` before it is refreshed. In such a setup, an
 exception is thrown if bean overriding is used.
 
-By default, the container logs every bean overriding at `INFO` level so that you can
-adapt your configuration accordingly. While not recommended, you can silence those logs
-by setting the `allowBeanDefinitionOverriding` flag to `true`.
+By default, the container logs every attempt to override a bean at `INFO` level so that
+you can adapt your configuration accordingly. While not recommended, you can silence
+those logs by setting the `allowBeanDefinitionOverriding` flag to `true`.
+
+.Java Configuration
+****
+If you use Java Configuration, a corresponding `@Bean` method always silently overrides
+a scanned bean class with the same component name as long as the return type of the
+`@Bean` method matches that bean class. This simply means that the container will call
+the `@Bean` factory method in favor of any pre-declared constructor on the bean class.
+****
+
+NOTE: We acknowledge that overriding beans in test scenarios is convenient, and there is
+explicit support for this as of Spring Framework 6.2. Please refer to
+xref:testing/testcontext-framework/bean-overriding.adoc[this section] for more details.
+
 
-NOTE: We acknowledge that overriding beans in a test is convenient, and there is
-explicit support for this. For more details please refer to xref:testing/testcontext-framework/bean-overriding.adoc[this section].
 
 [[beans-beanname]]
 == Naming Beans

framework-docs/modules/ROOT/pages/core/validation/beanvalidation.adoc

@@ -287,32 +287,7 @@ As the preceding example shows, a `ConstraintValidator` implementation can have
 You can integrate the method validation feature of Bean Validation into a
 Spring context through a `MethodValidationPostProcessor` bean definition:
 
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
-----
-	import org.springframework.validation.beanvalidation.MethodValidationPostProcessor;
-
-	@Configuration
-	public class AppConfig {
-
-		@Bean
-		public static MethodValidationPostProcessor validationPostProcessor() {
-			return new MethodValidationPostProcessor();
-		}
-	}
-
-----
-
-XML::
-+
-[source,xml,indent=0,subs="verbatim,quotes",role="secondary"]
-----
-	<bean class="org.springframework.validation.beanvalidation.MethodValidationPostProcessor"/>
-----
-======
+include-code::./ApplicationConfiguration[tag=snippet,indent=0]
 
 To be eligible for Spring-driven method validation, target classes need to be annotated
 with Spring's `@Validated` annotation, which can optionally also declare the validation
@@ -345,36 +320,7 @@ By default, `jakarta.validation.ConstraintViolationException` is raised with the
 you can have `MethodValidationException` raised instead with ``ConstraintViolation``s
 adapted to `MessageSourceResolvable` errors. To enable set the following flag:
 
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
-----
-	import org.springframework.validation.beanvalidation.MethodValidationPostProcessor;
-
-	@Configuration
-	public class AppConfig {
-
-		@Bean
-		public static MethodValidationPostProcessor validationPostProcessor() {
-			MethodValidationPostProcessor processor = new MethodValidationPostProcessor();
-			processor.setAdaptConstraintViolations(true);
-			return processor;
-		}
-	}
-
-----
-
-XML::
-+
-[source,xml,indent=0,subs="verbatim,quotes",role="secondary"]
-----
-	<bean class="org.springframework.validation.beanvalidation.MethodValidationPostProcessor">
-		<property name="adaptConstraintViolations" value="true"/>
-	</bean>
-----
-======
+include-code::./ApplicationConfiguration[tag=snippet,indent=0]
 
 `MethodValidationException` contains a list of ``ParameterValidationResult``s which
 group errors by method parameter, and each exposes a `MethodParameter`, the argument

framework-docs/modules/ROOT/pages/index.adoc

@@ -29,8 +29,6 @@ Brannen, Ramnivas Laddad, Arjen Poutsma, Chris Beams, Tareq Abedrabbo, Andy Clem
 Syer, Oliver Gierke, Rossen Stoyanchev, Phillip Webb, Rob Winch, Brian Clozel, Stephane
 Nicoll, Sebastien Deleuze, Jay Bryant, Mark Paluch
 
-Copyright © 2002 - 2024 VMware, Inc. All Rights Reserved.
-
 Copies of this document may be made for your own use and for distribution to others,
 provided that you do not charge any fee for such copies and further provided that each
-copy contains this Copyright Notice, whether distributed in print or electronically.
+copy contains the Copyright Notice, whether distributed in print or electronically.

framework-docs/modules/ROOT/pages/integration/rest-clients.adoc

@@ -1007,7 +1007,8 @@ method parameters:
   is supported for non-String values.
 
 | `@RequestAttribute`
-| Provide an `Object` to add as a request attribute. Only supported by `WebClient`.
+| Provide an `Object` to add as a request attribute. Only supported by `RestClient`
+  and `WebClient`.
 
 | `@RequestBody`
 | Provide the body of the request either as an Object to be serialized, or a

framework-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-mockitobean.adoc

@@ -1,32 +1,63 @@
 [[spring-testing-annotation-beanoverriding-mockitobean]]
 = `@MockitoBean` and `@MockitoSpyBean`
 
-`@MockitoBean` and `@MockitoSpyBean` are used on test class fields to override beans in
-the test's `ApplicationContext` with a Mockito mock or spy, respectively. In the latter
-case, the original bean definition is not replaced, but instead an early instance of the
-bean is captured and wrapped by the spy.
+`@MockitoBean` and `@MockitoSpyBean` are used on fields in test classes to override beans
+in the test's `ApplicationContext` with a Mockito mock or spy, respectively. In the
+latter case, the original bean definition is not replaced, but instead an early instance
+of the bean is captured and wrapped by the spy.
 
-By default, the annotated field's type is used to search for candidate definitions to
-override, but note that `@Qualifier` annotations are also taken into account for the
-purpose of matching. Users can also make things entirely explicit by specifying a bean
-`name` in the annotation.
+By default, the annotated field's type is used to search for candidate bean definitions
+to override. If multiple candidates match, `@Qualifier` can be provided to narrow the
+candidate to override. Alternatively, a candidate whose bean definition name matches the
+name of the field will match.
+
+To use a by-name override rather than a by-type override, specify the `name` attribute
+of the annotation.
+
+[WARNING]
+====
+Qualifiers, including the name of the field, are used to determine if a separate
+`ApplicationContext` needs to be created. If you are using this feature to mock or spy
+the same bean in several tests, make sure to name the field consistently to avoid
+creating unnecessary contexts.
+====
 
 Each annotation also defines Mockito-specific attributes to fine-tune the mocking details.
 
 The `@MockitoBean` annotation uses the `REPLACE_OR_CREATE_DEFINITION`
 xref:testing/testcontext-framework/bean-overriding.adoc#testcontext-bean-overriding-custom[strategy for test bean overriding].
-
-It requires that at most one matching candidate definition exists if a bean name
-is specified, or exactly one if no bean name is specified.
+If no existing bean definition matches, a new bean definition is created on the fly.
 
 The `@MockitoSpyBean` annotation uses the `WRAP_BEAN`
 xref:testing/testcontext-framework/bean-overriding.adoc#testcontext-bean-overriding-custom[strategy],
-and the original instance is wrapped in a Mockito spy.
+and the original instance is wrapped in a Mockito spy. This strategy requires that
+exactly one candidate bean definition exists.
+
+The following example shows how to use the default behavior of the `@MockitoBean` annotation:
+
+[tabs]
+======
+Java::
++
+[source,java,indent=0,subs="verbatim,quotes",role="primary"]
+----
+	class OverrideBeanTests {
+		@MockitoBean // <1>
+		CustomService customService;
 
-It requires that exactly one candidate definition exists.
+		// test case body...
+	}
+----
+<1> Replace the bean with type `CustomService` with a Mockito `mock`.
+======
+
+In the example above, we are creating a mock for `CustomService`. If more than one bean
+of that type exists, the bean named `customService` is considered. Otherwise, the test
+will fail, and you will need to provide a qualifier of some sort to identify which of the
+`CustomService` beans you want to override. If no such bean exists, a bean definition
+will be created with an auto-generated bean name.
 
-The following example shows how to configure the bean name via `@MockitoBean` and
-`@MockitoSpyBean`:
+The following example uses a by-name lookup, rather than a by-type lookup:
 
 [tabs]
 ======
@@ -35,17 +66,56 @@ Java::
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
 ----
 	class OverrideBeanTests {
+		@MockitoBean(name = "service") // <1>
+		CustomService customService;
+
+		// test case body...
+
+	}
+----
+<1> Replace the bean named `service` with a Mockito `mock`.
+======
 
-		@MockitoBean(name = "service1")  // <1>
-		private CustomService mockService;
+If no bean definition named `service` exists, one is created.
 
-		@MockitoSpyBean(name = "service2") // <2>
-		private CustomService spyService; // <3>
+The following example shows how to use the default behavior of the `@MockitoSpyBean` annotation:
+
+[tabs]
+======
+Java::
++
+[source,java,indent=0,subs="verbatim,quotes",role="primary"]
+----
+	class OverrideBeanTests {
+		@MockitoSpyBean // <1>
+		CustomService customService;
 
 		// test case body...
 	}
 ----
-<1> Mark `mockService` as a Mockito mock override of bean `service1` in this test class.
-<2> Mark `spyService` as a Mockito spy override of bean `service2` in this test class.
-<3> The fields will be injected with the Mockito mock and spy, respectively.
+<1> Wrap the bean with type `CustomService` with a Mockito `spy`.
+======
+
+In the example above, we are wrapping the bean with type `CustomService`. If more than
+one bean of that type exists, the bean named `customService` is considered. Otherwise,
+the test will fail, and you will need to provide a qualifier of some sort to identify
+which of the `CustomService` beans you want to spy.
+
+The following example uses a by-name lookup, rather than a by-type lookup:
+
+[tabs]
+======
+Java::
++
+[source,java,indent=0,subs="verbatim,quotes",role="primary"]
+----
+	class OverrideBeanTests {
+		@MockitoSpyBean(name = "service") // <1>
+		CustomService customService;
+
+		// test case body...
+
+	}
+----
+<1> Wrap the bean named `service` with a Mockito `spy`.
 ======