Release v6.0.7

2026-06-08 17:33:33 +00:00 · 2023-03-20 09:37:53 +00:00
4473 changed files with 123527 additions and 201359 deletions
@@ -1,32 +0,0 @@
-name: Deploy Docs
-on:
-  push:
-    branches-ignore: [ gh-pages ]
-    tags: '**'
-  repository_dispatch:
-    types: request-build-reference # legacy
-  schedule:
-  - cron: '0 10 * * *' # Once per day at 10am UTC
-  workflow_dispatch:
-permissions:
-  actions: write
-jobs:
-  build:
-    runs-on: ubuntu-latest
-    if: github.repository_owner == 'spring-projects'
-    steps:
-    - name: Checkout
-      uses: actions/checkout@v3
-      with:
-        ref: docs-build
-        fetch-depth: 1
-    - name: Dispatch (partial build)
-      if: github.ref_type == 'branch'
-      env:
-        GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-      run: gh workflow run deploy-docs.yml -r $(git rev-parse --abbrev-ref HEAD) -f build-refname=${{ github.ref_name }}
-    - name: Dispatch (full build)
-      if: github.ref_type == 'tag'
-      env:
-        GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-      run: gh workflow run deploy-docs.yml -r $(git rev-parse --abbrev-ref HEAD)
@@ -21,7 +21,8 @@ derby.log
 /build
 buildSrc/build
 /spring-*/build
-/framework-*/build
+/framework-bom/build
+/framework-docs/build
 /integration-tests/build
 /src/asciidoc/build
 spring-test/test-output/
@@ -49,5 +50,3 @@ atlassian-ide-plugin.xml

 # VS Code
 .vscode/
-
-cached-antora-playbook.yml
@@ -0,0 +1,36 @@
+Juergen Hoeller <jhoeller@vmware.com>
+Juergen Hoeller <jhoeller@vmware.com> <jhoeller@pivotal.io>
+Juergen Hoeller <jhoeller@vmware.com> <jhoeller@gopivotal.com>
+Rossen Stoyanchev <rstoyanchev@vmware.com>
+Rossen Stoyanchev <rstoyanchev@vmware.com> <rstoyanchev@pivotal.io>
+Rossen Stoyanchev <rstoyanchev@vmware.com> <rstoyanchev@gopivotal.com>
+Phillip Webb <pwebb@vmware.com>
+Phillip Webb <pwebb@vmware.com> <pwebb@pivotal.io>
+Phillip Webb <pwebb@vmware.com> <pwebb@gopivotal.com>
+Chris Beams <cbeams@vmware.com>
+Chris Beams <cbeams@vmware.com> <cbeams@pivotal.io>
+Chris Beams <cbeams@vmware.com> <cbeams@gopivotal.com>
+Arjen Poutsma <poutsmaa@vmware.com>
+Arjen Poutsma <poutsmaa@vmware.com> <apoutsma@pivotal.io>
+Arjen Poutsma <poutsmaa@vmware.com> <apoutsma@gopivotal.com>
+Arjen Poutsma <poutsmaa@vmware.com> <poutsma@mac.com>
+Arjen Poutsma <poutsmaa@vmware.com> <apoutsma@vmware.com>
+Oliver Drotbohm <odrotbohm@vmware.com>
+Oliver Drotbohm <odrotbohm@vmware.com> <ogierke@vmware.com>
+Oliver Drotbohm <odrotbohm@vmware.com> <ogierke@pivotal.io>
+Oliver Drotbohm <odrotbohm@vmware.com> <ogierke@gopivotal.com>
+Dave Syer <dsyer@vmware.com>
+Dave Syer <dsyer@vmware.com> <dsyer@pivotal.io>
+Dave Syer <dsyer@vmware.com> <dsyer@gopivotal.com>
+Dave Syer <dsyer@vmware.com> <david_syer@hotmail.com>
+Andy Clement <aclement@vmware.com>
+Andy Clement <aclement@vmware.com> <aclement@pivotal.io>
+Andy Clement <aclement@vmware.com> <aclement@gopivotal.com>
+Andy Clement <aclement@vmware.com> <andrew.clement@gmail.com>
+Sam Brannen <sbrannen@vmware.com>
+Sam Brannen <sbrannen@vmware.com> <sbrannen@pivotal.io>
+Sam Brannen <sbrannen@vmware.com> <sam@sambrannen.com>
+Simon Basle <sbasle@vmware.com>
+Simon Baslé <sbasle@vmware.com>
+<dmitry.katsubo@gmail.com> <dmitry.katsubo@gmai.com>
+Nick Williams <nicholas@nicholaswilliams.net>
@@ -1,3 +1,3 @@
 # Enable auto-env through the sdkman_auto_env config
 # Add key=value pairs of SDKs to use below
-java=17.0.10-librca
+java=17.0.6-librca
@@ -123,13 +123,13 @@ define the source file coding standards we use along with some IDEA editor setti

 ### Reference Docs

-The reference documentation is authored in [Asciidoctor](https://asciidoctor.org/) format
-using [Antora](https://docs.antora.org/antora/latest/). The source files for the documentation
-reside in the [framework-docs/modules/ROOT](framework-docs/modules/ROOT) directory. For
-trivial changes, you may be able to browse, edit source files, and submit directly from GitHub.
+The reference documentation is in the [framework-docs/src/docs/asciidoc](framework-docs/src/docs/asciidoc) directory, in
+[Asciidoctor](https://asciidoctor.org/) format. For trivial changes, you may be able to browse,
+edit source files, and submit directly from GitHub.

-When making changes locally, execute `./gradlew antora` and then browse the results under
-`framework-docs/build/site/index.html`.
+When making changes locally, execute `./gradlew :framework-docs:asciidoctor` and then browse the result under
+`framework-docs/build/docs/ref-docs/html5/index.html`.

 Asciidoctor also supports live editing. For more details see
 [AsciiDoc Tooling](https://docs.asciidoctor.org/asciidoctor/latest/tooling/).
+
@@ -1,8 +1,8 @@
-# <img src="framework-docs/src/docs/spring-framework.png" width="80" height="80"> Spring Framework [![Build Status](https://ci.spring.io/api/v1/teams/spring-framework/pipelines/spring-framework-6.1.x/jobs/build/badge)](https://ci.spring.io/teams/spring-framework/pipelines/spring-framework-6.1.x?groups=Build") [![Revved up by Develocity](https://img.shields.io/badge/Revved%20up%20by-Develocity-06A0CE?logo=Gradle&labelColor=02303A)](https://ge.spring.io/scans?search.rootProjectNames=spring)
+# <img src="framework-docs/src/docs/spring-framework.png" width="80" height="80"> Spring Framework [![Build Status](https://ci.spring.io/api/v1/teams/spring-framework/pipelines/spring-framework-6.0.x/jobs/build/badge)](https://ci.spring.io/teams/spring-framework/pipelines/spring-framework-6.0.x?groups=Build") [![Revved up by Gradle Enterprise](https://img.shields.io/badge/Revved%20up%20by-Gradle%20Enterprise-06A0CE?logo=Gradle&labelColor=02303A)](https://ge.spring.io/scans?search.rootProjectNames=spring)

 This is the home of the Spring Framework: the foundation for all [Spring projects](https://spring.io/projects). Collectively the Spring Framework and the family of Spring projects are often referred to simply as "Spring". 

-Spring provides everything required beyond the Java programming language for creating enterprise applications for a wide range of scenarios and architectures. Please read the [Overview](https://docs.spring.io/spring-framework/reference/overview.html) section of the reference documentation for a more complete introduction.
+Spring provides everything required beyond the Java programming language for creating enterprise applications for a wide range of scenarios and architectures. Please read the [Overview](https://docs.spring.io/spring/docs/current/spring-framework-reference/overview.html#spring-introduction) section as reference for a more complete introduction.

 ## Code of Conduct

@@ -14,7 +14,7 @@ For access to artifacts or a distribution zip, see the [Spring Framework Artifac

 ## Documentation

-The Spring Framework maintains reference documentation ([published](https://docs.spring.io/spring-framework/reference/) and [source](framework-docs/modules/ROOT)), GitHub [wiki pages](https://github.com/spring-projects/spring-framework/wiki), and an
+The Spring Framework maintains reference documentation ([published](https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/) and [source](framework-docs/src/docs/asciidoc)), GitHub [wiki pages](https://github.com/spring-projects/spring-framework/wiki), and an
 [API reference](https://docs.spring.io/spring-framework/docs/current/javadoc-api/). There are also [guides and tutorials](https://spring.io/guides) across Spring projects.

 ## Micro-Benchmarks
@@ -31,7 +31,7 @@ Information regarding CI builds can be found in the [Spring Framework Concourse

 ## Stay in Touch

-Follow [@SpringCentral](https://twitter.com/springcentral), [@SpringFramework](https://twitter.com/springframework), and its [team members](https://twitter.com/springframework/lists/team/members) on 𝕏. In-depth articles can be found at [The Spring Blog](https://spring.io/blog/), and releases are announced via our [releases feed](https://spring.io/blog/category/releases).
+Follow [@SpringCentral](https://twitter.com/springcentral), [@SpringFramework](https://twitter.com/springframework), and its [team members](https://twitter.com/springframework/lists/team/members) on Twitter. In-depth articles can be found at [The Spring Blog](https://spring.io/blog/), and releases are announced via our [news feed](https://spring.io/blog/category/news).

 ## License

@@ -1,26 +1,24 @@
 plugins {
-	id 'io.freefair.aspectj' version '8.4' apply false
+	id 'io.spring.nohttp' version '0.0.11'
+	id 'io.freefair.aspectj' version '6.5.0.3' apply false
 	// kotlinVersion is managed in gradle.properties
 	id 'org.jetbrains.kotlin.plugin.serialization' version "${kotlinVersion}" apply false
-	id 'org.jetbrains.dokka' version '1.8.20'
+	id 'org.jetbrains.dokka' version '1.7.20'
+	id 'org.asciidoctor.jvm.convert' version '3.3.2' apply false
+	id 'org.asciidoctor.jvm.pdf' version '3.3.2'  apply false
 	id 'org.unbroken-dome.xjc' version '2.0.0' apply false
-	id 'com.github.ben-manes.versions' version '0.51.0'
-	id 'com.github.johnrengelman.shadow' version '8.1.1' apply false
-	id 'de.undercouch.download' version '5.4.0'
-	id 'me.champeau.jmh' version '0.7.2' apply false
-	id 'me.champeau.mrjar' version '0.1.1'
+	id 'com.github.ben-manes.versions' version '0.42.0'
+	id 'com.github.johnrengelman.shadow' version '7.1.2' apply false
+	id 'de.undercouch.download' version '5.1.0'
+	id 'me.champeau.jmh' version '0.6.8' apply false
 }

 ext {
 	moduleProjects = subprojects.findAll { it.name.startsWith("spring-") }
-	javaProjects = subprojects.findAll { !it.name.startsWith("framework-") }
+	javaProjects = subprojects - project(":framework-bom") - project(":framework-platform")
 }

-description = "Spring Framework"
-
 configure(allprojects) { project ->
-	apply plugin: "org.springframework.build.localdev"
-	group = "org.springframework"
 	repositories {
 		mavenCentral()
 		maven {
@@ -30,6 +28,7 @@ configure(allprojects) { project ->
 				includeGroup 'io.projectreactor.netty'
 			}
 		}
+		maven { url "https://repo.spring.io/libs-spring-framework-build" }
 		if (version.contains('-')) {
 			maven { url "https://repo.spring.io/milestone" }
 		}
@@ -45,7 +44,16 @@ configure(allprojects) { project ->
 	}
 }

-configure(allprojects - project(":framework-platform")) {
+configure([rootProject] + javaProjects) { project ->
+	group = "org.springframework"
+
+	apply plugin: "java"
+	apply plugin: "java-test-fixtures"
+	apply plugin: "checkstyle"
+	apply plugin: 'org.springframework.build.conventions'
+	apply from: "${rootDir}/gradle/toolchains.gradle"
+	apply from: "${rootDir}/gradle/ide.gradle"
+
 	configurations {
 		dependencyManagement {
 			canBeConsumed = false
@@ -54,19 +62,36 @@ configure(allprojects - project(":framework-platform")) {
 		}
 		matching { it.name.endsWith("Classpath") }.all { it.extendsFrom(dependencyManagement) }
 	}
+
+	test {
+		useJUnitPlatform()
+		include(["**/*Tests.class", "**/*Test.class"])
+		systemProperty("java.awt.headless", "true")
+		systemProperty("testGroups", project.properties.get("testGroups"))
+		systemProperty("io.netty.leakDetection.level", "paranoid")
+		systemProperty("io.netty5.leakDetectionLevel", "paranoid")
+		systemProperty("io.netty5.leakDetection.targetRecords", "32")
+		systemProperty("io.netty5.buffer.lifecycleTracingEnabled", "true")
+		systemProperty("io.netty5.buffer.leakDetectionEnabled", "true")
+		jvmArgs(["--add-opens=java.base/java.lang=ALL-UNNAMED",
+				 "--add-opens=java.base/java.util=ALL-UNNAMED"])
+	}
+
+	checkstyle {
+		toolVersion = "10.9.1"
+		configDirectory.set(rootProject.file("src/checkstyle"))
+	}
+
+	tasks.named("checkstyleMain").configure {
+		maxHeapSize = "1g"
+	}
+
+	tasks.named("checkstyleTest").configure {
+		maxHeapSize = "1g"
+	}
+
 	dependencies {
 		dependencyManagement(enforcedPlatform(dependencies.project(path: ":framework-platform")))
-	}
-}
-
-configure([rootProject] + javaProjects) { project ->
-	apply plugin: "java"
-	apply plugin: "java-test-fixtures"
-	apply plugin: 'org.springframework.build.conventions'
-	apply from: "${rootDir}/gradle/toolchains.gradle"
-	apply from: "${rootDir}/gradle/ide.gradle"
-
-	dependencies {
 		testImplementation("org.junit.jupiter:junit-jupiter-api")
 		testImplementation("org.junit.jupiter:junit-jupiter-params")
 		testImplementation("org.junit.platform:junit-platform-suite-api")
@@ -80,41 +105,71 @@ configure([rootProject] + javaProjects) { project ->
 		testRuntimeOnly("org.junit.platform:junit-platform-suite-engine")
 		testRuntimeOnly("org.apache.logging.log4j:log4j-core")
 		testRuntimeOnly("org.apache.logging.log4j:log4j-jul")
-		testRuntimeOnly("org.apache.logging.log4j:log4j-slf4j2-impl")
+		testRuntimeOnly("org.apache.logging.log4j:log4j-slf4j-impl")
 		// JSR-305 only used for non-required meta-annotations
 		compileOnly("com.google.code.findbugs:jsr305")
 		testCompileOnly("com.google.code.findbugs:jsr305")
+		checkstyle("io.spring.javaformat:spring-javaformat-checkstyle:0.0.31")
 	}

 	ext.javadocLinks = [
 			"https://docs.oracle.com/en/java/javase/17/docs/api/",
 			"https://jakarta.ee/specifications/platform/9/apidocs/",
-			"https://docs.oracle.com/cd/E13222_01/wls/docs90/javadocs/",  // CommonJ and weblogic.* packages
-			"https://www.ibm.com/docs/api/v1/content/SSEQTP_8.5.5/com.ibm.websphere.javadoc.doc/web/apidocs/", // com.ibm.*
-			"https://docs.jboss.org/jbossas/javadoc/4.0.5/connector/", // org.jboss.resource.*
-			"https://docs.jboss.org/hibernate/orm/5.6/javadocs/",
-			"https://eclipse.dev/aspectj/doc/released/aspectj5rt-api",
+			"https://docs.oracle.com/cd/E13222_01/wls/docs90/javadocs/",  // CommonJ
+			"https://www.ibm.com/docs/api/v1/content/SSEQTP_8.5.5/com.ibm.websphere.javadoc.doc/web/apidocs/",
+			"https://docs.jboss.org/jbossas/javadoc/4.0.5/connector/",
+			"https://docs.jboss.org/jbossas/javadoc/7.1.2.Final/",
+			"https://www.eclipse.org/aspectj/doc/released/aspectj5rt-api/",
 			"https://www.quartz-scheduler.org/api/2.3.0/",
-			"https://fasterxml.github.io/jackson-core/javadoc/2.14/",
-			"https://fasterxml.github.io/jackson-databind/javadoc/2.14/",
-			"https://fasterxml.github.io/jackson-dataformat-xml/javadoc/2.14/",
+			"https://www.javadoc.io/doc/com.fasterxml.jackson.core/jackson-core/2.14.1/",
+			"https://www.javadoc.io/doc/com.fasterxml.jackson.core/jackson-databind/2.14.1/",
+			"https://www.javadoc.io/doc/com.fasterxml.jackson.dataformat/jackson-dataformat-xml/2.14.1/",
 			"https://hc.apache.org/httpcomponents-client-5.2.x/current/httpclient5/apidocs/",
 			"https://projectreactor.io/docs/test/release/api/",
 			"https://junit.org/junit4/javadoc/4.13.2/",
 			// TODO Uncomment link to JUnit 5 docs once we execute Gradle with Java 18+.
 			// See https://github.com/spring-projects/spring-framework/issues/27497
 			//
-			// "https://junit.org/junit5/docs/5.10.2/api/",
+			// "https://junit.org/junit5/docs/5.9.2/api/",
 			"https://www.reactive-streams.org/reactive-streams-1.0.3-javadoc/",
-			//"https://javadoc.io/static/io.rsocket/rsocket-core/1.1.1/",
+			"https://javadoc.io/static/io.rsocket/rsocket-core/1.1.1/",
 			"https://r2dbc.io/spec/1.0.0.RELEASE/api/",
-			// Previously there could be a split-package issue between JSR250 and JSR305 javax.annotation packages,
-			// but since 6.0 JSR 250 annotations such as @Resource and @PostConstruct have been replaced by their
-			// JakartaEE equivalents in the jakarta.annotation package.
-			//"https://www.javadoc.io/doc/com.google.code.findbugs/jsr305/3.0.2/"
+			// The external Javadoc link for JSR 305 must come last to ensure that types from
+			// JSR 250 (such as @PostConstruct) are still supported. This is due to the fact
+			// that JSR 250 and JSR 305 both define types in javax.annotation, which results
+			// in a split package, and the javadoc tool does not support split packages
+			// across multiple external Javadoc sites.
+			"https://www.javadoc.io/doc/com.google.code.findbugs/jsr305/3.0.2/"
 	] as String[]
 }

 configure(moduleProjects) { project ->
 	apply from: "${rootDir}/gradle/spring-module.gradle"
 }
+
+configure(rootProject) {
+	description = "Spring Framework"
+
+	apply plugin: "io.spring.nohttp"
+	apply plugin: 'org.springframework.build.api-diff'
+
+	nohttp {
+		source.exclude "**/test-output/**"
+		allowlistFile = project.file("src/nohttp/allowlist.lines")
+		def rootPath = file(rootDir).toPath()
+		def projectDirs = allprojects.collect { it.projectDir } + "${rootDir}/buildSrc"
+		projectDirs.forEach { dir ->
+			[ 'bin', 'build', 'out', '.settings' ]
+				.collect { rootPath.relativize(new File(dir, it).toPath()) }
+				.forEach { source.exclude "$it/**" }
+			[ '.classpath', '.project' ]
+				.collect { rootPath.relativize(new File(dir, it).toPath()) }
+				.forEach { source.exclude "$it" }
+		}
+	}
+
+	tasks.named("checkstyleNohttp").configure {
+		maxHeapSize = "1g"
+	}
+
+}
@@ -22,6 +22,21 @@ but doesn't affect the classpath of dependent projects.
 This plugin does not provide a `provided` configuration, as the native `compileOnly` and `testCompileOnly`
 configurations are preferred.

+### API Diff
+
+This plugin uses the [Gradle JApiCmp](https://github.com/melix/japicmp-gradle-plugin) plugin
+to generate API Diff reports for each Spring Framework module. This plugin is applied once on the root
+project and creates tasks in each framework module. Unlike previous versions of this part of the build,
+there is no need for checking out a specific tag. The plugin will fetch the JARs we want to compare the
+current working version with. You can generate the reports for all modules or a single module:
+
+```
+./gradlew apiDiff -PbaselineVersion=5.1.0.RELEASE
+./gradlew :spring-core:apiDiff -PbaselineVersion=5.1.0.RELEASE
+```      
+
+The reports are located under `build/reports/api-diff/$OLDVERSION_to_$NEWVERSION/`.
+                                                                                       

 ### RuntimeHints Java Agent

@@ -1,6 +1,5 @@
 plugins {
 	id 'java-gradle-plugin'
-	id 'checkstyle'
 }

 repositories {
@@ -18,24 +17,22 @@ ext {
 }

 dependencies {
-	checkstyle "io.spring.javaformat:spring-javaformat-checkstyle:${javaFormatVersion}"
-	implementation "org.jetbrains.kotlin:kotlin-gradle-plugin:${kotlinVersion}"
-	implementation "org.jetbrains.kotlin:kotlin-compiler-embeddable:${kotlinVersion}"
-	implementation "org.gradle:test-retry-gradle-plugin:1.5.6"
-	implementation "io.spring.javaformat:spring-javaformat-gradle-plugin:${javaFormatVersion}"
-	implementation "io.spring.nohttp:nohttp-gradle:0.0.11"
+	implementation("org.jetbrains.kotlin:kotlin-gradle-plugin:${kotlinVersion}")
+	implementation("org.jetbrains.kotlin:kotlin-compiler-embeddable:${kotlinVersion}")
+	implementation "me.champeau.gradle:japicmp-gradle-plugin:0.3.0"
+	implementation "org.gradle:test-retry-gradle-plugin:1.4.1"
 }

 gradlePlugin {
 	plugins {
+		apiDiffPlugin {
+			id = "org.springframework.build.api-diff"
+			implementationClass = "org.springframework.build.api.ApiDiffPlugin"
+		}
 		conventionsPlugin {
 			id = "org.springframework.build.conventions"
 			implementationClass = "org.springframework.build.ConventionsPlugin"
 		}
-		localDevPlugin {
-			id = "org.springframework.build.localdev"
-			implementationClass = "org.springframework.build.dev.LocalDevelopmentPlugin"
-		}
 		optionalDependenciesPlugin {
 			id = "org.springframework.build.optional-dependencies"
 			implementationClass = "org.springframework.build.optional.OptionalDependenciesPlugin"
@@ -1,27 +0,0 @@
-<?xml version="1.0"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="com.puppycrawl.tools.checkstyle.Checker">
-
-	<!-- Root Checks -->
-	<module name="io.spring.javaformat.checkstyle.check.SpringHeaderCheck">
-		<property name="fileExtensions" value="java"/>
-		<property name="headerType" value="apache2"/>
-		<property name="headerCopyrightPattern" value="20\d\d-20\d\d"/>
-		<property name="packageInfoHeaderType" value="none"/>
-	</module>
-	<module name="com.puppycrawl.tools.checkstyle.checks.NewlineAtEndOfFileCheck"/>
-
-	<!-- TreeWalker Checks -->
-	<module name="com.puppycrawl.tools.checkstyle.TreeWalker">
-
-		<!-- Imports -->
-		<module name="com.puppycrawl.tools.checkstyle.checks.imports.UnusedImportsCheck">
-			<property name="processJavadoc" value="true"/>
-		</module>
-
-		<!-- Modifiers -->
-		<module name="com.puppycrawl.tools.checkstyle.checks.modifier.ModifierOrderCheck"/>
-
-	</module>
-
-</module>
@@ -1,2 +1 @@
 org.gradle.caching=true
-javaFormatVersion=0.0.41
@@ -1,79 +0,0 @@
-/*
- * Copyright 2002-2024 the original author or authors.
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- *      https://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-
-package org.springframework.build;
-
-import java.io.File;
-import java.nio.file.Path;
-import java.util.List;
-
-import io.spring.javaformat.gradle.SpringJavaFormatPlugin;
-import io.spring.nohttp.gradle.NoHttpExtension;
-import io.spring.nohttp.gradle.NoHttpPlugin;
-import org.gradle.api.Plugin;
-import org.gradle.api.Project;
-import org.gradle.api.artifacts.DependencySet;
-import org.gradle.api.plugins.JavaBasePlugin;
-import org.gradle.api.plugins.quality.Checkstyle;
-import org.gradle.api.plugins.quality.CheckstyleExtension;
-import org.gradle.api.plugins.quality.CheckstylePlugin;
-
-/**
- * {@link Plugin} that applies conventions for checkstyle.
- *
- * @author Brian Clozel
- */
-public class CheckstyleConventions {
-
-	/**
-	 * Applies the Spring Java Format and Checkstyle plugins with the project conventions.
-	 * @param project the current project
-	 */
-	public void apply(Project project) {
-		project.getPlugins().withType(JavaBasePlugin.class, (java) -> {
-			if (project.getRootProject() == project) {
-				configureNoHttpPlugin(project);
-			}
-			project.getPlugins().apply(CheckstylePlugin.class);
-			project.getTasks().withType(Checkstyle.class).forEach(checkstyle -> checkstyle.getMaxHeapSize().set("1g"));
-			CheckstyleExtension checkstyle = project.getExtensions().getByType(CheckstyleExtension.class);
-			checkstyle.setToolVersion("10.14.1");
-			checkstyle.getConfigDirectory().set(project.getRootProject().file("src/checkstyle"));
-			String version = SpringJavaFormatPlugin.class.getPackage().getImplementationVersion();
-			DependencySet checkstyleDependencies = project.getConfigurations().getByName("checkstyle").getDependencies();
-			checkstyleDependencies.add(
-					project.getDependencies().create("io.spring.javaformat:spring-javaformat-checkstyle:" + version));
-		});
-	}
-
-	private static void configureNoHttpPlugin(Project project) {
-		project.getPlugins().apply(NoHttpPlugin.class);
-		NoHttpExtension noHttp = project.getExtensions().getByType(NoHttpExtension.class);
-		noHttp.setAllowlistFile(project.file("src/nohttp/allowlist.lines"));
-		noHttp.getSource().exclude("**/test-output/**", "**/.settings/**",
-				"**/.classpath", "**/.project", "**/.gradle/**");
-		List<String> buildFolders = List.of("bin", "build", "out");
-		project.allprojects(subproject -> {
-			Path rootPath = project.getRootDir().toPath();
-			Path projectPath = rootPath.relativize(subproject.getProjectDir().toPath());
-			for (String buildFolder : buildFolders) {
-				Path innerBuildDir = projectPath.resolve(buildFolder);
-				noHttp.getSource().exclude(innerBuildDir + File.separator + "**");
-			}
-		});
-	}
-
-}
@@ -1,5 +1,5 @@
 /*
- * Copyright 2002-2023 the original author or authors.
+ * Copyright 2002-2022 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
@@ -25,8 +25,10 @@ import org.jetbrains.kotlin.gradle.plugin.KotlinBasePlugin;
 * Plugin to apply conventions to projects that are part of Spring Framework's build.
 * Conventions are applied in response to various plugins being applied.
 *
- * <p>When the {@link JavaBasePlugin} is applied, the conventions in {@link CheckstyleConventions},
- * {@link TestConventions} and {@link JavaConventions} are applied.
+ * When the {@link JavaBasePlugin} is applied, the conventions in {@link TestConventions}
+ * are applied.
+ * When the {@link JavaBasePlugin} is applied, the conventions in {@link JavaConventions}
+ * are applied.
 * When the {@link KotlinBasePlugin} is applied, the conventions in {@link KotlinConventions}
 * are applied.
 *
@@ -36,10 +38,8 @@ public class ConventionsPlugin implements Plugin<Project> {

 	@Override
 	public void apply(Project project) {
-		new CheckstyleConventions().apply(project);
 		new JavaConventions().apply(project);
 		new KotlinConventions().apply(project);
 		new TestConventions().apply(project);
 	}
-
 }
@@ -1,5 +1,5 @@
 /*
- * Copyright 2002-2023 the original author or authors.
+ * Copyright 2002-2022 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
@@ -24,10 +24,7 @@ import org.gradle.api.Plugin;
 import org.gradle.api.Project;
 import org.gradle.api.plugins.JavaBasePlugin;
 import org.gradle.api.plugins.JavaPlugin;
-import org.gradle.api.plugins.JavaPluginExtension;
 import org.gradle.api.tasks.compile.JavaCompile;
-import org.gradle.jvm.toolchain.JavaLanguageVersion;
-import org.gradle.jvm.toolchain.JvmVendorSpec;

 /**
 * {@link Plugin} that applies conventions for compiling Java sources in Spring Framework.
@@ -71,10 +68,6 @@ public class JavaConventions {
 	 * @param project the current project
 	 */
 	private void applyJavaCompileConventions(Project project) {
-		project.getExtensions().getByType(JavaPluginExtension.class).toolchain(toolchain -> {
-			toolchain.getVendor().set(JvmVendorSpec.BELLSOFT);
-			toolchain.getLanguageVersion().set(JavaLanguageVersion.of(17));
-		});
 		project.getTasks().withType(JavaCompile.class)
 				.matching(compileTask -> compileTask.getName().equals(JavaPlugin.COMPILE_JAVA_TASK_NAME))
 				.forEach(compileTask -> {
@@ -16,8 +16,6 @@

 package org.springframework.build;

-import java.util.Map;
-
 import org.gradle.api.Project;
 import org.gradle.api.plugins.JavaBasePlugin;
 import org.gradle.api.tasks.testing.Test;
@@ -28,8 +26,8 @@ import org.gradle.testretry.TestRetryTaskExtension;
 * Conventions that are applied in the presence of the {@link JavaBasePlugin}. When the
 * plugin is applied:
 * <ul>
- * <li>The {@link TestRetryPlugin Test Retry} plugin is applied so that flaky tests
- * are retried 3 times when running on the CI server.
+ * <li>The {@link TestRetryPlugin Test Retry} plugins is applied so that flaky tests
+ * are retried 3 times when running on the CI.
 * </ul>
 *
 * @author Brian Clozel
@@ -43,36 +41,11 @@ class TestConventions {

 	private void configureTestConventions(Project project) {
 		project.getTasks().withType(Test.class,
-				test -> {
-					configureTests(project, test);
-					configureTestRetryPlugin(project, test);
-				});
-	}
-
-	private void configureTests(Project project, Test test) {
-		test.useJUnitPlatform();
-		test.include("**/*Tests.class", "**/*Test.class");
-		test.setSystemProperties(Map.of(
-				"java.awt.headless", "true",
-				"io.netty.leakDetection.level", "paranoid",
-				"io.netty5.leakDetectionLevel", "paranoid",
-				"io.netty5.leakDetection.targetRecords", "32",
-				"io.netty5.buffer.lifecycleTracingEnabled", "true"
-		));
-		if (project.hasProperty("testGroups")) {
-			test.systemProperty("testGroups", project.getProperties().get("testGroups"));
-		}
-		test.jvmArgs("--add-opens=java.base/java.lang=ALL-UNNAMED",
-				"--add-opens=java.base/java.util=ALL-UNNAMED",
-				"-Djava.locale.providers=COMPAT");
-	}
-
-	private void configureTestRetryPlugin(Project project, Test test) {
-		project.getPlugins().withType(TestRetryPlugin.class, testRetryPlugin -> {
-			TestRetryTaskExtension testRetry = test.getExtensions().getByType(TestRetryTaskExtension.class);
-			testRetry.getFailOnPassedAfterRetry().set(true);
-			testRetry.getMaxRetries().set(isCi() ? 3 : 0);
-		});
+				(test) -> project.getPlugins().withType(TestRetryPlugin.class, (testRetryPlugin) -> {
+					TestRetryTaskExtension testRetry = test.getExtensions().getByType(TestRetryTaskExtension.class);
+					testRetry.getFailOnPassedAfterRetry().set(true);
+					testRetry.getMaxRetries().set(isCi() ? 3 : 0);
+				}));
 	}

 	private boolean isCi() {
@@ -0,0 +1,140 @@
+/*
+ * Copyright 2002-2019 the original author or authors.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *      https://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.springframework.build.api;
+
+import java.io.File;
+import java.net.URI;
+import java.nio.file.Path;
+import java.nio.file.Paths;
+import java.util.Collections;
+import java.util.List;
+
+import me.champeau.gradle.japicmp.JapicmpPlugin;
+import me.champeau.gradle.japicmp.JapicmpTask;
+import org.gradle.api.GradleException;
+import org.gradle.api.Plugin;
+import org.gradle.api.Project;
+import org.gradle.api.artifacts.Configuration;
+import org.gradle.api.artifacts.Dependency;
+import org.gradle.api.plugins.JavaBasePlugin;
+import org.gradle.api.plugins.JavaPlugin;
+import org.gradle.api.publish.maven.plugins.MavenPublishPlugin;
+import org.gradle.api.tasks.TaskProvider;
+import org.gradle.jvm.tasks.Jar;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+/**
+ * {@link Plugin} that applies the {@code "japicmp-gradle-plugin"}
+ * and create tasks for all subprojects named {@code "spring-*"}, diffing the public API one by one
+ * and creating the reports in {@code "build/reports/api-diff/$OLDVERSION_to_$NEWVERSION/"}.
+ * <p>{@code "./gradlew apiDiff -PbaselineVersion=5.1.0.RELEASE"} will output the
+ * reports for the API diff between the baseline version and the current one for all modules.
+ * You can limit the report to a single module with
+ * {@code "./gradlew :spring-core:apiDiff -PbaselineVersion=5.1.0.RELEASE"}.
+ *
+ * @author Brian Clozel
+ */
+public class ApiDiffPlugin implements Plugin<Project> {
+
+	private static final Logger logger = LoggerFactory.getLogger(ApiDiffPlugin.class);
+
+	public static final String TASK_NAME = "apiDiff";
+
+	private static final String BASELINE_VERSION_PROPERTY = "baselineVersion";
+
+	private static final List<String> PACKAGE_INCLUDES = Collections.singletonList("org.springframework.*");
+
+	private static final URI SPRING_MILESTONE_REPOSITORY = URI.create("https://repo.spring.io/milestone");
+
+	@Override
+	public void apply(Project project) {
+		if (project.hasProperty(BASELINE_VERSION_PROPERTY) && project.equals(project.getRootProject())) {
+			project.getPluginManager().apply(JapicmpPlugin.class);
+			project.getPlugins().withType(JapicmpPlugin.class,
+					plugin -> applyApiDiffConventions(project));
+		}
+	}
+
+	private void applyApiDiffConventions(Project project) {
+		String baselineVersion = project.property(BASELINE_VERSION_PROPERTY).toString();
+		project.subprojects(subProject -> {
+			if (subProject.getName().startsWith("spring-")) {
+				createApiDiffTask(baselineVersion, subProject);
+			}
+		});
+	}
+
+	private void createApiDiffTask(String baselineVersion, Project project) {
+		if (isProjectEligible(project)) {
+			// Add Spring Milestone repository for generating diffs against previous milestones
+			project.getRootProject()
+					.getRepositories()
+					.maven(mavenArtifactRepository -> mavenArtifactRepository.setUrl(SPRING_MILESTONE_REPOSITORY));
+			JapicmpTask apiDiff = project.getTasks().create(TASK_NAME, JapicmpTask.class);
+			apiDiff.setDescription("Generates an API diff report with japicmp");
+			apiDiff.setGroup(JavaBasePlugin.DOCUMENTATION_GROUP);
+
+			apiDiff.setOldClasspath(createBaselineConfiguration(baselineVersion, project));
+			TaskProvider<Jar> jar = project.getTasks().withType(Jar.class).named("jar");
+			apiDiff.setNewArchives(project.getLayout().files(jar.get().getArchiveFile().get().getAsFile()));
+			apiDiff.setNewClasspath(getRuntimeClassPath(project));
+			apiDiff.setPackageIncludes(PACKAGE_INCLUDES);
+			apiDiff.setOnlyModified(true);
+			apiDiff.setIgnoreMissingClasses(true);
+			// Ignore Kotlin metadata annotations since they contain
+			// illegal HTML characters and fail the report generation
+			apiDiff.setAnnotationExcludes(Collections.singletonList("@kotlin.Metadata"));
+
+			apiDiff.setHtmlOutputFile(getOutputFile(baselineVersion, project));
+
+			apiDiff.dependsOn(project.getTasks().getByName("jar"));
+		}
+	}
+
+	private boolean isProjectEligible(Project project) {
+		return project.getPlugins().hasPlugin(JavaPlugin.class)
+				&& project.getPlugins().hasPlugin(MavenPublishPlugin.class);
+	}
+
+	private Configuration createBaselineConfiguration(String baselineVersion, Project project) {
+		String baseline = String.join(":",
+				project.getGroup().toString(), project.getName(), baselineVersion);
+		Dependency baselineDependency = project.getDependencies().create(baseline + "@jar");
+		Configuration baselineConfiguration = project.getRootProject().getConfigurations().detachedConfiguration(baselineDependency);
+		try {
+			// eagerly resolve the baseline configuration to check whether this is a new Spring module
+			baselineConfiguration.resolve();
+			return baselineConfiguration;
+		}
+		catch (GradleException exception) {
+			logger.warn("Could not resolve {} - assuming this is a new Spring module.", baseline);
+		}
+		return project.getRootProject().getConfigurations().detachedConfiguration();
+	}
+
+	private Configuration getRuntimeClassPath(Project project) {
+		return project.getConfigurations().getByName(JavaPlugin.RUNTIME_CLASSPATH_CONFIGURATION_NAME);
+	}
+
+	private File getOutputFile(String baseLineVersion, Project project) {
+		Path outDir = Paths.get(project.getRootProject().getBuildDir().getAbsolutePath(),
+				"reports", "api-diff",
+				baseLineVersion + "_to_" + project.getRootProject().getVersion());
+		return project.file(outDir.resolve(project.getName() + ".html").toString());
+	}
+
+}
@@ -1,49 +0,0 @@
-/*
- * Copyright 2002-2023 the original author or authors.
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- *      https://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-
-package org.springframework.build.dev;
-
-import org.gradle.api.Plugin;
-import org.gradle.api.Project;
-import org.gradle.api.plugins.JavaBasePlugin;
-
-/**
- * {@link Plugin} that skips documentation tasks when the {@code "-PskipDocs"} property is defined.
- *
- * @author Brian Clozel
- */
-public class LocalDevelopmentPlugin implements Plugin<Project> {
-
-	private static final String SKIP_DOCS_PROPERTY = "skipDocs";
-
-	@Override
-	public void apply(Project target) {
-		if (target.hasProperty(SKIP_DOCS_PROPERTY)) {
-			skipDocumentationTasks(target);
-			target.subprojects(this::skipDocumentationTasks);
-		}
-	}
-
-	private void skipDocumentationTasks(Project project) {
-		project.afterEvaluate(p -> {
-			p.getTasks().matching(task -> {
-						return JavaBasePlugin.DOCUMENTATION_GROUP.equals(task.getGroup())
-								|| "distribution".equals(task.getGroup());
-					})
-					.forEach(task -> task.setEnabled(false));
-		});
-	}
-}
@@ -1,48 +0,0 @@
-/*
- * Copyright 2002-2023 the original author or authors.
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- *      https://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-
-package org.springframework.build.hint;
-
-import java.util.Collections;
-
-import org.gradle.api.file.ConfigurableFileCollection;
-import org.gradle.api.provider.SetProperty;
-import org.gradle.api.tasks.Classpath;
-import org.gradle.api.tasks.Input;
-import org.gradle.process.CommandLineArgumentProvider;
-
-/**
- * Argument provider for registering the runtime hints agent with a Java process.
- */
-public interface RuntimeHintsAgentArgumentProvider extends CommandLineArgumentProvider {
-
-	@Classpath
-	ConfigurableFileCollection getAgentJar();
-
-    @Input
-    SetProperty<String> getIncludedPackages();
-
-    @Input
-    SetProperty<String> getExcludedPackages();
-
-    @Override
-    default Iterable<String> asArguments() {
-        StringBuilder packages = new StringBuilder();
-        getIncludedPackages().get().forEach(packageName -> packages.append('+').append(packageName).append(','));
-        getExcludedPackages().get().forEach(packageName -> packages.append('-').append(packageName).append(','));
-        return Collections.singleton("-javaagent:" + getAgentJar().getSingleFile() + "=" + packages);
-    }
-}
@@ -1,5 +1,5 @@
 /*
- * Copyright 2002-2023 the original author or authors.
+ * Copyright 2002-2022 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
@@ -16,15 +16,38 @@

 package org.springframework.build.hint;

+import java.util.Collections;
+
+import org.gradle.api.model.ObjectFactory;
 import org.gradle.api.provider.SetProperty;

 /**
 * Entry point to the DSL extension for the {@link RuntimeHintsAgentPlugin} Gradle plugin.
 * @author Brian Clozel
 */
-public interface RuntimeHintsAgentExtension {
+public class RuntimeHintsAgentExtension {

-	SetProperty<String> getIncludedPackages();
+	private final SetProperty<String> includedPackages;

-	SetProperty<String> getExcludedPackages();
+	private final SetProperty<String> excludedPackages;
+
+	public RuntimeHintsAgentExtension(ObjectFactory objectFactory) {
+		this.includedPackages = objectFactory.setProperty(String.class).convention(Collections.singleton("org.springframework"));
+		this.excludedPackages = objectFactory.setProperty(String.class).convention(Collections.emptySet());
+	}
+
+	public SetProperty<String> getIncludedPackages() {
+		return this.includedPackages;
+	}
+
+	public SetProperty<String> getExcludedPackages() {
+		return this.excludedPackages;
+	}
+
+	String asJavaAgentArgument() {
+		StringBuilder builder = new StringBuilder();
+		this.includedPackages.get().forEach(packageName -> builder.append('+').append(packageName).append(','));
+		this.excludedPackages.get().forEach(packageName -> builder.append('-').append(packageName).append(','));
+		return builder.toString();
+	}
 }
@@ -1,5 +1,5 @@
 /*
- * Copyright 2002-2023 the original author or authors.
+ * Copyright 2002-2022 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
@@ -16,79 +16,41 @@

 package org.springframework.build.hint;

-import org.gradle.api.JavaVersion;
 import org.gradle.api.Plugin;
 import org.gradle.api.Project;
-import org.gradle.api.artifacts.Configuration;
-import org.gradle.api.attributes.Bundling;
-import org.gradle.api.attributes.Category;
-import org.gradle.api.attributes.LibraryElements;
-import org.gradle.api.attributes.Usage;
-import org.gradle.api.attributes.java.TargetJvmVersion;
 import org.gradle.api.plugins.JavaPlugin;
+import org.gradle.api.tasks.bundling.Jar;
 import org.gradle.api.tasks.testing.Test;

-import java.util.Collections;
-
 /**
 * {@link Plugin} that configures the {@code RuntimeHints} Java agent to test tasks.
 *
 * @author Brian Clozel
- * @author Sebastien Deleuze
 */
 public class RuntimeHintsAgentPlugin implements Plugin<Project> {

 	public static final String RUNTIMEHINTS_TEST_TASK = "runtimeHintsTest";
 	private static final String EXTENSION_NAME = "runtimeHintsAgent";
-	private static final String CONFIGURATION_NAME = "testRuntimeHintsAgentJar";


 	@Override
 	public void apply(Project project) {

 		project.getPlugins().withType(JavaPlugin.class, javaPlugin -> {
-			RuntimeHintsAgentExtension agentExtension = createRuntimeHintsAgentExtension(project);
+			RuntimeHintsAgentExtension agentExtension = project.getExtensions().create(EXTENSION_NAME,
+					RuntimeHintsAgentExtension.class, project.getObjects());
 			Test agentTest = project.getTasks().create(RUNTIMEHINTS_TEST_TASK, Test.class, test -> {
 				test.useJUnitPlatform(options -> {
 					options.includeTags("RuntimeHintsTests");
 				});
 				test.include("**/*Tests.class", "**/*Test.class");
 				test.systemProperty("java.awt.headless", "true");
-				test.systemProperty("org.graalvm.nativeimage.imagecode", "runtime");
-				test.getJvmArgumentProviders().add(createRuntimeHintsAgentArgumentProvider(project, agentExtension));
+			});
+			project.afterEvaluate(p -> {
+				Jar jar = project.getRootProject().project("spring-core-test").getTasks().withType(Jar.class).named("jar").get();
+				agentTest.jvmArgs("-javaagent:" + jar.getArchiveFile().get().getAsFile() + "=" + agentExtension.asJavaAgentArgument());
 			});
 			project.getTasks().getByName("check", task -> task.dependsOn(agentTest));
-			project.getDependencies().add(CONFIGURATION_NAME, project.project(":spring-core-test"));
-		});
-	}
-
-	private static RuntimeHintsAgentExtension createRuntimeHintsAgentExtension(Project project) {
-		RuntimeHintsAgentExtension agentExtension = project.getExtensions().create(EXTENSION_NAME, RuntimeHintsAgentExtension.class);
-		agentExtension.getIncludedPackages().convention(Collections.singleton("org.springframework"));
-		agentExtension.getExcludedPackages().convention(Collections.emptySet());
-		return agentExtension;
-	}
-
-	private static RuntimeHintsAgentArgumentProvider createRuntimeHintsAgentArgumentProvider(
-			Project project, RuntimeHintsAgentExtension agentExtension) {
-		RuntimeHintsAgentArgumentProvider agentArgumentProvider = project.getObjects().newInstance(RuntimeHintsAgentArgumentProvider.class);
-		agentArgumentProvider.getAgentJar().from(createRuntimeHintsAgentConfiguration(project));
-		agentArgumentProvider.getIncludedPackages().set(agentExtension.getIncludedPackages());
-		agentArgumentProvider.getExcludedPackages().set(agentExtension.getExcludedPackages());
-		return agentArgumentProvider;
-	}
-
-	private static Configuration createRuntimeHintsAgentConfiguration(Project project) {
-		return project.getConfigurations().create(CONFIGURATION_NAME, configuration -> {
-			configuration.setCanBeConsumed(false);
-			configuration.setTransitive(false); // Only the built artifact is required
-			configuration.attributes(attributes -> {
-				attributes.attribute(Bundling.BUNDLING_ATTRIBUTE, project.getObjects().named(Bundling.class, Bundling.EXTERNAL));
-				attributes.attribute(Category.CATEGORY_ATTRIBUTE, project.getObjects().named(Category.class, Category.LIBRARY));
-				attributes.attribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE, project.getObjects().named(LibraryElements.class, LibraryElements.JAR));
-				attributes.attribute(TargetJvmVersion.TARGET_JVM_VERSION_ATTRIBUTE, Integer.valueOf(JavaVersion.current().getMajorVersion()));
-				attributes.attribute(Usage.USAGE_ATTRIBUTE, project.getObjects().named(Usage.class, Usage.JAVA_RUNTIME));
-			});
 		});
 	}
 }
@@ -1,5 +1,5 @@
 /*
- * Copyright 2002-2023 the original author or authors.
+ * Copyright 2002-2021 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
@@ -19,7 +19,7 @@ package org.springframework.build.optional;
 import org.gradle.api.Plugin;
 import org.gradle.api.Project;
 import org.gradle.api.artifacts.Configuration;
-import org.gradle.api.plugins.JavaBasePlugin;
+import org.gradle.api.plugins.JavaPlugin;
 import org.gradle.api.plugins.JavaPluginExtension;
 import org.gradle.api.tasks.SourceSetContainer;

@@ -40,10 +40,10 @@ public class OptionalDependenciesPlugin implements Plugin<Project> {

 	@Override
 	public void apply(Project project) {
-		Configuration optional = project.getConfigurations().create(OPTIONAL_CONFIGURATION_NAME);
+		Configuration optional = project.getConfigurations().create("optional");
 		optional.setCanBeConsumed(false);
 		optional.setCanBeResolved(false);
-		project.getPlugins().withType(JavaBasePlugin.class, (javaBasePlugin) -> {
+		project.getPlugins().withType(JavaPlugin.class, (javaPlugin) -> {
 			SourceSetContainer sourceSets = project.getExtensions().getByType(JavaPluginExtension.class)
 					.getSourceSets();
 			sourceSets.all((sourceSet) -> {
@@ -53,4 +53,4 @@ public class OptionalDependenciesPlugin implements Plugin<Project> {
 		});
 	}

-}
+}
@@ -1,19 +1,3 @@
-/*
- * Copyright 2002-2023 the original author or authors.
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- *      https://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-
 package org.springframework.build.shadow;

 import java.io.File;
@@ -2,7 +2,7 @@

 The Spring Framework uses https://concourse-ci.org/[Concourse] for its CI build and other automated tasks.
 The Spring team has a dedicated Concourse instance available at https://ci.spring.io with a build pipeline
-for https://ci.spring.io/teams/spring-framework/pipelines/spring-framework-6.1.x[Spring Framework 6.1.x].
+for https://ci.spring.io/teams/spring-framework/pipelines/spring-framework-6.0.x[Spring Framework 6.0.x].

 === Setting up your development environment

@@ -51,7 +51,7 @@ The pipeline can be deployed using the following command:

 [source]
 ----
-$ fly -t spring set-pipeline -p spring-framework-6.1.x -c ci/pipeline.yml -l ci/parameters.yml
+$ fly -t spring set-pipeline -p spring-framework-6.0.x -c ci/pipeline.yml -l ci/parameters.yml
 ----

 NOTE: This assumes that you have credhub integration configured with the appropriate secrets.
@@ -1,4 +1,4 @@
-FROM ubuntu:jammy-20240125
+FROM ubuntu:focal-20220922

 ADD setup.sh /setup.sh
 ADD get-jdk-url.sh /get-jdk-url.sh
@@ -6,7 +6,6 @@ RUN ./setup.sh

 ENV JAVA_HOME /opt/openjdk/java17
 ENV JDK17 /opt/openjdk/java17
-ENV JDK21 /opt/openjdk/java21
-ENV JDK23 /opt/openjdk/java23
+ENV JDK19 /opt/openjdk/java19

 ENV PATH $JAVA_HOME/bin:$PATH
@@ -3,13 +3,10 @@ set -e

 case "$1" in
 	java17)
-		echo "https://github.com/bell-sw/Liberica/releases/download/17.0.10%2B13/bellsoft-jdk17.0.10+13-linux-amd64.tar.gz"
+		echo "https://github.com/bell-sw/Liberica/releases/download/17.0.6+10/bellsoft-jdk17.0.6+10-linux-amd64.tar.gz"
 	;;
-	java21)
-		echo "https://github.com/bell-sw/Liberica/releases/download/21.0.2%2B14/bellsoft-jdk21.0.2+14-linux-amd64.tar.gz"
-	;;
-	java23)
-		echo "https://download.java.net/java/early_access/jdk23/10/GPL/openjdk-23-ea+10_linux-x64_bin.tar.gz"
+	java19)
+		echo "https://github.com/bell-sw/Liberica/releases/download/19.0.2+9/bellsoft-jdk19.0.2+9-linux-amd64.tar.gz"
 	;;
 	*)
 		echo $"Unknown java version"
@@ -20,7 +20,7 @@ curl https://raw.githubusercontent.com/spring-io/concourse-java-scripts/v0.0.4/c

 mkdir -p /opt/openjdk
 pushd /opt/openjdk > /dev/null
-for jdk in java17 java21 java22
+for jdk in java17 java19
 do
  JDK_URL=$( /get-jdk-url.sh $jdk )
  mkdir $jdk
@@ -3,8 +3,8 @@ github-repo-name: "spring-projects/spring-framework"
 sonatype-staging-profile: "org.springframework"
 docker-hub-organization: "springci"
 artifactory-server: "https://repo.spring.io"
-branch: "6.1.x"
-milestone: "6.1.x"
+branch: "main"
+milestone: "6.0.x"
 build-name: "spring-framework"
 pipeline-name: "spring-framework"
 concourse-url: "https://ci.spring.io"
@@ -45,7 +45,7 @@ resource_types:
  source:
    <<: *docker-resource-source
    repository: concourse/registry-image-resource
-    tag: 1.8.0
+    tag: 1.5.0
 - name: artifactory-resource
  type: registry-image
  source:
@@ -57,13 +57,19 @@ resource_types:
  source:
    <<: *docker-resource-source
    repository: concourse/github-release-resource
-    tag: 1.8.0
+    tag: 1.5.5
 - name: github-status-resource
  type: registry-image
  source:
    <<: *docker-resource-source
    repository: dpb587/github-status-resource
    tag: master
+- name: pull-request
+  type: registry-image
+  source:
+    <<: *docker-resource-source
+    repository: teliaoss/github-pr-resource
+    tag: v0.23.0
 - name: slack-notification
  type: registry-image
  source:
@@ -105,6 +111,14 @@ resources:
    username: ((artifactory-username))
    password: ((artifactory-password))
    build_name: ((build-name))
+- name: git-pull-request
+  type: pull-request
+  icon: source-pull
+  source:
+    access_token: ((github-ci-pull-request-token))
+    repository: ((github-repo-name))
+    base_branch: ((branch))
+    ignore_paths: ["ci/*"]
 - name: repo-status-build
  type: github-status-resource
  icon: eye-check-outline
@@ -113,22 +127,14 @@ resources:
    access_token: ((github-ci-status-token))
    branch: ((branch))
    context: build
- name: repo-status-jdk21-build
+- name: repo-status-jdk19-build
  type: github-status-resource
  icon: eye-check-outline
  source:
    repository: ((github-repo-name))
    access_token: ((github-ci-status-token))
    branch: ((branch))
-    context: jdk21-build
- name: repo-status-jdk23-build
-  type: github-status-resource
-  icon: eye-check-outline
-  source:
-    repository: ((github-repo-name))
-    access_token: ((github-ci-status-token))
-    branch: ((branch))
-    context: jdk23-build
+    context: jdk19-build
 - name: slack-alert
  type: slack-notification
  icon: slack
@@ -206,22 +212,26 @@ jobs:
      threads: 8
      artifact_set:
      - include:
-        - "/**/framework-api-*.zip"
+        - "/**/framework-docs-*.zip"
        properties:
          "zip.name": "spring-framework"
          "zip.displayname": "Spring Framework"
          "zip.deployed": "false"
      - include:
-        - "/**/framework-api-*-docs.zip"
+        - "/**/framework-docs-*-docs.zip"
        properties:
          "zip.type": "docs"
      - include:
-        - "/**/framework-api-*-schema.zip"
+        - "/**/framework-docs-*-dist.zip"
+        properties:
+          "zip.type": "dist"
+      - include:
+        - "/**/framework-docs-*-schema.zip"
        properties:
          "zip.type": "schema"
    get_params:
      threads: 8
- name: jdk21-build
+- name: jdk19-build
  serial: true
  public: true
  plan:
@@ -229,7 +239,7 @@ jobs:
    - get: git-repo
    - get: every-morning
      trigger: true
-    - put: repo-status-jdk21-build
+    - put: repo-status-jdk19-build
      params: { state: "pending", commit: "git-repo" }
    - do:
        - task: check-project
@@ -238,45 +248,48 @@ jobs:
          privileged: true
          timeout: ((task-timeout))
          params:
-            TEST_TOOLCHAIN: 21
+            TEST_TOOLCHAIN: 19
            <<: *build-project-task-params
      on_failure:
        do:
-          - put: repo-status-jdk21-build
+          - put: repo-status-jdk19-build
            params: { state: "failure", commit: "git-repo" }
          - put: slack-alert
            params:
              <<: *slack-fail-params
-    - put: repo-status-jdk21-build
+    - put: repo-status-jdk19-build
      params: { state: "success", commit: "git-repo" }
- name: jdk23-build
+- name: build-pull-requests
  serial: true
  public: true
  plan:
    - get: ci-image
    - get: git-repo
-    - get: every-morning
-      trigger: false
-    - put: repo-status-jdk23-build
-      params: { state: "pending", commit: "git-repo" }
+      resource: git-pull-request
+      trigger: true
+      version: every
    - do:
-        - task: check-project
-          image: ci-image
-          file: git-repo/ci/tasks/check-project.yml
-          privileged: true
-          timeout: ((task-timeout))
-          params:
-            TEST_TOOLCHAIN: 23
-            <<: *build-project-task-params
+      - put: git-pull-request
+        params:
+          path: git-repo
+          status: pending
+      - task: build-pr
+        image: ci-image
+        file: git-repo/ci/tasks/build-pr.yml
+        privileged: true
+        timeout: ((task-timeout))
+        params:
+          BRANCH: ((branch))
+      on_success:
+        put: git-pull-request
+        params:
+          path: git-repo
+          status: success
      on_failure:
-        do:
-          - put: repo-status-jdk23-build
-            params: { state: "failure", commit: "git-repo" }
-          - put: slack-alert
-            params:
-              <<: *slack-fail-params
-    - put: repo-status-jdk23-build
-      params: { state: "success", commit: "git-repo" }
+        put: git-pull-request
+        params:
+          path: git-repo
+          status: failure
 - name: stage-milestone
  serial: true
  plan:
@@ -428,8 +441,10 @@ jobs:

 groups:
 - name: "builds"
-  jobs: ["build", "jdk21-build", "jdk23-build"]
+  jobs: ["build", "jdk19-build"]
 - name: "releases"
  jobs: ["stage-milestone", "stage-rc", "stage-release", "promote-milestone", "promote-rc", "promote-release", "create-github-release"]
 - name: "ci-images"
  jobs: ["build-ci-images"]
+- name: "pull-requests"
+  jobs: [ "build-pull-requests" ]
@@ -4,6 +4,5 @@ set -e
 source $(dirname $0)/common.sh

 pushd git-repo > /dev/null
-./gradlew -Dorg.gradle.internal.launcher.welcomeMessageEnabled=false -Porg.gradle.java.installations.fromEnv=JDK17,JDK21 \
-  --no-daemon --max-workers=4 check
+./gradlew -Dorg.gradle.internal.launcher.welcomeMessageEnabled=false --no-daemon --max-workers=4 check
 popd > /dev/null
@@ -5,6 +5,5 @@ source $(dirname $0)/common.sh
 repository=$(pwd)/distribution-repository

 pushd git-repo > /dev/null
-./gradlew -Dorg.gradle.internal.launcher.welcomeMessageEnabled=false -Porg.gradle.java.installations.fromEnv=JDK17,JDK21,JDK23 \
-  --no-daemon --max-workers=4 -PdeploymentRepository=${repository} build publishAllPublicationsToDeploymentRepository
+./gradlew -Dorg.gradle.internal.launcher.welcomeMessageEnabled=false --no-daemon --max-workers=4 -PdeploymentRepository=${repository} build publishAllPublicationsToDeploymentRepository
 popd > /dev/null
@@ -4,6 +4,6 @@ set -e
 source $(dirname $0)/common.sh

 pushd git-repo > /dev/null
-./gradlew -Dorg.gradle.internal.launcher.welcomeMessageEnabled=false -Porg.gradle.java.installations.fromEnv=JDK17,JDK21,JDK23 \
-  -PmainToolchain=${MAIN_TOOLCHAIN} -PtestToolchain=${TEST_TOOLCHAIN} --no-daemon --max-workers=4 check antora
+./gradlew -Dorg.gradle.internal.launcher.welcomeMessageEnabled=false -Porg.gradle.java.installations.fromEnv=JDK17,JDK19 \
+  -PmainToolchain=${MAIN_TOOLCHAIN} -PtestToolchain=${TEST_TOOLCHAIN} --no-daemon --max-workers=4 check
 popd > /dev/null
@@ -35,8 +35,7 @@ git add gradle.properties > /dev/null
 git commit -m"Release v$stageVersion" > /dev/null
 git tag -a "v$stageVersion" -m"Release v$stageVersion" > /dev/null

-./gradlew --no-daemon --max-workers=4 -PdeploymentRepository=${repository} -Porg.gradle.java.installations.fromEnv=JDK17,JDK21 \
-  build publishAllPublicationsToDeploymentRepository
+./gradlew --no-daemon --max-workers=4 -PdeploymentRepository=${repository} build publishAllPublicationsToDeploymentRepository

 git reset --hard HEAD^ > /dev/null
 if [[ $nextVersion != $snapshotVersion ]]; then
@@ -4,7 +4,7 @@ image_resource:
  type: registry-image
  source:
    repository: springio/concourse-release-scripts
-    tag: '0.4.0'
+    tag: '0.3.4'
    username: ((docker-hub-username))
    password: ((docker-hub-password))
 inputs:
@@ -1,119 +0,0 @@
-plugins {
-	id 'java-platform'
-	id 'io.freefair.aggregate-javadoc' version '8.3'
-}
-
-description = "Spring Framework API Docs"
-
-apply from: "${rootDir}/gradle/publications.gradle"
-
-repositories {
-	maven {
-		url "https://repo.spring.io/release"
-	}
-}
-
-dependencies {
-	moduleProjects.each { moduleProject ->
-		javadoc moduleProject
-	}
-}
-
-javadoc {
-	title = "${rootProject.description} ${version} API"
-	options {
-		encoding = "UTF-8"
-		memberLevel = JavadocMemberLevel.PROTECTED
-		author = true
-		header = rootProject.description
-		use = true
-		overview = project.relativePath("$rootProject.rootDir/framework-docs/src/docs/api/overview.html")
-		destinationDir = file("$project.docsDir/javadoc-api")
-		splitIndex = true
-		links(rootProject.ext.javadocLinks)
-		addBooleanOption('Xdoclint:syntax,reference', true) // only check syntax and reference with doclint
-		addBooleanOption('Werror', true) // fail build on Javadoc warnings
-	}
-	maxMemory = "1024m"
-	doFirst {
-		classpath += files(
-				// ensure the javadoc process can resolve types compiled from .aj sources
-				project(":spring-aspects").sourceSets.main.output
-		)
-		classpath += files(moduleProjects.collect { it.sourceSets.main.compileClasspath })
-	}
-}
-
-/**
- * Produce KDoc for all Spring Framework modules in "build/docs/kdoc"
- */
-rootProject.tasks.dokkaHtmlMultiModule.configure {
-	dependsOn {
-		tasks.named("javadoc")
-	}
-	moduleName.set("spring-framework")
-	outputDirectory.set(file("$docsDir/kdoc-api"))
-	includes.from("$rootProject.rootDir/framework-docs/src/docs/api/dokka-overview.md")
-}
-
-/**
- * Zip all Java docs (javadoc & kdoc) into a single archive
- */
-tasks.register('docsZip', Zip) {
-	dependsOn = ['javadoc', rootProject.tasks.dokkaHtmlMultiModule]
-	group = "distribution"
-	description = "Builds -${archiveClassifier} archive containing api and reference " +
-			"for deployment at https://docs.spring.io/spring-framework/docs/."
-
-	archiveBaseName.set("spring-framework")
-	archiveClassifier.set("docs")
-	from("src/dist") {
-		include "changelog.txt"
-	}
-	from(javadoc) {
-		into "javadoc-api"
-	}
-	from(rootProject.tasks.dokkaHtmlMultiModule.outputDirectory) {
-		into "kdoc-api"
-	}
-}
-
-/**
- * Zip all Spring Framework schemas into a single archive
- */
-tasks.register('schemaZip', Zip) {
-	group = "distribution"
-	archiveBaseName.set("spring-framework")
-	archiveClassifier.set("schema")
-	description = "Builds -${archiveClassifier} archive containing all " +
-			"XSDs for deployment at https://springframework.org/schema."
-	duplicatesStrategy DuplicatesStrategy.EXCLUDE
-	moduleProjects.each { module ->
-		def Properties schemas = new Properties();
-
-		module.sourceSets.main.resources.find {
-			(it.path.endsWith("META-INF/spring.schemas") || it.path.endsWith("META-INF\\spring.schemas"))
-		}?.withInputStream { schemas.load(it) }
-
-		for (def key : schemas.keySet()) {
-			def shortName = key.replaceAll(/http.*schema.(.*).spring-.*/, '$1')
-			assert shortName != key
-			File xsdFile = module.sourceSets.main.resources.find {
-				(it.path.endsWith(schemas.get(key)) || it.path.endsWith(schemas.get(key).replaceAll('\\/', '\\\\')))
-			}
-			assert xsdFile != null
-			into(shortName) {
-				from xsdFile.path
-			}
-		}
-	}
-}
-
-publishing {
-	publications {
-		mavenJava(MavenPublication) {
-			artifact docsZip
-			artifact schemaZip
-		}
-	}
-}
@@ -1,90 +0,0 @@
-name: framework
-version: true
-title: Spring Framework
-nav:
-  - modules/ROOT/nav.adoc
-ext:
-  collector:
-    run:
-      command: gradlew -q -PbuildSrc.skipTests=true "-Dorg.gradle.jvmargs=-Xmx3g -XX:+HeapDumpOnOutOfMemoryError" :framework-docs:generateAntoraResources
-      local: true
-    scan:
-      dir: ./build/generated-antora-resources
-
-asciidoc:
-  attributes:
-    attribute-missing: 'warn'
-    # FIXME: the copyright is not removed
-    # FIXME: The package is not renamed
-    chomp: 'all'
-    fold: 'all'
-    table-stripes: 'odd'
-    include-java: 'example$docs-src/main/java/org/springframework/docs'
-    spring-site: 'https://spring.io'
-    spring-site-blog: '{spring-site}/blog'
-    spring-site-cve: "{spring-site}/security"
-    spring-site-guides: '{spring-site}/guides'
-    spring-site-projects: '{spring-site}/projects'
-    spring-site-tools: "{spring-site}/tools"
-    spring-org: 'spring-projects'
-    spring-github-org: "https://github.com/{spring-org}"
-    spring-framework-github: "https://github.com/{spring-org}/spring-framework"
-    spring-framework-code: '{spring-framework-github}/tree/main'
-    spring-framework-issues: '{spring-framework-github}/issues'
-    spring-framework-wiki: '{spring-framework-github}/wiki'
-    # Docs
-    docs-site: 'https://docs.spring.io'
-    spring-framework-docs-root: '{docs-site}/spring-framework/docs'
-    spring-framework-api: '{spring-framework-docs-root}/{spring-version}/javadoc-api/org/springframework'
-    spring-framework-api-kdoc: '{spring-framework-docs-root}/{spring-version}/kdoc-api'
-    spring-framework-reference: '{spring-framework-docs-root}/{spring-version}/reference'
-    #
-    # Other Spring portfolio projects
-    spring-boot-docs: '{docs-site}/spring-boot/docs/current/reference/html'
-    spring-boot-issues: '{spring-github-org}/spring-boot/issues'
-    # TODO add more projects / links or just build up on {docs-site}?
-    # TODO rename the below using new conventions
-    docs-spring-gemfire: '{docs-site}/spring-gemfire/docs/current/reference'
-    docs-spring-security: '{docs-site}/spring-security/reference'
-    docs-spring-session: '{docs-site}/spring-session/reference'
-    #
-    # External projects URLs and related attributes
-    aspectj-site: 'https://www.eclipse.org/aspectj'
-    aspectj-docs: "{aspectj-site}/doc/released"
-    aspectj-api: "{aspectj-docs}/runtime-api"
-    aspectj-docs-devguide: "{aspectj-docs}/devguide"
-    aspectj-docs-progguide: "{aspectj-docs}/progguide"
-    assertj-docs: 'https://assertj.github.io/doc'
-    baeldung-blog: 'https://www.baeldung.com'
-    bean-validation-site: 'https://beanvalidation.org'
-    graalvm-docs: 'https://www.graalvm.org/22.3/reference-manual'
-    hibernate-validator-site: 'https://hibernate.org/validator/'
-    jackson-docs: 'https://fasterxml.github.io'
-    jackson-github-org: 'https://github.com/FasterXML'
-    java-api: 'https://docs.oracle.com/en/java/javase/17/docs/api'
-    java-tutorial: 'https://docs.oracle.com/javase/tutorial'
-    JSR: 'https://www.jcp.org/en/jsr/detail?id='
-    kotlin-site: 'https://kotlinlang.org'
-    kotlin-docs: '{kotlin-site}/docs'
-    kotlin-api: '{kotlin-site}/api/latest'
-    kotlin-coroutines-api: '{kotlin-site}/api/kotlinx.coroutines'
-    kotlin-github-org: 'https://github.com/Kotlin'
-    kotlin-issues: 'https://youtrack.jetbrains.com/issue'
-    reactive-streams-site: 'https://www.reactive-streams.org'
-    reactive-streams-spec: 'https://github.com/reactive-streams/reactive-streams-jvm/blob/master/README.md#specification'
-    reactor-github-org: 'https://github.com/reactor'
-    reactor-site: 'https://projectreactor.io'
-    rsocket-github-org: 'https://github.com/rsocket'
-    rsocket-java: '{rsocket-github-org}/rsocket-java'
-    rsocket-java-code: '{rsocket-java}/tree/master/'
-    rsocket-protocol-extensions: '{rsocket-github-org}/rsocket/tree/master/Extensions'
-    rsocket-site: 'https://rsocket.io'
-    rfc-site: 'https://datatracker.ietf.org/doc/html'
-    sockjs-client: 'https://github.com/sockjs/sockjs-client'
-    sockjs-protocol: 'https://github.com/sockjs/sockjs-protocol'
-    sockjs-protocol-site: "https://sockjs.github.io/sockjs-protocol"
-    stackoverflow-site: 'https://stackoverflow.com'
-    stackoverflow-questions: '{stackoverflow-site}/questions'
-    stackoverflow-spring-tag: "{stackoverflow-questions}/tagged/spring"
-    stackoverflow-spring-kotlin-tags: "{stackoverflow-spring-tag}+kotlin"
-    testcontainers-site: 'https://www.testcontainers.org'
@@ -1,47 +1,22 @@
-plugins {
-	id 'kotlin'
-	id 'io.spring.antora.generate-antora-yml' version '0.0.1'
-	id 'org.antora' version '1.0.0'
-}
-
 description = "Spring Framework Docs"

-apply from: "${rootDir}/gradle/ide.gradle"
+apply plugin: 'kotlin'
+apply plugin: 'org.asciidoctor.jvm.convert'
+apply plugin: 'org.asciidoctor.jvm.pdf'
 apply from: "${rootDir}/gradle/publications.gradle"

-antora {
-	version = '3.2.0-alpha.2'
-	playbook = 'cached-antora-playbook.yml'
-	playbookProvider {
-		repository = 'spring-projects/spring-framework'
-		branch = 'docs-build'
-		path = 'lib/antora/templates/per-branch-antora-playbook.yml'
-		checkLocalBranch = true
-	}
-	options = ['--clean', '--stacktrace']
-	environment = [
-			'ALGOLIA_API_KEY': '82c7ead946afbac3cf98c32446154691',
-			'ALGOLIA_APP_ID': '244V8V9FGG',
-			'ALGOLIA_INDEX_NAME': 'framework-docs'
-	]
-	dependencies = [
-			'@antora/atlas-extension': '1.0.0-alpha.1',
-			'@antora/collector-extension': '1.0.0-alpha.3',
-			'@asciidoctor/tabs': '1.0.0-beta.3',
-			'@opendevise/antora-release-line-extension': '1.0.0',
-			'@springio/antora-extensions': '1.8.2',
-			'@springio/asciidoctor-extensions': '1.0.0-alpha.9'
-	]
+
+configurations {
+	asciidoctorExtensions
 }

-tasks.named("generateAntoraYml") {
-	asciidocAttributes = project.provider( {
-		return  ["spring-version": project.version ]
-	} )
-}
+dependencies {
+	api(project(":spring-context"))
+	api(project(":spring-web"))
+	api("jakarta.servlet:jakarta.servlet-api")

-tasks.register("generateAntoraResources") {
-	dependsOn 'generateAntoraYml'
+	implementation(project(":spring-core-test"))
+	implementation("org.assertj:assertj-core")
 }

 jar {
@@ -52,19 +27,228 @@ javadoc {
 	enabled = false
 }

-repositories {
-	maven {
-		url "https://repo.spring.io/release"
+dependencies {
+	asciidoctorExtensions "io.spring.asciidoctor.backends:spring-asciidoctor-backends:0.0.5"
+}
+
+/**
+ * Produce Javadoc for all Spring Framework modules in "build/docs/javadoc"
+ */
+task api(type: Javadoc) {
+	group = "Documentation"
+	description = "Generates aggregated Javadoc API documentation."
+	title = "${rootProject.description} ${version} API"
+
+	dependsOn {
+		moduleProjects.collect {
+			it.tasks.getByName("jar")
+		}
+	}
+	doFirst {
+		classpath = files(
+				// ensure the javadoc process can resolve types compiled from .aj sources
+				project(":spring-aspects").sourceSets.main.output
+		)
+		classpath += files(moduleProjects.collect { it.sourceSets.main.compileClasspath })
+	}
+
+	options {
+		encoding = "UTF-8"
+		memberLevel = JavadocMemberLevel.PROTECTED
+		author = true
+		header = rootProject.description
+		use = true
+		overview = "framework-docs/src/docs/api/overview.html"
+		splitIndex = true
+		links(project.ext.javadocLinks)
+		addBooleanOption('Xdoclint:syntax', true) // only check syntax with doclint
+		addBooleanOption('Werror', true) // fail build on Javadoc warnings
+	}
+	source moduleProjects.collect { project ->
+		project.sourceSets.main.allJava
+	}
+	maxMemory = "1024m"
+	destinationDir = file("$buildDir/docs/javadoc")
+}
+
+/**
+ * Produce KDoc for all Spring Framework modules in "build/docs/kdoc"
+ */
+rootProject.tasks.dokkaHtmlMultiModule.configure {
+	dependsOn {
+		tasks.getByName("api")
+	}
+	moduleName.set("spring-framework")
+	outputDirectory.set(project.file("$buildDir/docs/kdoc"))
+}
+
+asciidoctorj {
+	version = '2.4.3'
+	fatalWarnings ".*"
+	options doctype: 'book', eruby: 'erubis'
+	attributes([
+			icons: 'font',
+			idprefix: '',
+			idseparator: '-',
+			revnumber: project.version,
+			sectanchors: '',
+			sectnums: '',
+			'spring-version': project.version
+	])
+}
+
+/**
+ * Generate the Spring Framework Reference documentation from
+ * "src/docs/asciidoc" in "build/docs/ref-docs/html5".
+ */
+asciidoctor {
+	baseDirFollowsSourceDir()
+	configurations "asciidoctorExtensions"
+	sources {
+		include '*.adoc'
+	}
+	resources {
+		from(sourceDir) {
+			include 'images/*.png'
+		}
+	}
+	outputDir "$buildDir/docs/ref-docs/html5"
+	outputOptions {
+		backends "spring-html"
+	}
+	forkOptions {
+		jvmArgs += ["--add-opens", "java.base/sun.nio.ch=ALL-UNNAMED", "--add-opens", "java.base/java.io=ALL-UNNAMED"]
+	}
+	logDocuments = true
+}
+
+asciidoctor.mustRunAfter "check"
+
+/**
+ * Generate the Spring Framework Reference documentation from "src/docs/asciidoc"
+ * in "build/docs/ref-docs/pdf".
+ */
+asciidoctorPdf {
+	baseDirFollowsSourceDir()
+	configurations 'asciidoctorExtensions'
+	sources {
+		include 'spring-framework.adocbook'
+	}
+	outputDir "$buildDir/docs/ref-docs/pdf"
+	forkOptions {
+		jvmArgs += ["--add-opens", "java.base/sun.nio.ch=ALL-UNNAMED", "--add-opens", "java.base/java.io=ALL-UNNAMED"]
+	}
+	logDocuments = true
+}
+
+/**
+ * Zip all docs (API and reference) into a single archive
+ */
+task docsZip(type: Zip, dependsOn: ['api', 'asciidoctor', 'asciidoctorPdf', rootProject.tasks.dokkaHtmlMultiModule]) {
+	group = "Distribution"
+	description = "Builds -${archiveClassifier} archive containing api and reference " +
+			"for deployment at https://docs.spring.io/spring-framework/docs/."
+
+	archiveBaseName.set("spring-framework")
+	archiveClassifier.set("docs")
+	from("src/dist") {
+		include "changelog.txt"
+	}
+	from (api) {
+		into "javadoc-api"
+	}
+	from ("$asciidoctor.outputDir") {
+		into "reference/html"
+	}
+	from ("$asciidoctorPdf.outputDir") {
+		into "reference/pdf"
+	}
+	from (rootProject.tasks.dokkaHtmlMultiModule.outputDirectory) {
+		into "kdoc-api"
 	}
 }

-dependencies {
-	api(project(":spring-context"))
-	api(project(":spring-jms"))
-	api(project(":spring-web"))
-	api("jakarta.jms:jakarta.jms-api")
-	api("jakarta.servlet:jakarta.servlet-api")
+/**
+ * Zip all Spring Framework schemas into a single archive
+ */
+task schemaZip(type: Zip) {
+	group = "Distribution"
+	archiveBaseName.set("spring-framework")
+	archiveClassifier.set("schema")
+	description = "Builds -${archiveClassifier} archive containing all " +
+			"XSDs for deployment at https://springframework.org/schema."
+	duplicatesStrategy DuplicatesStrategy.EXCLUDE
+	moduleProjects.each { module ->
+		def Properties schemas = new Properties();

-	implementation(project(":spring-core-test"))
-	implementation("org.assertj:assertj-core")
+		module.sourceSets.main.resources.find {
+			(it.path.endsWith("META-INF/spring.schemas") || it.path.endsWith("META-INF\\spring.schemas"))
+		}?.withInputStream { schemas.load(it) }
+
+		for (def key : schemas.keySet()) {
+			def shortName = key.replaceAll(/http.*schema.(.*).spring-.*/, '$1')
+			assert shortName != key
+			File xsdFile = module.sourceSets.main.resources.find {
+				(it.path.endsWith(schemas.get(key)) || it.path.endsWith(schemas.get(key).replaceAll('\\/','\\\\')))
+			}
+			assert xsdFile != null
+			into (shortName) {
+				from xsdFile.path
+			}
+		}
+	}
+}
+
+/**
+ * Create a distribution zip with everything:
+ * docs, schemas, jars, source jars, javadoc jars
+ */
+task distZip(type: Zip, dependsOn: [docsZip, schemaZip]) {
+	group = "Distribution"
+	archiveBaseName.set("spring-framework")
+	archiveClassifier.set("dist")
+	description = "Builds -${archiveClassifier} archive, containing all jars and docs, " +
+			"suitable for community download page."
+
+	ext.baseDir = "spring-framework-${project.version}";
+
+	from("src/docs/dist") {
+		include "readme.txt"
+		include "license.txt"
+		include "notice.txt"
+		into "${baseDir}"
+		expand(copyright: new Date().format("yyyy"), version: project.version)
+	}
+
+	from(zipTree(docsZip.archiveFile)) {
+		into "${baseDir}/docs"
+	}
+
+	from(zipTree(schemaZip.archiveFile)) {
+		into "${baseDir}/schema"
+	}
+
+	moduleProjects.each { module ->
+		into ("${baseDir}/libs") {
+			from module.jar
+			if (module.tasks.findByPath("sourcesJar")) {
+				from module.sourcesJar
+			}
+			if (module.tasks.findByPath("javadocJar")) {
+				from module.javadocJar
+			}
+		}
+	}
+}
+
+distZip.mustRunAfter moduleProjects.check
+
+publishing {
+	publications {
+		mavenJava(MavenPublication) {
+			artifact docsZip
+			artifact schemaZip
+			artifact distZip
+		}
+	}
 }
@@ -1 +0,0 @@
-../../../src
@@ -1,443 +0,0 @@
-* xref:overview.adoc[Overview]
-* xref:core.adoc[]
-** xref:core/beans.adoc[]
-*** xref:core/beans/introduction.adoc[]
-*** xref:core/beans/basics.adoc[]
-*** xref:core/beans/definition.adoc[]
-*** xref:core/beans/dependencies.adoc[]
-**** xref:core/beans/dependencies/factory-collaborators.adoc[]
-**** xref:core/beans/dependencies/factory-properties-detailed.adoc[]
-**** xref:core/beans/dependencies/factory-dependson.adoc[]
-**** xref:core/beans/dependencies/factory-lazy-init.adoc[]
-**** xref:core/beans/dependencies/factory-autowire.adoc[]
-**** xref:core/beans/dependencies/factory-method-injection.adoc[]
-*** xref:core/beans/factory-scopes.adoc[]
-*** xref:core/beans/factory-nature.adoc[]
-*** xref:core/beans/child-bean-definitions.adoc[]
-*** xref:core/beans/factory-extension.adoc[]
-*** xref:core/beans/annotation-config.adoc[]
-**** xref:core/beans/annotation-config/autowired.adoc[]
-**** xref:core/beans/annotation-config/autowired-primary.adoc[]
-**** xref:core/beans/annotation-config/autowired-qualifiers.adoc[]
-**** xref:core/beans/annotation-config/generics-as-qualifiers.adoc[]
-**** xref:core/beans/annotation-config/custom-autowire-configurer.adoc[]
-**** xref:core/beans/annotation-config/resource.adoc[]
-**** xref:core/beans/annotation-config/value-annotations.adoc[]
-**** xref:core/beans/annotation-config/postconstruct-and-predestroy-annotations.adoc[]
-*** xref:core/beans/classpath-scanning.adoc[]
-*** xref:core/beans/standard-annotations.adoc[]
-*** xref:core/beans/java.adoc[]
-**** xref:core/beans/java/basic-concepts.adoc[]
-**** xref:core/beans/java/instantiating-container.adoc[]
-**** xref:core/beans/java/bean-annotation.adoc[]
-**** xref:core/beans/java/configuration-annotation.adoc[]
-**** xref:core/beans/java/composing-configuration-classes.adoc[]
-*** xref:core/beans/environment.adoc[]
-*** xref:core/beans/context-load-time-weaver.adoc[]
-*** xref:core/beans/context-introduction.adoc[]
-*** xref:core/beans/beanfactory.adoc[]
-** xref:core/resources.adoc[]
-** xref:core/validation.adoc[]
-*** xref:core/validation/validator.adoc[]
-*** xref:core/validation/beans-beans.adoc[]
-*** xref:core/validation/conversion.adoc[]
-*** xref:core/validation/convert.adoc[]
-*** xref:core/validation/format.adoc[]
-*** xref:core/validation/format-configuring-formatting-globaldatetimeformat.adoc[]
-*** xref:core/validation/beanvalidation.adoc[]
-** xref:core/expressions.adoc[]
-*** xref:core/expressions/evaluation.adoc[]
-*** xref:core/expressions/beandef.adoc[]
-*** xref:core/expressions/language-ref.adoc[]
-**** xref:core/expressions/language-ref/literal.adoc[]
-**** xref:core/expressions/language-ref/properties-arrays.adoc[]
-**** xref:core/expressions/language-ref/inline-lists.adoc[]
-**** xref:core/expressions/language-ref/inline-maps.adoc[]
-**** xref:core/expressions/language-ref/array-construction.adoc[]
-**** xref:core/expressions/language-ref/methods.adoc[]
-**** xref:core/expressions/language-ref/operators.adoc[]
-**** xref:core/expressions/language-ref/types.adoc[]
-**** xref:core/expressions/language-ref/constructors.adoc[]
-**** xref:core/expressions/language-ref/variables.adoc[]
-**** xref:core/expressions/language-ref/functions.adoc[]
-**** xref:core/expressions/language-ref/bean-references.adoc[]
-**** xref:core/expressions/language-ref/operator-ternary.adoc[]
-**** xref:core/expressions/language-ref/operator-elvis.adoc[]
-**** xref:core/expressions/language-ref/operator-safe-navigation.adoc[]
-**** xref:core/expressions/language-ref/collection-selection.adoc[]
-**** xref:core/expressions/language-ref/collection-projection.adoc[]
-**** xref:core/expressions/language-ref/templating.adoc[]
-*** xref:core/expressions/example-classes.adoc[]
-** xref:core/aop.adoc[]
-*** xref:core/aop/introduction-defn.adoc[]
-*** xref:core/aop/introduction-spring-defn.adoc[]
-*** xref:core/aop/introduction-proxies.adoc[]
-*** xref:core/aop/ataspectj.adoc[]
-**** xref:core/aop/ataspectj/aspectj-support.adoc[]
-**** xref:core/aop/ataspectj/at-aspectj.adoc[]
-**** xref:core/aop/ataspectj/pointcuts.adoc[]
-**** xref:core/aop/ataspectj/advice.adoc[]
-**** xref:core/aop/ataspectj/introductions.adoc[]
-**** xref:core/aop/ataspectj/instantiation-models.adoc[]
-**** xref:core/aop/ataspectj/example.adoc[]
-*** xref:core/aop/schema.adoc[]
-*** xref:core/aop/choosing.adoc[]
-*** xref:core/aop/mixing-styles.adoc[]
-*** xref:core/aop/proxying.adoc[]
-*** xref:core/aop/aspectj-programmatic.adoc[]
-*** xref:core/aop/using-aspectj.adoc[]
-*** xref:core/aop/resources.adoc[]
-** xref:core/aop-api.adoc[]
-*** xref:core/aop-api/pointcuts.adoc[]
-*** xref:core/aop-api/advice.adoc[]
-*** xref:core/aop-api/advisor.adoc[]
-*** xref:core/aop-api/pfb.adoc[]
-*** xref:core/aop-api/concise-proxy.adoc[]
-*** xref:core/aop-api/prog.adoc[]
-*** xref:core/aop-api/advised.adoc[]
-*** xref:core/aop-api/autoproxy.adoc[]
-*** xref:core/aop-api/targetsource.adoc[]
-*** xref:core/aop-api/extensibility.adoc[]
-** xref:core/null-safety.adoc[]
-** xref:core/databuffer-codec.adoc[]
-** xref:core/spring-jcl.adoc[]
-** xref:core/aot.adoc[]
-** xref:core/appendix.adoc[]
-*** xref:core/appendix/xsd-schemas.adoc[]
-*** xref:core/appendix/xml-custom.adoc[]
-*** xref:core/appendix/application-startup-steps.adoc[]
-* xref:testing.adoc[]
-** xref:testing/introduction.adoc[]
-** xref:testing/unit.adoc[]
-** xref:testing/integration.adoc[]
-** xref:testing/support-jdbc.adoc[]
-** xref:testing/testcontext-framework.adoc[]
-*** xref:testing/testcontext-framework/key-abstractions.adoc[]
-*** xref:testing/testcontext-framework/bootstrapping.adoc[]
-*** xref:testing/testcontext-framework/tel-config.adoc[]
-*** xref:testing/testcontext-framework/application-events.adoc[]
-*** xref:testing/testcontext-framework/test-execution-events.adoc[]
-*** xref:testing/testcontext-framework/ctx-management.adoc[]
-**** xref:testing/testcontext-framework/ctx-management/xml.adoc[]
-**** xref:testing/testcontext-framework/ctx-management/groovy.adoc[]
-**** xref:testing/testcontext-framework/ctx-management/javaconfig.adoc[]
-**** xref:testing/testcontext-framework/ctx-management/mixed-config.adoc[]
-**** xref:testing/testcontext-framework/ctx-management/context-customizers.adoc[]
-**** xref:testing/testcontext-framework/ctx-management/initializers.adoc[]
-**** xref:testing/testcontext-framework/ctx-management/inheritance.adoc[]
-**** xref:testing/testcontext-framework/ctx-management/env-profiles.adoc[]
-**** xref:testing/testcontext-framework/ctx-management/property-sources.adoc[]
-**** xref:testing/testcontext-framework/ctx-management/dynamic-property-sources.adoc[]
-**** xref:testing/testcontext-framework/ctx-management/web.adoc[]
-**** xref:testing/testcontext-framework/ctx-management/web-mocks.adoc[]
-**** xref:testing/testcontext-framework/ctx-management/caching.adoc[]
-**** xref:testing/testcontext-framework/ctx-management/failure-threshold.adoc[]
-**** xref:testing/testcontext-framework/ctx-management/hierarchies.adoc[]
-*** xref:testing/testcontext-framework/fixture-di.adoc[]
-*** xref:testing/testcontext-framework/web-scoped-beans.adoc[]
-*** xref:testing/testcontext-framework/tx.adoc[]
-*** xref:testing/testcontext-framework/executing-sql.adoc[]
-*** xref:testing/testcontext-framework/parallel-test-execution.adoc[]
-*** xref:testing/testcontext-framework/support-classes.adoc[]
-*** xref:testing/testcontext-framework/aot.adoc[]
-** xref:testing/webtestclient.adoc[]
-** xref:testing/spring-mvc-test-framework.adoc[]
-*** xref:testing/spring-mvc-test-framework/server.adoc[]
-*** xref:testing/spring-mvc-test-framework/server-static-imports.adoc[]
-*** xref:testing/spring-mvc-test-framework/server-setup-options.adoc[]
-*** xref:testing/spring-mvc-test-framework/server-setup-steps.adoc[]
-*** xref:testing/spring-mvc-test-framework/server-performing-requests.adoc[]
-*** xref:testing/spring-mvc-test-framework/server-defining-expectations.adoc[]
-*** xref:testing/spring-mvc-test-framework/async-requests.adoc[]
-*** xref:testing/spring-mvc-test-framework/vs-streaming-response.adoc[]
-*** xref:testing/spring-mvc-test-framework/server-filters.adoc[]
-*** xref:testing/spring-mvc-test-framework/vs-end-to-end-integration-tests.adoc[]
-*** xref:testing/spring-mvc-test-framework/server-resources.adoc[]
-*** xref:testing/spring-mvc-test-framework/server-htmlunit.adoc[]
-**** xref:testing/spring-mvc-test-framework/server-htmlunit/why.adoc[]
-**** xref:testing/spring-mvc-test-framework/server-htmlunit/mah.adoc[]
-**** xref:testing/spring-mvc-test-framework/server-htmlunit/webdriver.adoc[]
-**** xref:testing/spring-mvc-test-framework/server-htmlunit/geb.adoc[]
-** xref:testing/spring-mvc-test-client.adoc[]
-** xref:testing/appendix.adoc[]
-*** xref:testing/annotations.adoc[]
-**** xref:testing/annotations/integration-standard.adoc[]
-**** xref:testing/annotations/integration-spring.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-bootstrapwith.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-contextconfiguration.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-webappconfiguration.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-contexthierarchy.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-contextcustomizerfactories.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-activeprofiles.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-testpropertysource.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-dynamicpropertysource.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-dirtiescontext.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-testexecutionlisteners.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-recordapplicationevents.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-commit.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-rollback.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-beforetransaction.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-aftertransaction.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-sql.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-sqlconfig.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-sqlmergemode.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-sqlgroup.adoc[]
-***** xref:testing/annotations/integration-spring/annotation-disabledinaotmode.adoc[]
-**** xref:testing/annotations/integration-junit4.adoc[]
-**** xref:testing/annotations/integration-junit-jupiter.adoc[]
-**** xref:testing/annotations/integration-meta.adoc[]
-*** xref:testing/resources.adoc[]
-* xref:data-access.adoc[]
-** xref:data-access/transaction.adoc[]
-*** xref:data-access/transaction/motivation.adoc[]
-*** xref:data-access/transaction/strategies.adoc[]
-*** xref:data-access/transaction/tx-resource-synchronization.adoc[]
-*** xref:data-access/transaction/declarative.adoc[]
-**** xref:data-access/transaction/declarative/tx-decl-explained.adoc[]
-**** xref:data-access/transaction/declarative/first-example.adoc[]
-**** xref:data-access/transaction/declarative/rolling-back.adoc[]
-**** xref:data-access/transaction/declarative/diff-tx.adoc[]
-**** xref:data-access/transaction/declarative/txadvice-settings.adoc[]
-**** xref:data-access/transaction/declarative/annotations.adoc[]
-**** xref:data-access/transaction/declarative/tx-propagation.adoc[]
-**** xref:data-access/transaction/declarative/applying-more-than-just-tx-advice.adoc[]
-**** xref:data-access/transaction/declarative/aspectj.adoc[]
-*** xref:data-access/transaction/programmatic.adoc[]
-*** xref:data-access/transaction/tx-decl-vs-prog.adoc[]
-*** xref:data-access/transaction/event.adoc[]
-*** xref:data-access/transaction/application-server-integration.adoc[]
-*** xref:data-access/transaction/solutions-to-common-problems.adoc[]
-*** xref:data-access/transaction/resources.adoc[]
-** xref:data-access/dao.adoc[]
-** xref:data-access/jdbc.adoc[]
-*** xref:data-access/jdbc/choose-style.adoc[]
-*** xref:data-access/jdbc/packages.adoc[]
-*** xref:data-access/jdbc/core.adoc[]
-*** xref:data-access/jdbc/connections.adoc[]
-*** xref:data-access/jdbc/advanced.adoc[]
-*** xref:data-access/jdbc/simple.adoc[]
-*** xref:data-access/jdbc/object.adoc[]
-*** xref:data-access/jdbc/parameter-handling.adoc[]
-*** xref:data-access/jdbc/embedded-database-support.adoc[]
-*** xref:data-access/jdbc/initializing-datasource.adoc[]
-** xref:data-access/r2dbc.adoc[]
-** xref:data-access/orm.adoc[]
-*** xref:data-access/orm/introduction.adoc[]
-*** xref:data-access/orm/general.adoc[]
-*** xref:data-access/orm/hibernate.adoc[]
-*** xref:data-access/orm/jpa.adoc[]
-** xref:data-access/oxm.adoc[]
-** xref:data-access/appendix.adoc[]
-* xref:web.adoc[]
-** xref:web/webmvc.adoc[]
-*** xref:web/webmvc/mvc-servlet.adoc[]
-**** xref:web/webmvc/mvc-servlet/context-hierarchy.adoc[]
-**** xref:web/webmvc/mvc-servlet/special-bean-types.adoc[]
-**** xref:web/webmvc/mvc-servlet/config.adoc[]
-**** xref:web/webmvc/mvc-servlet/container-config.adoc[]
-**** xref:web/webmvc/mvc-servlet/sequence.adoc[]
-**** xref:web/webmvc/mvc-servlet/handlermapping-path.adoc[]
-**** xref:web/webmvc/mvc-servlet/handlermapping-interceptor.adoc[]
-**** xref:web/webmvc/mvc-servlet/exceptionhandlers.adoc[]
-**** xref:web/webmvc/mvc-servlet/viewresolver.adoc[]
-**** xref:web/webmvc/mvc-servlet/localeresolver.adoc[]
-**** xref:web/webmvc/mvc-servlet/themeresolver.adoc[]
-**** xref:web/webmvc/mvc-servlet/multipart.adoc[]
-**** xref:web/webmvc/mvc-servlet/logging.adoc[]
-*** xref:web/webmvc/filters.adoc[]
-*** xref:web/webmvc/mvc-controller.adoc[]
-**** xref:web/webmvc/mvc-controller/ann.adoc[]
-**** xref:web/webmvc/mvc-controller/ann-requestmapping.adoc[]
-**** xref:web/webmvc/mvc-controller/ann-methods.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/arguments.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/return-types.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/typeconversion.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/matrix-variables.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/requestparam.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/requestheader.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/cookievalue.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/modelattrib-method-args.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/sessionattributes.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/sessionattribute.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/requestattrib.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/redirecting-passing-data.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/flash-attributes.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/multipart-forms.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/requestbody.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/httpentity.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/responsebody.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/responseentity.adoc[]
-***** xref:web/webmvc/mvc-controller/ann-methods/jackson.adoc[]
-**** xref:web/webmvc/mvc-controller/ann-modelattrib-methods.adoc[]
-**** xref:web/webmvc/mvc-controller/ann-initbinder.adoc[]
-**** xref:web/webmvc/mvc-controller/ann-validation.adoc[]
-**** xref:web/webmvc/mvc-controller/ann-exceptionhandler.adoc[]
-**** xref:web/webmvc/mvc-controller/ann-advice.adoc[]
-*** xref:web/webmvc-functional.adoc[]
-*** xref:web/webmvc/mvc-uri-building.adoc[]
-*** xref:web/webmvc/mvc-ann-async.adoc[]
-*** xref:web/webmvc-cors.adoc[]
-*** xref:web/webmvc/mvc-ann-rest-exceptions.adoc[]
-*** xref:web/webmvc/mvc-security.adoc[]
-*** xref:web/webmvc/mvc-caching.adoc[]
-*** xref:web/webmvc-view.adoc[]
-**** xref:web/webmvc-view/mvc-thymeleaf.adoc[]
-**** xref:web/webmvc-view/mvc-freemarker.adoc[]
-**** xref:web/webmvc-view/mvc-groovymarkup.adoc[]
-**** xref:web/webmvc-view/mvc-script.adoc[]
-**** xref:web/webmvc-view/mvc-jsp.adoc[]
-**** xref:web/webmvc-view/mvc-feeds.adoc[]
-**** xref:web/webmvc-view/mvc-document.adoc[]
-**** xref:web/webmvc-view/mvc-jackson.adoc[]
-**** xref:web/webmvc-view/mvc-xml-marshalling.adoc[]
-**** xref:web/webmvc-view/mvc-xslt.adoc[]
-*** xref:web/webmvc/mvc-config.adoc[]
-**** xref:web/webmvc/mvc-config/enable.adoc[]
-**** xref:web/webmvc/mvc-config/customize.adoc[]
-**** xref:web/webmvc/mvc-config/conversion.adoc[]
-**** xref:web/webmvc/mvc-config/validation.adoc[]
-**** xref:web/webmvc/mvc-config/interceptors.adoc[]
-**** xref:web/webmvc/mvc-config/content-negotiation.adoc[]
-**** xref:web/webmvc/mvc-config/message-converters.adoc[]
-**** xref:web/webmvc/mvc-config/view-controller.adoc[]
-**** xref:web/webmvc/mvc-config/view-resolvers.adoc[]
-**** xref:web/webmvc/mvc-config/static-resources.adoc[]
-**** xref:web/webmvc/mvc-config/default-servlet-handler.adoc[]
-**** xref:web/webmvc/mvc-config/path-matching.adoc[]
-**** xref:web/webmvc/mvc-config/advanced-java.adoc[]
-**** xref:web/webmvc/mvc-config/advanced-xml.adoc[]
-*** xref:web/webmvc/mvc-http2.adoc[]
-** xref:web/webmvc-client.adoc[]
-** xref:web/webmvc-test.adoc[]
-** xref:web/websocket.adoc[]
-*** xref:web/websocket/server.adoc[]
-*** xref:web/websocket/fallback.adoc[]
-*** xref:web/websocket/stomp.adoc[]
-**** xref:web/websocket/stomp/overview.adoc[]
-**** xref:web/websocket/stomp/benefits.adoc[]
-**** xref:web/websocket/stomp/enable.adoc[]
-**** xref:web/websocket/stomp/server-config.adoc[]
-**** xref:web/websocket/stomp/message-flow.adoc[]
-**** xref:web/websocket/stomp/handle-annotations.adoc[]
-**** xref:web/websocket/stomp/handle-send.adoc[]
-**** xref:web/websocket/stomp/handle-simple-broker.adoc[]
-**** xref:web/websocket/stomp/handle-broker-relay.adoc[]
-**** xref:web/websocket/stomp/handle-broker-relay-configure.adoc[]
-**** xref:web/websocket/stomp/destination-separator.adoc[]
-**** xref:web/websocket/stomp/authentication.adoc[]
-**** xref:web/websocket/stomp/authentication-token-based.adoc[]
-**** xref:web/websocket/stomp/authorization.adoc[]
-**** xref:web/websocket/stomp/user-destination.adoc[]
-**** xref:web/websocket/stomp/ordered-messages.adoc[]
-**** xref:web/websocket/stomp/application-context-events.adoc[]
-**** xref:web/websocket/stomp/interceptors.adoc[]
-**** xref:web/websocket/stomp/client.adoc[]
-**** xref:web/websocket/stomp/scope.adoc[]
-**** xref:web/websocket/stomp/configuration-performance.adoc[]
-**** xref:web/websocket/stomp/stats.adoc[]
-**** xref:web/websocket/stomp/testing.adoc[]
-** xref:web/integration.adoc[]
-* xref:web-reactive.adoc[]
-** xref:web/webflux.adoc[]
-*** xref:web/webflux/new-framework.adoc[]
-*** xref:web/webflux/reactive-spring.adoc[]
-*** xref:web/webflux/dispatcher-handler.adoc[]
-*** xref:web/webflux/controller.adoc[]
-**** xref:web/webflux/controller/ann.adoc[]
-**** xref:web/webflux/controller/ann-requestmapping.adoc[]
-**** xref:web/webflux/controller/ann-methods.adoc[]
-***** xref:web/webflux/controller/ann-methods/arguments.adoc[]
-***** xref:web/webflux/controller/ann-methods/return-types.adoc[]
-***** xref:web/webflux/controller/ann-methods/typeconversion.adoc[]
-***** xref:web/webflux/controller/ann-methods/matrix-variables.adoc[]
-***** xref:web/webflux/controller/ann-methods/requestparam.adoc[]
-***** xref:web/webflux/controller/ann-methods/requestheader.adoc[]
-***** xref:web/webflux/controller/ann-methods/cookievalue.adoc[]
-***** xref:web/webflux/controller/ann-methods/modelattrib-method-args.adoc[]
-***** xref:web/webflux/controller/ann-methods/sessionattributes.adoc[]
-***** xref:web/webflux/controller/ann-methods/sessionattribute.adoc[]
-***** xref:web/webflux/controller/ann-methods/requestattrib.adoc[]
-***** xref:web/webflux/controller/ann-methods/multipart-forms.adoc[]
-***** xref:web/webflux/controller/ann-methods/requestbody.adoc[]
-***** xref:web/webflux/controller/ann-methods/httpentity.adoc[]
-***** xref:web/webflux/controller/ann-methods/responsebody.adoc[]
-***** xref:web/webflux/controller/ann-methods/responseentity.adoc[]
-***** xref:web/webflux/controller/ann-methods/jackson.adoc[]
-**** xref:web/webflux/controller/ann-modelattrib-methods.adoc[]
-**** xref:web/webflux/controller/ann-initbinder.adoc[]
-**** xref:web/webflux/controller/ann-validation.adoc[]
-**** xref:web/webflux/controller/ann-exceptions.adoc[]
-**** xref:web/webflux/controller/ann-advice.adoc[]
-*** xref:web/webflux-functional.adoc[]
-*** xref:web/webflux/uri-building.adoc[]
-*** xref:web/webflux-cors.adoc[]
-*** xref:web/webflux/ann-rest-exceptions.adoc[]
-*** xref:web/webflux/security.adoc[]
-*** xref:web/webflux/caching.adoc[]
-*** xref:web/webflux-view.adoc[]
-*** xref:web/webflux/config.adoc[]
-*** xref:web/webflux/http2.adoc[]
-** xref:web/webflux-webclient.adoc[]
-*** xref:web/webflux-webclient/client-builder.adoc[]
-*** xref:web/webflux-webclient/client-retrieve.adoc[]
-*** xref:web/webflux-webclient/client-exchange.adoc[]
-*** xref:web/webflux-webclient/client-body.adoc[]
-*** xref:web/webflux-webclient/client-filter.adoc[]
-*** xref:web/webflux-webclient/client-attributes.adoc[]
-*** xref:web/webflux-webclient/client-context.adoc[]
-*** xref:web/webflux-webclient/client-synchronous.adoc[]
-*** xref:web/webflux-webclient/client-testing.adoc[]
-** xref:web/webflux-http-interface-client.adoc[]
-** xref:web/webflux-websocket.adoc[]
-** xref:web/webflux-test.adoc[]
-** xref:rsocket.adoc[]
-** xref:web/webflux-reactive-libraries.adoc[]
-* xref:integration.adoc[]
-** xref:integration/rest-clients.adoc[]
-** xref:integration/jms.adoc[]
-*** xref:integration/jms/using.adoc[]
-*** xref:integration/jms/sending.adoc[]
-*** xref:integration/jms/receiving.adoc[]
-*** xref:integration/jms/jca-message-endpoint-manager.adoc[]
-*** xref:integration/jms/annotated.adoc[]
-*** xref:integration/jms/namespace.adoc[]
-** xref:integration/jmx.adoc[]
-*** xref:integration/jmx/exporting.adoc[]
-*** xref:integration/jmx/interface.adoc[]
-*** xref:integration/jmx/naming.adoc[]
-*** xref:integration/jmx/jsr160.adoc[]
-*** xref:integration/jmx/proxy.adoc[]
-*** xref:integration/jmx/notifications.adoc[]
-*** xref:integration/jmx/resources.adoc[]
-** xref:integration/email.adoc[]
-** xref:integration/scheduling.adoc[]
-** xref:integration/cache.adoc[]
-*** xref:integration/cache/strategies.adoc[]
-*** xref:integration/cache/annotations.adoc[]
-*** xref:integration/cache/jsr-107.adoc[]
-*** xref:integration/cache/declarative-xml.adoc[]
-*** xref:integration/cache/store-configuration.adoc[]
-*** xref:integration/cache/plug.adoc[]
-*** xref:integration/cache/specific-config.adoc[]
-** xref:integration/observability.adoc[]
-** xref:integration/checkpoint-restore.adoc[]
-** xref:integration/cds.adoc[]
-** xref:integration/appendix.adoc[]
-* xref:languages.adoc[]
-** xref:languages/kotlin.adoc[]
-*** xref:languages/kotlin/requirements.adoc[]
-*** xref:languages/kotlin/extensions.adoc[]
-*** xref:languages/kotlin/null-safety.adoc[]
-*** xref:languages/kotlin/classes-interfaces.adoc[]
-*** xref:languages/kotlin/annotations.adoc[]
-*** xref:languages/kotlin/bean-definition-dsl.adoc[]
-*** xref:languages/kotlin/web.adoc[]
-*** xref:languages/kotlin/coroutines.adoc[]
-*** xref:languages/kotlin/spring-projects-in.adoc[]
-*** xref:languages/kotlin/getting-started.adoc[]
-*** xref:languages/kotlin/resources.adoc[]
-** xref:languages/groovy.adoc[]
-** xref:languages/dynamic.adoc[]
-* xref:appendix.adoc[]
-* {spring-framework-wiki}[Wiki]
-
@@ -1,119 +0,0 @@
-[[appendix]]
-= Appendix
-
-This part of the reference documentation covers topics that apply to multiple modules
-within the core Spring Framework.
-
-
-[[appendix-spring-properties]]
-== Spring Properties
-
-{spring-framework-api}/core/SpringProperties.html[`SpringProperties`] is a static holder
-for properties that control certain low-level aspects of the Spring Framework. Users can
-configure these properties via JVM system properties or programmatically via the
-`SpringProperties.setProperty(String key, String value)` method. The latter may be
-necessary if the deployment environment disallows custom JVM system properties. As an
-alternative, these properties may be configured in a `spring.properties` file in the root
-of the classpath -- for example, deployed within the application's JAR file.
-
-The following table lists all currently supported Spring properties.
-
-.Supported Spring Properties
-[cols="1,1"]
-|===
-| Name | Description
-
-| `spring.aot.enabled`
-| Indicates the application should run with AOT generated artifacts. See
-xref:core/aot.adoc[Ahead of Time Optimizations] and 
-{spring-framework-api}++/aot/AotDetector.html#AOT_ENABLED++[`AotDetector`]
-for details.
-
-| `spring.beaninfo.ignore`
-| Instructs Spring to use the `Introspector.IGNORE_ALL_BEANINFO` mode when calling the
-JavaBeans `Introspector`. See
-{spring-framework-api}++/beans/StandardBeanInfoFactory.html#IGNORE_BEANINFO_PROPERTY_NAME++[`CachedIntrospectionResults`]
-for details.
-
-| `spring.cache.reactivestreams.ignore`
-| Instructs Spring's caching infrastructure to ignore the presence of Reactive Streams,
-in particular Reactor's `Mono`/`Flux` in `@Cacheable` method return type declarations. See
-{spring-framework-api}++/cache/interceptor/CacheAspectSupport.html#IGNORE_REACTIVESTREAMS_PROPERTY_NAME++[`CacheAspectSupport`]
-for details.
-
-| `spring.classformat.ignore`
-| Instructs Spring to ignore class format exceptions during classpath scanning, in
-particular for unsupported class file versions. See
-{spring-framework-api}++/context/annotation/ClassPathScanningCandidateComponentProvider.html#IGNORE_CLASSFORMAT_PROPERTY_NAME++[`ClassPathScanningCandidateComponentProvider`]
-for details.
-
-| `spring.context.checkpoint`
-| Property that specifies a common context checkpoint. See
-xref:integration/checkpoint-restore.adoc#_automatic_checkpointrestore_at_startup[Automatic
-checkpoint/restore at startup] and
-{spring-framework-api}++/context/support/DefaultLifecycleProcessor.html#CHECKPOINT_PROPERTY_NAME++[`DefaultLifecycleProcessor`]
-for details.
-
-| `spring.context.exit`
-| Property for terminating the JVM when the context reaches a specific phase. See
-xref:integration/checkpoint-restore.adoc#_automatic_checkpointrestore_at_startup[Automatic
-checkpoint/restore at startup] and
-{spring-framework-api}++/context/support/DefaultLifecycleProcessor.html#EXIT_PROPERTY_NAME++[`DefaultLifecycleProcessor`]
-for details.
-
-| `spring.context.expression.maxLength`
-| The maximum length for
-xref:core/expressions/evaluation.adoc#expressions-parser-configuration[Spring Expression Language]
-expressions used in XML bean definitions, `@Value`, etc.
-
-| `spring.expression.compiler.mode`
-| The mode to use when compiling expressions for the
-xref:core/expressions/evaluation.adoc#expressions-compiler-configuration[Spring Expression Language].
-
-| `spring.getenv.ignore`
-| Instructs Spring to ignore operating system environment variables if a Spring
-`Environment` property -- for example, a placeholder in a configuration String -- isn't
-resolvable otherwise. See
-{spring-framework-api}++/core/env/AbstractEnvironment.html#IGNORE_GETENV_PROPERTY_NAME++[`AbstractEnvironment`]
-for details.
-
-| `spring.jdbc.getParameterType.ignore`
-| Instructs Spring to ignore `java.sql.ParameterMetaData.getParameterType` completely.
-See the note in xref:data-access/jdbc/advanced.adoc#jdbc-batch-list[Batch Operations with a List of Objects].
-
-| `spring.jndi.ignore`
-| Instructs Spring to ignore a default JNDI environment, as an optimization for scenarios
-where nothing is ever to be found for such JNDI fallback searches to begin with, avoiding
-the repeated JNDI lookup overhead. See
-{spring-framework-api}++/jndi/JndiLocatorDelegate.html#IGNORE_JNDI_PROPERTY_NAME++[`JndiLocatorDelegate`]
-for details.
-
-| `spring.objenesis.ignore`
-| Instructs Spring to ignore Objenesis, not even attempting to use it. See
-{spring-framework-api}++/objenesis/SpringObjenesis.html#IGNORE_OBJENESIS_PROPERTY_NAME++[`SpringObjenesis`]
-for details.
-
-| `spring.test.aot.processing.failOnError`
-| A boolean flag that controls whether errors encountered during AOT processing in the
-_Spring TestContext Framework_ should result in an exception that fails the overall process.
-See xref:testing/testcontext-framework/aot.adoc[Ahead of Time Support for Tests].
-
-| `spring.test.constructor.autowire.mode`
-| The default _test constructor autowire mode_ to use if `@TestConstructor` is not present
-on a test class. See xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-testconstructor[Changing the default test constructor autowire mode].
-
-| `spring.test.context.cache.maxSize`
-| The maximum size of the context cache in the _Spring TestContext Framework_. See
-xref:testing/testcontext-framework/ctx-management/caching.adoc[Context Caching].
-
-| `spring.test.context.failure.threshold`
-| The failure threshold for errors encountered while attempting to load an `ApplicationContext`
-in the _Spring TestContext Framework_. See
-xref:testing/testcontext-framework/ctx-management/failure-threshold.adoc[Context Failure Threshold].
-
-| `spring.test.enclosing.configuration`
-| The default _enclosing configuration inheritance mode_ to use if
-`@NestedTestConfiguration` is not present on a test class. See
-xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-nestedtestconfiguration[Changing the default enclosing configuration inheritance mode].
-
-|===
@@ -1,12 +0,0 @@
-[[aop-api]]
-= Spring AOP APIs
-:page-section-summary-toc: 1
-
-The previous chapter described the Spring's support for AOP with @AspectJ and schema-based
-aspect definitions. In this chapter, we discuss the lower-level Spring AOP APIs. For common
-applications, we recommend the use of Spring AOP with AspectJ pointcuts as described in the
-previous chapter.
-
-
-
-
@@ -1,592 +0,0 @@
-[[aop-api-advice]]
-= Advice API in Spring
-
-Now we can examine how Spring AOP handles advice.
-
-
-
-[[aop-api-advice-lifecycle]]
-== Advice Lifecycles
-
-Each advice is a Spring bean. An advice instance can be shared across all advised
-objects or be unique to each advised object. This corresponds to per-class or
-per-instance advice.
-
-Per-class advice is used most often. It is appropriate for generic advice, such as
-transaction advisors. These do not depend on the state of the proxied object or add new
-state. They merely act on the method and arguments.
-
-Per-instance advice is appropriate for introductions, to support mixins. In this case,
-the advice adds state to the proxied object.
-
-You can use a mix of shared and per-instance advice in the same AOP proxy.
-
-
-
-[[aop-api-advice-types]]
-== Advice Types in Spring
-
-Spring provides several advice types and is extensible to support
-arbitrary advice types. This section describes the basic concepts and standard advice types.
-
-
-[[aop-api-advice-around]]
-=== Interception Around Advice
-
-The most fundamental advice type in Spring is interception around advice.
-
-Spring is compliant with the AOP `Alliance` interface for around advice that uses method
-interception. Classes that implement `MethodInterceptor` and that implement around advice should also implement the
-following interface:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	public interface MethodInterceptor extends Interceptor {
-
-		Object invoke(MethodInvocation invocation) throws Throwable;
-	}
----
-
-The `MethodInvocation` argument to the `invoke()` method exposes the method being
-invoked, the target join point, the AOP proxy, and the arguments to the method. The
-`invoke()` method should return the invocation's result: the return value of the join
-point.
-
-The following example shows a simple `MethodInterceptor` implementation:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class DebugInterceptor implements MethodInterceptor {
-
-		public Object invoke(MethodInvocation invocation) throws Throwable {
-			System.out.println("Before: invocation=[" + invocation + "]");
-			Object rval = invocation.proceed();
-			System.out.println("Invocation returned");
-			return rval;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class DebugInterceptor : MethodInterceptor {
-
-		override fun invoke(invocation: MethodInvocation): Any {
-			println("Before: invocation=[$invocation]")
-			val rval = invocation.proceed()
-			println("Invocation returned")
-			return rval
-		}
-	}
----
-======
-
-Note the call to the `proceed()` method of `MethodInvocation`. This proceeds down the
-interceptor chain towards the join point. Most interceptors invoke this method and
-return its return value. However, a `MethodInterceptor`, like any around advice, can
-return a different value or throw an exception rather than invoke the proceed method.
-However, you do not want to do this without good reason.
-
-NOTE: `MethodInterceptor` implementations offer interoperability with other AOP Alliance-compliant AOP
-implementations. The other advice types discussed in the remainder of this section
-implement common AOP concepts but in a Spring-specific way. While there is an advantage
-in using the most specific advice type, stick with `MethodInterceptor` around advice if
-you are likely to want to run the aspect in another AOP framework. Note that pointcuts
-are not currently interoperable between frameworks, and the AOP Alliance does not
-currently define pointcut interfaces.
-
-
-[[aop-api-advice-before]]
-=== Before Advice
-
-A simpler advice type is a before advice. This does not need a `MethodInvocation`
-object, since it is called only before entering the method.
-
-The main advantage of a before advice is that there is no need to invoke the `proceed()`
-method and, therefore, no possibility of inadvertently failing to proceed down the
-interceptor chain.
-
-The following listing shows the `MethodBeforeAdvice` interface:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	public interface MethodBeforeAdvice extends BeforeAdvice {
-
-		void before(Method m, Object[] args, Object target) throws Throwable;
-	}
----
-
-(Spring's API design would allow for
-field before advice, although the usual objects apply to field interception and it is
-unlikely for Spring to ever implement it.)
-
-Note that the return type is `void`. Before advice can insert custom behavior before the join
-point runs but cannot change the return value. If a before advice throws an
-exception, it stops further execution of the interceptor chain. The exception
-propagates back up the interceptor chain. If it is unchecked or on the signature of
-the invoked method, it is passed directly to the client. Otherwise, it is
-wrapped in an unchecked exception by the AOP proxy.
-
-The following example shows a before advice in Spring, which counts all method invocations:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class CountingBeforeAdvice implements MethodBeforeAdvice {
-
-		private int count;
-
-		public void before(Method m, Object[] args, Object target) throws Throwable {
-			++count;
-		}
-
-		public int getCount() {
-			return count;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class CountingBeforeAdvice : MethodBeforeAdvice {
-
-		var count: Int = 0
-
-		override fun before(m: Method, args: Array<Any>, target: Any?) {
-			++count
-		}
-	}
----
-======
-
-TIP: Before advice can be used with any pointcut.
-
-
-[[aop-api-advice-throws]]
-=== Throws Advice
-
-Throws advice is invoked after the return of the join point if the join point threw
-an exception. Spring offers typed throws advice. Note that this means that the
-`org.springframework.aop.ThrowsAdvice` interface does not contain any methods. It is a
-tag interface identifying that the given object implements one or more typed throws
-advice methods. These should be in the following form:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	afterThrowing([Method, args, target], subclassOfThrowable)
----
-
-Only the last argument is required. The method signatures may have either one or four
-arguments, depending on whether the advice method is interested in the method and
-arguments. The next two listing show classes that are examples of throws advice.
-
-The following advice is invoked if a `RemoteException` is thrown (including from subclasses):
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class RemoteThrowsAdvice implements ThrowsAdvice {
-
-		public void afterThrowing(RemoteException ex) throws Throwable {
-			// Do something with remote exception
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class RemoteThrowsAdvice : ThrowsAdvice {
-
-		fun afterThrowing(ex: RemoteException) {
-			// Do something with remote exception
-		}
-	}
----
-======
-
-Unlike the preceding
-advice, the next example declares four arguments, so that it has access to the invoked method, method
-arguments, and target object. The following advice is invoked if a `ServletException` is thrown:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class ServletThrowsAdviceWithArguments implements ThrowsAdvice {
-
-		public void afterThrowing(Method m, Object[] args, Object target, ServletException ex) {
-			// Do something with all arguments
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class ServletThrowsAdviceWithArguments : ThrowsAdvice {
-
-		fun afterThrowing(m: Method, args: Array<Any>, target: Any, ex: ServletException) {
-			// Do something with all arguments
-		}
-	}
----
-======
-
-The final example illustrates how these two methods could be used in a single class
-that handles both `RemoteException` and `ServletException`. Any number of throws advice
-methods can be combined in a single class. The following listing shows the final example:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public static class CombinedThrowsAdvice implements ThrowsAdvice {
-
-		public void afterThrowing(RemoteException ex) throws Throwable {
-			// Do something with remote exception
-		}
-
-		public void afterThrowing(Method m, Object[] args, Object target, ServletException ex) {
-			// Do something with all arguments
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class CombinedThrowsAdvice : ThrowsAdvice {
-
-		fun afterThrowing(ex: RemoteException) {
-			// Do something with remote exception
-		}
-
-		fun afterThrowing(m: Method, args: Array<Any>, target: Any, ex: ServletException) {
-			// Do something with all arguments
-		}
-	}
----
-======
-
-NOTE: If a throws-advice method throws an exception itself, it overrides the
-original exception (that is, it changes the exception thrown to the user). The overriding
-exception is typically a RuntimeException, which is compatible with any method
-signature. However, if a throws-advice method throws a checked exception, it must
-match the declared exceptions of the target method and is, hence, to some degree
-coupled to specific target method signatures. _Do not throw an undeclared checked
-exception that is incompatible with the target method's signature!_
-
-TIP: Throws advice can be used with any pointcut.
-
-
-[[aop-api-advice-after-returning]]
-=== After Returning Advice
-
-An after returning advice in Spring must implement the
-`org.springframework.aop.AfterReturningAdvice` interface, which the following listing shows:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	public interface AfterReturningAdvice extends Advice {
-
-		void afterReturning(Object returnValue, Method m, Object[] args, Object target)
-				throws Throwable;
-	}
----
-
-An after returning advice has access to the return value (which it cannot modify),
-the invoked method, the method's arguments, and the target.
-
-The following after returning advice counts all successful method invocations that have
-not thrown exceptions:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class CountingAfterReturningAdvice implements AfterReturningAdvice {
-
-		private int count;
-
-		public void afterReturning(Object returnValue, Method m, Object[] args, Object target)
-				throws Throwable {
-			++count;
-		}
-
-		public int getCount() {
-			return count;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class CountingAfterReturningAdvice : AfterReturningAdvice {
-
-		var count: Int = 0
-			private set
-
-		override fun afterReturning(returnValue: Any?, m: Method, args: Array<Any>, target: Any?) {
-			++count
-		}
-	}
----
-======
-
-This advice does not change the execution path. If it throws an exception, it is
-thrown up the interceptor chain instead of the return value.
-
-TIP: After returning advice can be used with any pointcut.
-
-
-[[aop-api-advice-introduction]]
-=== Introduction Advice
-
-Spring treats introduction advice as a special kind of interception advice.
-
-Introduction requires an `IntroductionAdvisor` and an `IntroductionInterceptor` that
-implement the following interface:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	public interface IntroductionInterceptor extends MethodInterceptor {
-
-		boolean implementsInterface(Class intf);
-	}
----
-
-The `invoke()` method inherited from the AOP Alliance `MethodInterceptor` interface must
-implement the introduction. That is, if the invoked method is on an introduced
-interface, the introduction interceptor is responsible for handling the method call -- it
-cannot invoke `proceed()`.
-
-Introduction advice cannot be used with any pointcut, as it applies only at the class,
-rather than the method, level. You can only use introduction advice with the
-`IntroductionAdvisor`, which has the following methods:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	public interface IntroductionAdvisor extends Advisor, IntroductionInfo {
-
-		ClassFilter getClassFilter();
-
-		void validateInterfaces() throws IllegalArgumentException;
-	}
-
-	public interface IntroductionInfo {
-
-		Class<?>[] getInterfaces();
-	}
----
-
-There is no `MethodMatcher` and, hence, no `Pointcut` associated with introduction
-advice. Only class filtering is logical.
-
-The `getInterfaces()` method returns the interfaces introduced by this advisor.
-
-The `validateInterfaces()` method is used internally to see whether or not the
-introduced interfaces can be implemented by the configured `IntroductionInterceptor`.
-
-Consider an example from the Spring test suite and suppose we want to
-introduce the following interface to one or more objects:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public interface Lockable {
-		void lock();
-		void unlock();
-		boolean locked();
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	interface Lockable {
-		fun lock()
-		fun unlock()
-		fun locked(): Boolean
-	}
----
-======
-
-This illustrates a mixin. We want to be able to cast advised objects to `Lockable`,
-whatever their type and call lock and unlock methods. If we call the `lock()` method, we
-want all setter methods to throw a `LockedException`. Thus, we can add an aspect that
-provides the ability to make objects immutable without them having any knowledge of it:
-a good example of AOP.
-
-First, we need an `IntroductionInterceptor` that does the heavy lifting. In this
-case, we extend the `org.springframework.aop.support.DelegatingIntroductionInterceptor`
-convenience class. We could implement `IntroductionInterceptor` directly, but using
-`DelegatingIntroductionInterceptor` is best for most cases.
-
-The `DelegatingIntroductionInterceptor` is designed to delegate an introduction to an
-actual implementation of the introduced interfaces, concealing the use of interception
-to do so. You can set the delegate to any object using a constructor argument. The
-default delegate (when the no-argument constructor is used) is `this`. Thus, in the next example,
-the delegate is the `LockMixin` subclass of `DelegatingIntroductionInterceptor`.
-Given a delegate (by default, itself), a `DelegatingIntroductionInterceptor` instance
-looks for all interfaces implemented by the delegate (other than
-`IntroductionInterceptor`) and supports introductions against any of them.
-Subclasses such as `LockMixin` can call the `suppressInterface(Class intf)`
-method to suppress interfaces that should not be exposed. However, no matter how many
-interfaces an `IntroductionInterceptor` is prepared to support, the
-`IntroductionAdvisor` used controls which interfaces are actually exposed. An
-introduced interface conceals any implementation of the same interface by the target.
-
-Thus, `LockMixin` extends `DelegatingIntroductionInterceptor` and implements `Lockable`
-itself. The superclass automatically picks up that `Lockable` can be supported for
-introduction, so we do not need to specify that. We could introduce any number of
-interfaces in this way.
-
-Note the use of the `locked` instance variable. This effectively adds additional state
-to that held in the target object.
-
-The following example shows the example `LockMixin` class:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class LockMixin extends DelegatingIntroductionInterceptor implements Lockable {
-
-		private boolean locked;
-
-		public void lock() {
-			this.locked = true;
-		}
-
-		public void unlock() {
-			this.locked = false;
-		}
-
-		public boolean locked() {
-			return this.locked;
-		}
-
-		public Object invoke(MethodInvocation invocation) throws Throwable {
-			if (locked() && invocation.getMethod().getName().indexOf("set") == 0) {
-				throw new LockedException();
-			}
-			return super.invoke(invocation);
-		}
-
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class LockMixin : DelegatingIntroductionInterceptor(), Lockable {
-
-		private var locked: Boolean = false
-
-		fun lock() {
-			this.locked = true
-		}
-
-		fun unlock() {
-			this.locked = false
-		}
-
-		fun locked(): Boolean {
-			return this.locked
-		}
-
-		override fun invoke(invocation: MethodInvocation): Any? {
-			if (locked() && invocation.method.name.indexOf("set") == 0) {
-				throw LockedException()
-			}
-			return super.invoke(invocation)
-		}
-
-	}
----
-======
-
-Often, you need not override the `invoke()` method. The
-`DelegatingIntroductionInterceptor` implementation (which calls the `delegate` method if
-the method is introduced, otherwise proceeds towards the join point) usually
-suffices. In the present case, we need to add a check: no setter method can be invoked
-if in locked mode.
-
-The required introduction only needs to hold a distinct
-`LockMixin` instance and specify the introduced interfaces (in this case, only
-`Lockable`). A more complex example might take a reference to the introduction
-interceptor (which would be defined as a prototype). In this case, there is no
-configuration relevant for a `LockMixin`, so we create it by using `new`.
-The following example shows our `LockMixinAdvisor` class:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class LockMixinAdvisor extends DefaultIntroductionAdvisor {
-
-		public LockMixinAdvisor() {
-			super(new LockMixin(), Lockable.class);
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class LockMixinAdvisor : DefaultIntroductionAdvisor(LockMixin(), Lockable::class.java)
----
-======
-
-We can apply this advisor very simply, because it requires no configuration. (However, it
-is impossible to use an `IntroductionInterceptor` without an
-`IntroductionAdvisor`.) As usual with introductions, the advisor must be per-instance,
-as it is stateful. We need a different instance of `LockMixinAdvisor`, and hence
-`LockMixin`, for each advised object. The advisor comprises part of the advised object's
-state.
-
-We can apply this advisor programmatically by using the `Advised.addAdvisor()` method or
-(the recommended way) in XML configuration, as any other advisor. All proxy creation
-choices discussed below, including "`auto proxy creators,`" correctly handle introductions
-and stateful mixins.
-
-
-
-
-
@@ -1,148 +0,0 @@
-[[aop-api-advised]]
-= Manipulating Advised Objects
-
-However you create AOP proxies, you can manipulate them BY using the
-`org.springframework.aop.framework.Advised` interface. Any AOP proxy can be cast to this
-interface, no matter which other interfaces it implements. This interface includes the
-following methods:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	Advisor[] getAdvisors();
-
-	void addAdvice(Advice advice) throws AopConfigException;
-
-	void addAdvice(int pos, Advice advice) throws AopConfigException;
-
-	void addAdvisor(Advisor advisor) throws AopConfigException;
-
-	void addAdvisor(int pos, Advisor advisor) throws AopConfigException;
-
-	int indexOf(Advisor advisor);
-
-	boolean removeAdvisor(Advisor advisor) throws AopConfigException;
-
-	void removeAdvisor(int index) throws AopConfigException;
-
-	boolean replaceAdvisor(Advisor a, Advisor b) throws AopConfigException;
-
-	boolean isFrozen();
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	fun getAdvisors(): Array<Advisor>
-
-	@Throws(AopConfigException::class)
-	fun addAdvice(advice: Advice)
-
-	@Throws(AopConfigException::class)
-	fun addAdvice(pos: Int, advice: Advice)
-
-	@Throws(AopConfigException::class)
-	fun addAdvisor(advisor: Advisor)
-
-	@Throws(AopConfigException::class)
-	fun addAdvisor(pos: Int, advisor: Advisor)
-
-	fun indexOf(advisor: Advisor): Int
-
-	@Throws(AopConfigException::class)
-	fun removeAdvisor(advisor: Advisor): Boolean
-
-	@Throws(AopConfigException::class)
-	fun removeAdvisor(index: Int)
-
-	@Throws(AopConfigException::class)
-	fun replaceAdvisor(a: Advisor, b: Advisor): Boolean
-
-	fun isFrozen(): Boolean
----
-======
-
-The `getAdvisors()` method returns an `Advisor` for every advisor, interceptor, or
-other advice type that has been added to the factory. If you added an `Advisor`, the
-returned advisor at this index is the object that you added. If you added an
-interceptor or other advice type, Spring wrapped this in an advisor with a
-pointcut that always returns `true`. Thus, if you added a `MethodInterceptor`, the advisor
-returned for this index is a `DefaultPointcutAdvisor` that returns your
-`MethodInterceptor` and a pointcut that matches all classes and methods.
-
-The `addAdvisor()` methods can be used to add any `Advisor`. Usually, the advisor holding
-pointcut and advice is the generic `DefaultPointcutAdvisor`, which you can use with
-any advice or pointcut (but not for introductions).
-
-By default, it is possible to add or remove advisors or interceptors even once a proxy
-has been created. The only restriction is that it is impossible to add or remove an
-introduction advisor, as existing proxies from the factory do not show the interface
-change. (You can obtain a new proxy from the factory to avoid this problem.)
-
-The following example shows casting an AOP proxy to the `Advised` interface and examining and
-manipulating its advice:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	Advised advised = (Advised) myObject;
-	Advisor[] advisors = advised.getAdvisors();
-	int oldAdvisorCount = advisors.length;
-	System.out.println(oldAdvisorCount + " advisors");
-
-	// Add an advice like an interceptor without a pointcut
-	// Will match all proxied methods
-	// Can use for interceptors, before, after returning or throws advice
-	advised.addAdvice(new DebugInterceptor());
-
-	// Add selective advice using a pointcut
-	advised.addAdvisor(new DefaultPointcutAdvisor(mySpecialPointcut, myAdvice));
-
-	assertEquals("Added two advisors", oldAdvisorCount + 2, advised.getAdvisors().length);
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	val advised = myObject as Advised
-	val advisors = advised.advisors
-	val oldAdvisorCount = advisors.size
-	println("$oldAdvisorCount advisors")
-
-	// Add an advice like an interceptor without a pointcut
-	// Will match all proxied methods
-	// Can use for interceptors, before, after returning or throws advice
-	advised.addAdvice(DebugInterceptor())
-
-	// Add selective advice using a pointcut
-	advised.addAdvisor(DefaultPointcutAdvisor(mySpecialPointcut, myAdvice))
-
-	assertEquals("Added two advisors", oldAdvisorCount + 2, advised.advisors.size)
----
-======
-
-NOTE: It is questionable whether it is advisable (no pun intended) to modify advice on a
-business object in production, although there are, no doubt, legitimate usage cases.
-However, it can be very useful in development (for example, in tests). We have sometimes
-found it very useful to be able to add test code in the form of an interceptor or other
-advice, getting inside a method invocation that we want to test. (For example, the advice can
-get inside a transaction created for that method, perhaps to run SQL to check that
-a database was correctly updated, before marking the transaction for roll back.)
-
-Depending on how you created the proxy, you can usually set a `frozen` flag. In that
-case, the `Advised` `isFrozen()` method returns `true`, and any attempts to modify
-advice through addition or removal results in an `AopConfigException`. The ability
-to freeze the state of an advised object is useful in some cases (for example, to
-prevent calling code removing a security interceptor).
-
-
-
-
@@ -1,20 +0,0 @@
-[[aop-api-advisor]]
-= The Advisor API in Spring
-:page-section-summary-toc: 1
-
-In Spring, an Advisor is an aspect that contains only a single advice object associated
-with a pointcut expression.
-
-Apart from the special case of introductions, any advisor can be used with any advice.
-`org.springframework.aop.support.DefaultPointcutAdvisor` is the most commonly used
-advisor class. It can be used with a `MethodInterceptor`, `BeforeAdvice`, or
-`ThrowsAdvice`.
-
-It is possible to mix advisor and advice types in Spring in the same AOP proxy. For
-example, you could use an interception around advice, throws advice, and before advice in
-one proxy configuration. Spring automatically creates the necessary interceptor
-chain.
-
-
-
-
@@ -1,131 +0,0 @@
-[[aop-autoproxy]]
-= Using the "auto-proxy" facility
-
-So far, we have considered explicit creation of AOP proxies by using a `ProxyFactoryBean` or
-similar factory bean.
-
-Spring also lets us use "`auto-proxy`" bean definitions, which can automatically
-proxy selected bean definitions. This is built on Spring's "`bean post processor`"
-infrastructure, which enables modification of any bean definition as the container loads.
-
-In this model, you set up some special bean definitions in your XML bean definition file
-to configure the auto-proxy infrastructure. This lets you declare the targets
-eligible for auto-proxying. You need not use `ProxyFactoryBean`.
-
-There are two ways to do this:
-
-* By using an auto-proxy creator that refers to specific beans in the current context.
-* A special case of auto-proxy creation that deserves to be considered separately:
-  auto-proxy creation driven by source-level metadata attributes.
-
-
-
-[[aop-autoproxy-choices]]
-== Auto-proxy Bean Definitions
-
-This section covers the  auto-proxy creators provided by the
-`org.springframework.aop.framework.autoproxy` package.
-
-
-[[aop-api-autoproxy]]
-=== `BeanNameAutoProxyCreator`
-
-The `BeanNameAutoProxyCreator` class is a `BeanPostProcessor` that automatically creates
-AOP proxies for beans with names that match literal values or wildcards. The following
-example shows how to create a `BeanNameAutoProxyCreator` bean:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
-		<property name="beanNames" value="jdk*,onlyJdk"/>
-		<property name="interceptorNames">
-			<list>
-				<value>myInterceptor</value>
-			</list>
-		</property>
-	</bean>
----
-
-As with `ProxyFactoryBean`, there is an `interceptorNames` property rather than a list
-of interceptors, to allow correct behavior for prototype advisors. Named "`interceptors`"
-can be advisors or any advice type.
-
-As with auto-proxying in general, the main point of using `BeanNameAutoProxyCreator` is
-to apply the same configuration consistently to multiple objects, with minimal volume of
-configuration. It is a popular choice for applying declarative transactions to multiple
-objects.
-
-Bean definitions whose names match, such as `jdkMyBean` and `onlyJdk` in the preceding
-example, are plain old bean definitions with the target class. An AOP proxy is
-automatically created by the `BeanNameAutoProxyCreator`. The same advice is applied
-to all matching beans. Note that, if advisors are used (rather than the interceptor in
-the preceding example), the pointcuts may apply differently to different beans.
-
-
-[[aop-api-autoproxy-default]]
-=== `DefaultAdvisorAutoProxyCreator`
-
-A more general and extremely powerful auto-proxy creator is
-`DefaultAdvisorAutoProxyCreator`. This automagically applies eligible advisors in the
-current context, without the need to include specific bean names in the auto-proxy
-advisor's bean definition. It offers the same merit of consistent configuration and
-avoidance of duplication as `BeanNameAutoProxyCreator`.
-
-Using this mechanism involves:
-
-* Specifying a `DefaultAdvisorAutoProxyCreator` bean definition.
-* Specifying any number of advisors in the same or related contexts. Note that these
-  must be advisors, not interceptors or other advice. This is necessary,
-  because there must be a pointcut to evaluate, to check the eligibility of each advice
-  to candidate bean definitions.
-
-The `DefaultAdvisorAutoProxyCreator` automatically evaluates the pointcut contained
-in each advisor, to see what (if any) advice it should apply to each business object
-(such as `businessObject1` and `businessObject2` in the example).
-
-This means that any number of advisors can be applied automatically to each business
-object. If no pointcut in any of the advisors matches any method in a business object,
-the object is not proxied. As bean definitions are added for new business objects,
-they are automatically proxied if necessary.
-
-Auto-proxying in general has the advantage of making it impossible for callers or
-dependencies to obtain an un-advised object. Calling `getBean("businessObject1")` on this
-`ApplicationContext` returns an AOP proxy, not the target business object. (The "`inner
-bean`" idiom shown earlier also offers this benefit.)
-
-The following example creates a `DefaultAdvisorAutoProxyCreator` bean and the other
-elements discussed in this section:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator"/>
-
-	<bean class="org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor">
-		<property name="transactionInterceptor" ref="transactionInterceptor"/>
-	</bean>
-
-	<bean id="customAdvisor" class="com.mycompany.MyAdvisor"/>
-
-	<bean id="businessObject1" class="com.mycompany.BusinessObject1">
-		<!-- Properties omitted -->
-	</bean>
-
-	<bean id="businessObject2" class="com.mycompany.BusinessObject2"/>
----
-
-The `DefaultAdvisorAutoProxyCreator` is very useful if you want to apply the same advice
-consistently to many business objects. Once the infrastructure definitions are in place,
-you can add new business objects without including specific proxy configuration.
-You can also easily drop in additional aspects (for example, tracing or
-performance monitoring aspects) with minimal change to configuration.
-
-The `DefaultAdvisorAutoProxyCreator` offers support for filtering (by using a naming
-convention so that only certain advisors are evaluated, which allows the use of multiple,
-differently configured, AdvisorAutoProxyCreators in the same factory) and ordering.
-Advisors can implement the `org.springframework.core.Ordered` interface to ensure
-correct ordering if this is an issue. The `TransactionAttributeSourceAdvisor` used in the
-preceding example has a configurable order value. The default setting is unordered.
-
-
-
-
@@ -1,71 +0,0 @@
-[[aop-concise-proxy]]
-= Concise Proxy Definitions
-
-Especially when defining transactional proxies, you may end up with many similar proxy
-definitions. The use of parent and child bean definitions, along with inner bean
-definitions, can result in much cleaner and more concise proxy definitions.
-
-First, we create a parent, template, bean definition for the proxy, as follows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="txProxyTemplate" abstract="true"
-			class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
-		<property name="transactionManager" ref="transactionManager"/>
-		<property name="transactionAttributes">
-			<props>
-				<prop key="*">PROPAGATION_REQUIRED</prop>
-			</props>
-		</property>
-	</bean>
----
-
-This is never instantiated itself, so it can actually be incomplete. Then, each proxy
-that needs to be created is a child bean definition, which wraps the target of the
-proxy as an inner bean definition, since the target is never used on its own anyway.
-The following example shows such a child bean:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="myService" parent="txProxyTemplate">
-		<property name="target">
-			<bean class="org.springframework.samples.MyServiceImpl">
-			</bean>
-		</property>
-	</bean>
----
-
-You can override properties from the parent template. In the following example,
-we override the transaction propagation settings:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="mySpecialService" parent="txProxyTemplate">
-		<property name="target">
-			<bean class="org.springframework.samples.MySpecialServiceImpl">
-			</bean>
-		</property>
-		<property name="transactionAttributes">
-			<props>
-				<prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>
-				<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>
-				<prop key="load*">PROPAGATION_REQUIRED,readOnly</prop>
-				<prop key="store*">PROPAGATION_REQUIRED</prop>
-			</props>
-		</property>
-	</bean>
----
-
-Note that in the parent bean example, we explicitly marked the parent bean definition as
-being abstract by setting the `abstract` attribute to `true`, as described
-xref:core/beans/child-bean-definitions.adoc[previously], so that it may not actually ever be
-instantiated. Application contexts (but not simple bean factories), by default,
-pre-instantiate all singletons. Therefore, it is important (at least for singleton beans)
-that, if you have a (parent) bean definition that you intend to use only as a template,
-and this definition specifies a class, you must make sure to set the `abstract`
-attribute to `true`. Otherwise, the application context actually tries to
-pre-instantiate it.
-
-
-
-
@@ -1,16 +0,0 @@
-[[aop-extensibility]]
-= Defining New Advice Types
-:page-section-summary-toc: 1
-
-Spring AOP is designed to be extensible. While the interception implementation strategy
-is presently used internally, it is possible to support arbitrary advice types in
-addition to the interception around advice, before, throws advice, and
-after returning advice.
-
-The `org.springframework.aop.framework.adapter` package is an SPI package that lets
-support for new custom advice types be added without changing the core framework.
-The only constraint on a custom `Advice` type is that it must implement the
-`org.aopalliance.aop.Advice` marker interface.
-
-See the {spring-framework-api}/aop/framework/adapter/package-summary.html[`org.springframework.aop.framework.adapter`]
-javadoc for further information.
@@ -1,331 +0,0 @@
-[[aop-pfb]]
-= Using the `ProxyFactoryBean` to Create AOP Proxies
-
-If you use the Spring IoC container (an `ApplicationContext` or `BeanFactory`) for your
-business objects (and you should be!), you want to use one of Spring's AOP
-`FactoryBean` implementations. (Remember that a factory bean introduces a layer of indirection, letting
-it create objects of a different type.)
-
-NOTE: The Spring AOP support also uses factory beans under the covers.
-
-The basic way to create an AOP proxy in Spring is to use the
-`org.springframework.aop.framework.ProxyFactoryBean`. This gives complete control over
-the pointcuts, any advice that applies, and their ordering. However, there are simpler
-options that are preferable if you do not need such control.
-
-
-
-[[aop-pfb-1]]
-== Basics
-
-The `ProxyFactoryBean`, like other Spring `FactoryBean` implementations, introduces a
-level of indirection. If you define a `ProxyFactoryBean` named `foo`, objects that
-reference `foo` do not see the `ProxyFactoryBean` instance itself but an object
-created by the implementation of the `getObject()` method in the `ProxyFactoryBean` . This
-method creates an AOP proxy that wraps a target object.
-
-One of the most important benefits of using a `ProxyFactoryBean` or another IoC-aware
-class to create AOP proxies is that advice and pointcuts can also be
-managed by IoC. This is a powerful feature, enabling certain approaches that are hard to
-achieve with other AOP frameworks. For example, an advice may itself reference
-application objects (besides the target, which should be available in any AOP
-framework), benefiting from all the pluggability provided by Dependency Injection.
-
-
-
-[[aop-pfb-2]]
-== JavaBean Properties
-
-In common with most `FactoryBean` implementations provided with Spring, the
-`ProxyFactoryBean` class is itself a JavaBean. Its properties are used to:
-
-* Specify the target you want to proxy.
-* Specify whether to use CGLIB (described later and see also xref:core/aop-api/pfb.adoc#aop-pfb-proxy-types[JDK- and CGLIB-based proxies]).
-
-Some key properties are inherited from `org.springframework.aop.framework.ProxyConfig`
-(the superclass for all AOP proxy factories in Spring). These key properties include
-the following:
-
-* `proxyTargetClass`: `true` if the target class is to be proxied, rather than the
-  target class's interfaces. If this property value is set to `true`, then CGLIB proxies
-  are created (but see also xref:core/aop-api/pfb.adoc#aop-pfb-proxy-types[JDK- and CGLIB-based proxies]).
-* `optimize`: Controls whether or not aggressive optimizations are applied to proxies
-  created through CGLIB. You should not blithely use this setting unless you fully
-  understand how the relevant AOP proxy handles optimization. This is currently used
-  only for CGLIB proxies. It has no effect with JDK dynamic proxies.
-* `frozen`: If a proxy configuration is `frozen`, changes to the configuration are
-  no longer allowed. This is useful both as a slight optimization and for those cases
-  when you do not want callers to be able to manipulate the proxy (through the `Advised`
-  interface) after the proxy has been created. The default value of this property is
-  `false`, so changes (such as adding additional advice) are allowed.
-* `exposeProxy`: Determines whether or not the current proxy should be exposed in a
-  `ThreadLocal` so that it can be accessed by the target. If a target needs to obtain
-  the proxy and the `exposeProxy` property is set to `true`, the target can use the
-  `AopContext.currentProxy()` method.
-
-Other properties specific to `ProxyFactoryBean` include the following:
-
-* `proxyInterfaces`: An array of `String` interface names. If this is not supplied, a CGLIB
-  proxy for the target class is used (but see also xref:core/aop-api/pfb.adoc#aop-pfb-proxy-types[JDK- and CGLIB-based proxies]).
-* `interceptorNames`: A `String` array of `Advisor`, interceptor, or other advice names to
-  apply. Ordering is significant, on a first come-first served basis. That is to say
-  that the first interceptor in the list is the first to be able to intercept the
-  invocation.
-+
-The names are bean names in the current factory, including bean names from ancestor
-factories. You cannot mention bean references here, since doing so results in the
-`ProxyFactoryBean` ignoring the singleton setting of the advice.
-+
-You can append an interceptor name with an asterisk (`*`). Doing so results in the
-application of all advisor beans with names that start with the part before the asterisk
-to be applied. You can find an example of using this feature in xref:core/aop-api/pfb.adoc#aop-global-advisors[Using "`Global`" Advisors].
-
-* singleton: Whether or not the factory should return a single object, no matter how
-  often the `getObject()` method is called. Several `FactoryBean` implementations offer
-  such a method. The default value is `true`. If you want to use stateful advice - for
-  example, for stateful mixins - use prototype advice along with a singleton value of
-  `false`.
-
-
-
-[[aop-pfb-proxy-types]]
-== JDK- and CGLIB-based proxies
-
-This section serves as the definitive documentation on how the `ProxyFactoryBean`
-chooses to create either a JDK-based proxy or a CGLIB-based proxy for a particular target
-object (which is to be proxied).
-
-NOTE: The behavior of the `ProxyFactoryBean` with regard to creating JDK- or CGLIB-based
-proxies changed between versions 1.2.x and 2.0 of Spring. The `ProxyFactoryBean` now
-exhibits similar semantics with regard to auto-detecting interfaces as those of the
-`TransactionProxyFactoryBean` class.
-
-If the class of a target object that is to be proxied (hereafter simply referred to as
-the target class) does not implement any interfaces, a CGLIB-based proxy is
-created. This is the easiest scenario, because JDK proxies are interface-based, and no
-interfaces means JDK proxying is not even possible. You can plug in the target bean
-and specify the list of interceptors by setting the `interceptorNames` property. Note that a
-CGLIB-based proxy is created even if the `proxyTargetClass` property of the
-`ProxyFactoryBean` has been set to `false`. (Doing so makes no sense and is best
-removed from the bean definition, because it is, at best, redundant, and, at worst
-confusing.)
-
-If the target class implements one (or more) interfaces, the type of proxy that is
-created depends on the configuration of the `ProxyFactoryBean`.
-
-If the `proxyTargetClass` property of the `ProxyFactoryBean` has been set to `true`,
-a CGLIB-based proxy is created. This makes sense and is in keeping with the
-principle of least surprise. Even if the `proxyInterfaces` property of the
-`ProxyFactoryBean` has been set to one or more fully qualified interface names, the fact
-that the `proxyTargetClass` property is set to `true` causes CGLIB-based
-proxying to be in effect.
-
-If the `proxyInterfaces` property of the `ProxyFactoryBean` has been set to one or more
-fully qualified interface names, a JDK-based proxy is created. The created
-proxy implements all of the interfaces that were specified in the `proxyInterfaces`
-property. If the target class happens to implement a whole lot more interfaces than
-those specified in the `proxyInterfaces` property, that is all well and good, but those
-additional interfaces are not implemented by the returned proxy.
-
-If the `proxyInterfaces` property of the `ProxyFactoryBean` has not been set, but
-the target class does implement one (or more) interfaces, the
-`ProxyFactoryBean` auto-detects the fact that the target class does actually
-implement at least one interface, and a JDK-based proxy is created. The interfaces
-that are actually proxied are all of the interfaces that the target class
-implements. In effect, this is the same as supplying a list of each and every
-interface that the target class implements to the `proxyInterfaces` property. However,
-it is significantly less work and less prone to typographical errors.
-
-
-
-[[aop-api-proxying-intf]]
-== Proxying Interfaces
-
-Consider a simple example of `ProxyFactoryBean` in action. This example involves:
-
-* A target bean that is proxied. This is the `personTarget` bean definition in
-  the example.
-* An `Advisor` and an `Interceptor` used to provide advice.
-* An AOP proxy bean definition to specify the target object (the `personTarget` bean),
-  the interfaces to proxy, and the advice to apply.
-
-The following listing shows the example:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="personTarget" class="com.mycompany.PersonImpl">
-		<property name="name" value="Tony"/>
-		<property name="age" value="51"/>
-	</bean>
-
-	<bean id="myAdvisor" class="com.mycompany.MyAdvisor">
-		<property name="someProperty" value="Custom string property value"/>
-	</bean>
-
-	<bean id="debugInterceptor" class="org.springframework.aop.interceptor.DebugInterceptor">
-	</bean>
-
-	<bean id="person"
-		class="org.springframework.aop.framework.ProxyFactoryBean">
-		<property name="proxyInterfaces" value="com.mycompany.Person"/>
-
-		<property name="target" ref="personTarget"/>
-		<property name="interceptorNames">
-			<list>
-				<value>myAdvisor</value>
-				<value>debugInterceptor</value>
-			</list>
-		</property>
-	</bean>
----
-
-Note that the `interceptorNames` property takes a list of `String`, which holds the bean names of the
-interceptors or advisors in the current factory. You can use advisors, interceptors, before, after
-returning, and throws advice objects. The ordering of advisors is significant.
-
-NOTE: You might be wondering why the list does not hold bean references. The reason for this is
-that, if the singleton property of the `ProxyFactoryBean` is set to `false`, it must be able to
-return independent proxy instances. If any of the advisors is itself a prototype, an
-independent instance would need to be returned, so it is necessary to be able to obtain
-an instance of the prototype from the factory. Holding a reference is not sufficient.
-
-The `person` bean definition shown earlier can be used in place of a `Person` implementation, as
-follows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	Person person = (Person) factory.getBean("person");
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	val person = factory.getBean("person") as Person;
----
-======
-
-Other beans in the same IoC context can express a strongly typed dependency on it, as
-with an ordinary Java object. The following example shows how to do so:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="personUser" class="com.mycompany.PersonUser">
-		<property name="person"><ref bean="person"/></property>
-	</bean>
----
-
-The `PersonUser` class in this example exposes a property of type `Person`. As far as
-it is concerned, the AOP proxy can be used transparently in place of a "`real`" person
-implementation. However, its class would be a dynamic proxy class. It would be possible
-to cast it to the `Advised` interface (discussed later).
-
-You can conceal the distinction between target and proxy by using an anonymous
-inner bean. Only the `ProxyFactoryBean` definition is different. The
-advice is included only for completeness. The following example shows how to use an
-anonymous inner bean:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="myAdvisor" class="com.mycompany.MyAdvisor">
-		<property name="someProperty" value="Custom string property value"/>
-	</bean>
-
-	<bean id="debugInterceptor" class="org.springframework.aop.interceptor.DebugInterceptor"/>
-
-	<bean id="person" class="org.springframework.aop.framework.ProxyFactoryBean">
-		<property name="proxyInterfaces" value="com.mycompany.Person"/>
-		<!-- Use inner bean, not local reference to target -->
-		<property name="target">
-			<bean class="com.mycompany.PersonImpl">
-				<property name="name" value="Tony"/>
-				<property name="age" value="51"/>
-			</bean>
-		</property>
-		<property name="interceptorNames">
-			<list>
-				<value>myAdvisor</value>
-				<value>debugInterceptor</value>
-			</list>
-		</property>
-	</bean>
----
-
-Using an anonymous inner bean has the advantage that there is only one object of type `Person`. This is useful if we want
-to prevent users of the application context from obtaining a reference to the un-advised
-object or need to avoid any ambiguity with Spring IoC autowiring. There is also,
-arguably, an advantage in that the `ProxyFactoryBean` definition is self-contained.
-However, there are times when being able to obtain the un-advised target from the
-factory might actually be an advantage (for example, in certain test scenarios).
-
-
-
-[[aop-api-proxying-class]]
-== Proxying Classes
-
-What if you need to proxy a class, rather than one or more interfaces?
-
-Imagine that in our earlier example, there was no `Person` interface. We needed to advise
-a class called `Person` that did not implement any business interface. In this case, you
-can configure Spring to use CGLIB proxying rather than dynamic proxies. To do so, set the
-`proxyTargetClass` property on the `ProxyFactoryBean` shown earlier to `true`. While it is best to
-program to interfaces rather than classes, the ability to advise classes that do not
-implement interfaces can be useful when working with legacy code. (In general, Spring
-is not prescriptive. While it makes it easy to apply good practices, it avoids forcing a
-particular approach.)
-
-If you want to, you can force the use of CGLIB in any case, even if you do have
-interfaces.
-
-CGLIB proxying works by generating a subclass of the target class at runtime. Spring
-configures this generated subclass to delegate method calls to the original target. The
-subclass is used to implement the Decorator pattern, weaving in the advice.
-
-CGLIB proxying should generally be transparent to users. However, there are some issues
-to consider:
-
-* `final` classes cannot be proxied, because they cannot be extended.
-* `final` methods cannot be advised, because they cannot be overridden.
-* `private` methods cannot be advised, because they cannot be overridden.
-* Methods that are not visible, typically package private methods in a parent class
-from a different package, cannot be advised because they are effectively private.
-
-NOTE: There is no need to add CGLIB to your classpath. CGLIB is repackaged and included
-in the `spring-core` JAR. In other words, CGLIB-based AOP works "out of the box", as do
-JDK dynamic proxies.
-
-There is little performance difference between CGLIB proxies and dynamic proxies.
-Performance should not be a decisive consideration in this case.
-
-
-
-[[aop-global-advisors]]
-== Using "`Global`" Advisors
-
-By appending an asterisk to an interceptor name, all advisors with bean names that match
-the part before the asterisk are added to the advisor chain. This can come in handy
-if you need to add a standard set of "`global`" advisors. The following example defines
-two global advisors:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="proxy" class="org.springframework.aop.framework.ProxyFactoryBean">
-		<property name="target" ref="service"/>
-		<property name="interceptorNames">
-			<list>
-				<value>global*</value>
-			</list>
-		</property>
-	</bean>
-
-	<bean id="global_debug" class="org.springframework.aop.interceptor.DebugInterceptor"/>
-	<bean id="global_performance" class="org.springframework.aop.interceptor.PerformanceMonitorInterceptor"/>
----
-
-
-
-
@@ -1,256 +0,0 @@
-[[aop-api-pointcuts]]
-= Pointcut API in Spring
-
-This section describes how Spring handles the crucial pointcut concept.
-
-
-
-[[aop-api-concepts]]
-== Concepts
-
-Spring's pointcut model enables pointcut reuse independent of advice types. You can
-target different advice with the same pointcut.
-
-The `org.springframework.aop.Pointcut` interface is the central interface, used to
-target advice to particular classes and methods. The complete interface follows:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	public interface Pointcut {
-
-		ClassFilter getClassFilter();
-
-		MethodMatcher getMethodMatcher();
-	}
----
-
-Splitting the `Pointcut` interface into two parts allows reuse of class and method
-matching parts and fine-grained composition operations (such as performing a "`union`"
-with another method matcher).
-
-The `ClassFilter` interface is used to restrict the pointcut to a given set of target
-classes. If the `matches()` method always returns true, all target classes are
-matched. The following listing shows the `ClassFilter` interface definition:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	public interface ClassFilter {
-
-		boolean matches(Class clazz);
-	}
----
-
-The `MethodMatcher` interface is normally more important. The complete interface follows:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	public interface MethodMatcher {
-
-		boolean matches(Method m, Class<?> targetClass);
-
-		boolean isRuntime();
-
-		boolean matches(Method m, Class<?> targetClass, Object... args);
-	}
----
-
-The `matches(Method, Class)` method is used to test whether this pointcut ever
-matches a given method on a target class. This evaluation can be performed when an AOP
-proxy is created to avoid the need for a test on every method invocation. If the
-two-argument `matches` method returns `true` for a given method, and the `isRuntime()`
-method for the MethodMatcher returns `true`, the three-argument matches method is
-invoked on every method invocation. This lets a pointcut look at the arguments passed
-to the method invocation immediately before the target advice starts.
-
-Most `MethodMatcher` implementations are static, meaning that their `isRuntime()` method
-returns `false`. In this case, the three-argument `matches` method is never invoked.
-
-TIP: If possible, try to make pointcuts static, allowing the AOP framework to cache the
-results of pointcut evaluation when an AOP proxy is created.
-
-
-
-[[aop-api-pointcut-ops]]
-== Operations on Pointcuts
-
-Spring supports operations (notably, union and intersection) on pointcuts.
-
-Union means the methods that either pointcut matches.
-Intersection means the methods that both pointcuts match.
-Union is usually more useful.
-You can compose pointcuts by using the static methods in the
-`org.springframework.aop.support.Pointcuts` class or by using the
-`ComposablePointcut` class in the same package. However, using AspectJ pointcut
-expressions is usually a simpler approach.
-
-
-
-[[aop-api-pointcuts-aspectj]]
-== AspectJ Expression Pointcuts
-
-Since 2.0, the most important type of pointcut used by Spring is
-`org.springframework.aop.aspectj.AspectJExpressionPointcut`. This is a pointcut that
-uses an AspectJ-supplied library to parse an AspectJ pointcut expression string.
-
-See the xref:core/aop.adoc[previous chapter] for a discussion of supported AspectJ pointcut primitives.
-
-
-
-[[aop-api-pointcuts-impls]]
-== Convenience Pointcut Implementations
-
-Spring provides several convenient pointcut implementations. You can use some of them
-directly; others are intended to be subclassed in application-specific pointcuts.
-
-
-[[aop-api-pointcuts-static]]
-=== Static Pointcuts
-
-Static pointcuts are based on the method and the target class and cannot take into account
-the method's arguments. Static pointcuts suffice -- and are best -- for most usages.
-Spring can evaluate a static pointcut only once, when a method is first invoked.
-After that, there is no need to evaluate the pointcut again with each method invocation.
-
-The rest of this section describes some of the static pointcut implementations that are
-included with Spring.
-
-[[aop-api-pointcuts-regex]]
-==== Regular Expression Pointcuts
-
-One obvious way to specify static pointcuts is regular expressions. Several AOP
-frameworks besides Spring make this possible.
-`org.springframework.aop.support.JdkRegexpMethodPointcut` is a generic regular
-expression pointcut that uses the regular expression support in the JDK.
-
-With the `JdkRegexpMethodPointcut` class, you can provide a list of pattern strings.
-If any of these is a match, the pointcut evaluates to `true`. (As a consequence,
-the resulting pointcut is effectively the union of the specified patterns.)
-
-The following example shows how to use `JdkRegexpMethodPointcut`:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<bean id="settersAndAbsquatulatePointcut"
-			class="org.springframework.aop.support.JdkRegexpMethodPointcut">
-		<property name="patterns">
-			<list>
-				<value>.*set.*</value>
-				<value>.*absquatulate</value>
-			</list>
-		</property>
-	</bean>
----
-
-Spring provides a convenience class named `RegexpMethodPointcutAdvisor`, which lets us
-also reference an `Advice` (remember that an `Advice` can be an interceptor, before advice,
-throws advice, and others). Behind the scenes, Spring uses a `JdkRegexpMethodPointcut`.
-Using `RegexpMethodPointcutAdvisor` simplifies wiring, as the one bean encapsulates both
-pointcut and advice, as the following example shows:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<bean id="settersAndAbsquatulateAdvisor"
-			class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
-		<property name="advice">
-			<ref bean="beanNameOfAopAllianceInterceptor"/>
-		</property>
-		<property name="patterns">
-			<list>
-				<value>.*set.*</value>
-				<value>.*absquatulate</value>
-			</list>
-		</property>
-	</bean>
----
-
-You can use `RegexpMethodPointcutAdvisor` with any `Advice` type.
-
-[[aop-api-pointcuts-attribute-driven]]
-==== Attribute-driven Pointcuts
-
-An important type of static pointcut is a metadata-driven pointcut. This uses the
-values of metadata attributes (typically, source-level metadata).
-
-
-[[aop-api-pointcuts-dynamic]]
-=== Dynamic pointcuts
-
-Dynamic pointcuts are costlier to evaluate than static pointcuts. They take into account
-method arguments as well as static information. This means that they must be
-evaluated with every method invocation and that the result cannot be cached, as arguments will
-vary.
-
-The main example is the `control flow` pointcut.
-
-[[aop-api-pointcuts-cflow]]
-==== Control Flow Pointcuts
-
-Spring control flow pointcuts are conceptually similar to AspectJ `cflow` pointcuts,
-although less powerful. (There is currently no way to specify that a pointcut runs
-below a join point matched by another pointcut.) A control flow pointcut matches the
-current call stack. For example, it might fire if the join point was invoked by a method
-in the `com.mycompany.web` package or by the `SomeCaller` class. Control flow pointcuts
-are specified by using the `org.springframework.aop.support.ControlFlowPointcut` class.
-
-NOTE: Control flow pointcuts are significantly more expensive to evaluate at runtime than even
-other dynamic pointcuts. In Java 1.4, the cost is about five times that of other dynamic
-pointcuts.
-
-
-
-[[aop-api-pointcuts-superclasses]]
-== Pointcut Superclasses
-
-Spring provides useful pointcut superclasses to help you to implement your own pointcuts.
-
-Because static pointcuts are most useful, you should probably subclass
-`StaticMethodMatcherPointcut`. This requires implementing only one
-abstract method (although you can override other methods to customize behavior). The
-following example shows how to subclass `StaticMethodMatcherPointcut`:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	class TestStaticPointcut extends StaticMethodMatcherPointcut {
-
-		public boolean matches(Method m, Class targetClass) {
-			// return true if custom criteria match
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class TestStaticPointcut : StaticMethodMatcherPointcut() {
-
-		override fun matches(method: Method, targetClass: Class<*>): Boolean {
-			// return true if custom criteria match
-		}
-	}
----
-======
-
-There are also superclasses for dynamic pointcuts.
-You can use custom pointcuts with any advice type.
-
-
-
-[[aop-api-pointcuts-custom]]
-== Custom Pointcuts
-
-Because pointcuts in Spring AOP are Java classes rather than language features (as in
-AspectJ), you can declare custom pointcuts, whether static or dynamic. Custom
-pointcuts in Spring can be arbitrarily complex. However, we recommend using the AspectJ pointcut
-expression language, if you can.
-
-NOTE: Later versions of Spring may offer support for "`semantic pointcuts`" as offered by JAC --
-for example, "`all methods that change instance variables in the target object.`"
-
-
-
-
@@ -1,54 +0,0 @@
-[[aop-prog]]
-= Creating AOP Proxies Programmatically with the `ProxyFactory`
-
-It is easy to create AOP proxies programmatically with Spring. This lets you use
-Spring AOP without dependency on Spring IoC.
-
-The interfaces implemented by the target object are
-automatically proxied. The following listing shows creation of a proxy for a target object, with one
-interceptor and one advisor:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	ProxyFactory factory = new ProxyFactory(myBusinessInterfaceImpl);
-	factory.addAdvice(myMethodInterceptor);
-	factory.addAdvisor(myAdvisor);
-	MyBusinessInterface tb = (MyBusinessInterface) factory.getProxy();
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	val factory = ProxyFactory(myBusinessInterfaceImpl)
-	factory.addAdvice(myMethodInterceptor)
-	factory.addAdvisor(myAdvisor)
-	val tb = factory.proxy as MyBusinessInterface
----
-======
-
-The first step is to construct an object of type
-`org.springframework.aop.framework.ProxyFactory`. You can create this with a target
-object, as in the preceding example, or specify the interfaces to be proxied in an alternate
-constructor.
-
-You can add advice (with interceptors as a specialized kind of advice), advisors, or both
-and manipulate them for the life of the `ProxyFactory`. If you add an
-`IntroductionInterceptionAroundAdvisor`, you can cause the proxy to implement additional
-interfaces.
-
-There are also convenience methods on `ProxyFactory` (inherited from `AdvisedSupport`)
-that let you add other advice types, such as before and throws advice.
-`AdvisedSupport` is the superclass of both `ProxyFactory` and `ProxyFactoryBean`.
-
-TIP: Integrating AOP proxy creation with the IoC framework is best practice in most
-applications. We recommend that you externalize configuration from Java code with AOP,
-as you should in general.
-
-
-
-
@@ -1,232 +0,0 @@
-[[aop-targetsource]]
-= Using `TargetSource` Implementations
-
-Spring offers the concept of a `TargetSource`, expressed in the
-`org.springframework.aop.TargetSource` interface. This interface is responsible for
-returning the "`target object`" that implements the join point. The `TargetSource`
-implementation is asked for a target instance each time the AOP proxy handles a method
-invocation.
-
-Developers who use Spring AOP do not normally need to work directly with `TargetSource` implementations, but
-this provides a powerful means of supporting pooling, hot swappable, and other
-sophisticated targets. For example, a pooling `TargetSource` can return a different target
-instance for each invocation, by using a pool to manage instances.
-
-If you do not specify a `TargetSource`, a default implementation is used to wrap a
-local object. The same target is returned for each invocation (as you would expect).
-
-The rest of this section describes the standard target sources provided with Spring and how you can use them.
-
-TIP: When using a custom target source, your target will usually need to be a prototype
-rather than a singleton bean definition. This allows Spring to create a new target
-instance when required.
-
-
-
-[[aop-ts-swap]]
-== Hot-swappable Target Sources
-
-The `org.springframework.aop.target.HotSwappableTargetSource` exists to let the target
-of an AOP proxy be switched while letting callers keep their references to it.
-
-Changing the target source's target takes effect immediately. The
-`HotSwappableTargetSource` is thread-safe.
-
-You can change the target by using the `swap()` method on HotSwappableTargetSource, as the follow example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	HotSwappableTargetSource swapper = (HotSwappableTargetSource) beanFactory.getBean("swapper");
-	Object oldTarget = swapper.swap(newTarget);
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	val swapper = beanFactory.getBean("swapper") as HotSwappableTargetSource
-	val oldTarget = swapper.swap(newTarget)
----
-======
-
-The following example shows the required XML definitions:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="initialTarget" class="mycompany.OldTarget"/>
-
-	<bean id="swapper" class="org.springframework.aop.target.HotSwappableTargetSource">
-		<constructor-arg ref="initialTarget"/>
-	</bean>
-
-	<bean id="swappable" class="org.springframework.aop.framework.ProxyFactoryBean">
-		<property name="targetSource" ref="swapper"/>
-	</bean>
----
-
-The preceding `swap()` call changes the target of the swappable bean. Clients that hold a
-reference to that bean are unaware of the change but immediately start hitting
-the new target.
-
-Although this example does not add any advice (it is not necessary to add advice to
-use a `TargetSource`), any `TargetSource` can be used in conjunction with
-arbitrary advice.
-
-
-
-[[aop-ts-pool]]
-== Pooling Target Sources
-
-Using a pooling target source provides a similar programming model to stateless session
-EJBs, in which a pool of identical instances is maintained, with method invocations
-going to free objects in the pool.
-
-A crucial difference between Spring pooling and SLSB pooling is that Spring pooling can
-be applied to any POJO. As with Spring in general, this service can be applied in a
-non-invasive way.
-
-Spring provides support for Commons Pool 2.2, which provides a
-fairly efficient pooling implementation. You need the `commons-pool` Jar on your
-application's classpath to use this feature. You can also subclass
-`org.springframework.aop.target.AbstractPoolingTargetSource` to support any other
-pooling API.
-
-NOTE: Commons Pool 1.5+ is also supported but is deprecated as of Spring Framework 4.2.
-
-The following listing shows an example configuration:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="businessObjectTarget" class="com.mycompany.MyBusinessObject"
-			scope="prototype">
-		... properties omitted
-	</bean>
-
-	<bean id="poolTargetSource" class="org.springframework.aop.target.CommonsPool2TargetSource">
-		<property name="targetBeanName" value="businessObjectTarget"/>
-		<property name="maxSize" value="25"/>
-	</bean>
-
-	<bean id="businessObject" class="org.springframework.aop.framework.ProxyFactoryBean">
-		<property name="targetSource" ref="poolTargetSource"/>
-		<property name="interceptorNames" value="myInterceptor"/>
-	</bean>
----
-
-Note that the target object (`businessObjectTarget` in the preceding example) must be a
-prototype. This lets the `PoolingTargetSource` implementation create new instances
-of the target to grow the pool as necessary. See the {spring-framework-api}/aop/target/AbstractPoolingTargetSource.html[javadoc of
-`AbstractPoolingTargetSource`] and the concrete subclass you wish to use for information
-about its properties. `maxSize` is the most basic and is always guaranteed to be present.
-
-In this case, `myInterceptor` is the name of an interceptor that would need to be
-defined in the same IoC context. However, you need not specify interceptors to
-use pooling. If you want only pooling and no other advice, do not set the
-`interceptorNames` property at all.
-
-You can configure Spring to be able to cast any pooled object to the
-`org.springframework.aop.target.PoolingConfig` interface, which exposes information
-about the configuration and current size of the pool through an introduction. You
-need to define an advisor similar to the following:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="poolConfigAdvisor" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
-		<property name="targetObject" ref="poolTargetSource"/>
-		<property name="targetMethod" value="getPoolingConfigMixin"/>
-	</bean>
----
-
-This advisor is obtained by calling a convenience method on the
-`AbstractPoolingTargetSource` class, hence the use of `MethodInvokingFactoryBean`. This
-advisor's name (`poolConfigAdvisor`, here) must be in the list of interceptors names in
-the `ProxyFactoryBean` that exposes the pooled object.
-
-The cast is defined as follows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	PoolingConfig conf = (PoolingConfig) beanFactory.getBean("businessObject");
-	System.out.println("Max pool size is " + conf.getMaxSize());
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	val conf = beanFactory.getBean("businessObject") as PoolingConfig
-	println("Max pool size is " + conf.maxSize)
----
-======
-
-NOTE: Pooling stateless service objects is not usually necessary. We do not believe it should
-be the default choice, as most stateless objects are naturally thread-safe, and instance
-pooling is problematic if resources are cached.
-
-Simpler pooling is available by using auto-proxying. You can set the `TargetSource` implementations
-used by any auto-proxy creator.
-
-
-
-[[aop-ts-prototype]]
-== Prototype Target Sources
-
-Setting up a "`prototype`" target source is similar to setting up a pooling `TargetSource`. In this
-case, a new instance of the target is created on every method invocation. Although
-the cost of creating a new object is not high in a modern JVM, the cost of wiring up the
-new object (satisfying its IoC dependencies) may be more expensive. Thus, you should not
-use this approach without very good reason.
-
-To do this, you could modify the `poolTargetSource` definition shown earlier as follows
-(we also changed the name, for clarity):
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="prototypeTargetSource" class="org.springframework.aop.target.PrototypeTargetSource">
-		<property name="targetBeanName" ref="businessObjectTarget"/>
-	</bean>
----
-
-The only property is the name of the target bean. Inheritance is used in the
-`TargetSource` implementations to ensure consistent naming. As with the pooling target
-source, the target bean must be a prototype bean definition.
-
-
-
-[[aop-ts-threadlocal]]
-== `ThreadLocal` Target Sources
-
-`ThreadLocal` target sources are useful if you need an object to be created for each
-incoming request (per thread that is). The concept of a `ThreadLocal` provides a JDK-wide
-facility to transparently store a resource alongside a thread. Setting up a
-`ThreadLocalTargetSource` is pretty much the same as was explained for the other types
-of target source, as the following example shows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="threadlocalTargetSource" class="org.springframework.aop.target.ThreadLocalTargetSource">
-		<property name="targetBeanName" value="businessObjectTarget"/>
-	</bean>
----
-
-NOTE: `ThreadLocal` instances come with serious issues (potentially resulting in memory leaks) when
-incorrectly using them in multi-threaded and multi-classloader environments. You
-should always consider wrapping a `ThreadLocal` in some other class and never directly use
-the `ThreadLocal` itself (except in the wrapper class). Also, you should
-always remember to correctly set and unset (where the latter simply involves a call to
-`ThreadLocal.set(null)`) the resource local to the thread. Unsetting should be done in
-any case, since not unsetting it might result in problematic behavior. Spring's
-`ThreadLocal` support does this for you and should always be considered in favor of using
-`ThreadLocal` instances without other proper handling code.
-
-
-
-
@@ -1,38 +0,0 @@
-[[aop]]
-= Aspect Oriented Programming with Spring
-
-Aspect-oriented Programming (AOP) complements Object-oriented Programming (OOP) by
-providing another way of thinking about program structure. The key unit of modularity
-in OOP is the class, whereas in AOP the unit of modularity is the aspect. Aspects
-enable the modularization of concerns (such as transaction management) that cut across
-multiple types and objects. (Such concerns are often termed "crosscutting" concerns
-in AOP literature.)
-
-One of the key components of Spring is the AOP framework. While the Spring IoC
-container does not depend on AOP (meaning you do not need to use AOP if you don't want
-to), AOP complements Spring IoC to provide a very capable middleware solution.
-
-.Spring AOP with AspectJ pointcuts
-****
-Spring provides simple and powerful ways of writing custom aspects by using either a
-xref:core/aop/schema.adoc[schema-based approach] or the xref:core/aop/ataspectj.adoc[@AspectJ annotation style].
-Both of these styles offer fully typed advice and use of the AspectJ pointcut language
-while still using Spring AOP for weaving.
-
-This chapter discusses the schema- and @AspectJ-based AOP support.
-The lower-level AOP support is discussed in xref:core/aop-api.adoc[the following chapter].
-****
-
-AOP is used in the Spring Framework to:
-
-* Provide declarative enterprise services. The most important such service is
-  xref:data-access/transaction/declarative.adoc[declarative transaction management].
-* Let users implement custom aspects, complementing their use of OOP with AOP.
-
-NOTE: If you are interested only in generic declarative services or other pre-packaged
-declarative middleware services such as pooling, you do not need to work directly with
-Spring AOP, and can skip most of this chapter.
-
-
-
-
@@ -1,59 +0,0 @@
-[[aop-aspectj-programmatic]]
-= Programmatic Creation of @AspectJ Proxies
-
-In addition to declaring aspects in your configuration by using either `<aop:config>`
-or `<aop:aspectj-autoproxy>`, it is also possible to programmatically create proxies
-that advise target objects. For the full details of Spring's AOP API, see the
-xref:core/aop-api.adoc[next chapter]. Here, we want to focus on the ability to automatically
-create proxies by using @AspectJ aspects.
-
-You can use the `org.springframework.aop.aspectj.annotation.AspectJProxyFactory` class
-to create a proxy for a target object that is advised by one or more @AspectJ aspects.
-The basic usage for this class is very simple, as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	// create a factory that can generate a proxy for the given target object
-	AspectJProxyFactory factory = new AspectJProxyFactory(targetObject);
-
-	// add an aspect, the class must be an @AspectJ aspect
-	// you can call this as many times as you need with different aspects
-	factory.addAspect(SecurityManager.class);
-
-	// you can also add existing aspect instances, the type of the object supplied
-	// must be an @AspectJ aspect
-	factory.addAspect(usageTracker);
-
-	// now get the proxy object...
-	MyInterfaceType proxy = factory.getProxy();
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	// create a factory that can generate a proxy for the given target object
-	val factory = AspectJProxyFactory(targetObject)
-
-	// add an aspect, the class must be an @AspectJ aspect
-	// you can call this as many times as you need with different aspects
-	factory.addAspect(SecurityManager::class.java)
-
-	// you can also add existing aspect instances, the type of the object supplied
-	// must be an @AspectJ aspect
-	factory.addAspect(usageTracker)
-
-	// now get the proxy object...
-	val proxy = factory.getProxy<Any>()
----
-======
-
-See the {spring-framework-api}/aop/aspectj/annotation/AspectJProxyFactory.html[javadoc] for more information.
-
-
-
-
@@ -1,16 +0,0 @@
-[[aop-ataspectj]]
-= @AspectJ support
-:page-section-summary-toc: 1
-
-@AspectJ refers to a style of declaring aspects as regular Java classes annotated with
-annotations. The @AspectJ style was introduced by the
-{aspectj-site}[AspectJ project] as part of the AspectJ 5 release. Spring
-interprets the same annotations as AspectJ 5, using a library supplied by AspectJ
-for pointcut parsing and matching. The AOP runtime is still pure Spring AOP, though, and
-there is no dependency on the AspectJ compiler or weaver.
-
-NOTE: Using the AspectJ compiler and weaver enables use of the full AspectJ language and
-is discussed in xref:core/aop/using-aspectj.adoc[Using AspectJ with Spring Applications].
-
-
-
@@ -1,941 +0,0 @@
-[[aop-advice]]
-= Declaring Advice
-
-Advice is associated with a pointcut expression and runs before, after, or around method
-executions matched by the pointcut. The pointcut expression may be either an _inline
-pointcut_ or a reference to a xref:core/aop/ataspectj/pointcuts.adoc#aop-common-pointcuts[_named pointcut_].
-
-
-[[aop-advice-before]]
-== Before Advice
-
-You can declare before advice in an aspect by using the `@Before` annotation.
-
-The following example uses an inline pointcut expression.
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	import org.aspectj.lang.annotation.Aspect;
-	import org.aspectj.lang.annotation.Before;
-
-	@Aspect
-	public class BeforeExample {
-
-		@Before("execution(* com.xyz.dao.*.*(..))")
-		public void doAccessCheck() {
-			// ...
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	import org.aspectj.lang.annotation.Aspect
-	import org.aspectj.lang.annotation.Before
-
-	@Aspect
-	class BeforeExample {
-
-		@Before("execution(* com.xyz.dao.*.*(..))")
-		fun doAccessCheck() {
-			// ...
-		}
-	}
----
-======
-
-If we use a xref:core/aop/ataspectj/pointcuts.adoc#aop-common-pointcuts[named pointcut], we can rewrite the preceding example
-as follows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	import org.aspectj.lang.annotation.Aspect;
-	import org.aspectj.lang.annotation.Before;
-
-	@Aspect
-	public class BeforeExample {
-
-		@Before("com.xyz.CommonPointcuts.dataAccessOperation()")
-		public void doAccessCheck() {
-			// ...
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	import org.aspectj.lang.annotation.Aspect
-	import org.aspectj.lang.annotation.Before
-
-	@Aspect
-	class BeforeExample {
-
-		@Before("com.xyz.CommonPointcuts.dataAccessOperation()")
-		fun doAccessCheck() {
-			// ...
-		}
-	}
----
-======
-
-
-[[aop-advice-after-returning]]
-== After Returning Advice
-
-After returning advice runs when a matched method execution returns normally.
-You can declare it by using the `@AfterReturning` annotation.
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	import org.aspectj.lang.annotation.Aspect;
-	import org.aspectj.lang.annotation.AfterReturning;
-
-	@Aspect
-	public class AfterReturningExample {
-
-		@AfterReturning("execution(* com.xyz.dao.*.*(..))")
-		public void doAccessCheck() {
-			// ...
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	import org.aspectj.lang.annotation.Aspect
-	import org.aspectj.lang.annotation.AfterReturning
-
-	@Aspect
-	class AfterReturningExample {
-
-		@AfterReturning("execution(* com.xyz.dao.*.*(..))")
-		fun doAccessCheck() {
-			// ...
-		}
-	}
----
-======
-
-NOTE: You can have multiple advice declarations (and other members as well),
-all inside the same aspect. We show only a single advice declaration in these
-examples to focus the effect of each one.
-
-Sometimes, you need access in the advice body to the actual value that was returned.
-You can use the form of `@AfterReturning` that binds the return value to get that
-access, as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	import org.aspectj.lang.annotation.Aspect;
-	import org.aspectj.lang.annotation.AfterReturning;
-
-	@Aspect
-	public class AfterReturningExample {
-
-		@AfterReturning(
-			pointcut="execution(* com.xyz.dao.*.*(..))",
-			returning="retVal")
-		public void doAccessCheck(Object retVal) {
-			// ...
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	import org.aspectj.lang.annotation.Aspect
-	import org.aspectj.lang.annotation.AfterReturning
-
-	@Aspect
-	class AfterReturningExample {
-
-		@AfterReturning(
-			pointcut = "execution(* com.xyz.dao.*.*(..))",
-			returning = "retVal")
-		fun doAccessCheck(retVal: Any?) {
-			// ...
-		}
-	}
----
-======
-
-The name used in the `returning` attribute must correspond to the name of a parameter
-in the advice method. When a method execution returns, the return value is passed to
-the advice method as the corresponding argument value. A `returning` clause also
-restricts matching to only those method executions that return a value of the
-specified type (in this case, `Object`, which matches any return value).
-
-Please note that it is not possible to return a totally different reference when
-using after returning advice.
-
-
-[[aop-advice-after-throwing]]
-== After Throwing Advice
-
-After throwing advice runs when a matched method execution exits by throwing an
-exception. You can declare it by using the `@AfterThrowing` annotation, as the
-following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	import org.aspectj.lang.annotation.Aspect;
-	import org.aspectj.lang.annotation.AfterThrowing;
-
-	@Aspect
-	public class AfterThrowingExample {
-
-		@AfterThrowing("execution(* com.xyz.dao.*.*(..))")
-		public void doRecoveryActions() {
-			// ...
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	import org.aspectj.lang.annotation.Aspect
-	import org.aspectj.lang.annotation.AfterThrowing
-
-	@Aspect
-	class AfterThrowingExample {
-
-		@AfterThrowing("execution(* com.xyz.dao.*.*(..))")
-		fun doRecoveryActions() {
-			// ...
-		}
-	}
----
-======
-
-Often, you want the advice to run only when exceptions of a given type are thrown,
-and you also often need access to the thrown exception in the advice body. You can
-use the `throwing` attribute to both restrict matching (if desired -- use `Throwable`
-as the exception type otherwise) and bind the thrown exception to an advice parameter.
-The following example shows how to do so:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	import org.aspectj.lang.annotation.Aspect;
-	import org.aspectj.lang.annotation.AfterThrowing;
-
-	@Aspect
-	public class AfterThrowingExample {
-
-		@AfterThrowing(
-			pointcut="execution(* com.xyz.dao.*.*(..))",
-			throwing="ex")
-		public void doRecoveryActions(DataAccessException ex) {
-			// ...
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	import org.aspectj.lang.annotation.Aspect
-	import org.aspectj.lang.annotation.AfterThrowing
-
-	@Aspect
-	class AfterThrowingExample {
-
-		@AfterThrowing(
-			pointcut = "execution(* com.xyz.dao.*.*(..))",
-			throwing = "ex")
-		fun doRecoveryActions(ex: DataAccessException) {
-			// ...
-		}
-	}
----
-======
-
-The name used in the `throwing` attribute must correspond to the name of a parameter in
-the advice method. When a method execution exits by throwing an exception, the exception
-is passed to the advice method as the corresponding argument value. A `throwing` clause
-also restricts matching to only those method executions that throw an exception of the
-specified type (`DataAccessException`, in this case).
-
-[NOTE]
-====
-Note that `@AfterThrowing` does not indicate a general exception handling callback.
-Specifically, an `@AfterThrowing` advice method is only supposed to receive exceptions
-from the join point (user-declared target method) itself but not from an accompanying
-`@After`/`@AfterReturning` method.
-====
-
-
-[[aop-advice-after-finally]]
-== After (Finally) Advice
-
-After (finally) advice runs when a matched method execution exits. It is declared by
-using the `@After` annotation. After advice must be prepared to handle both normal and
-exception return conditions. It is typically used for releasing resources and similar
-purposes. The following example shows how to use after finally advice:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	import org.aspectj.lang.annotation.Aspect;
-	import org.aspectj.lang.annotation.After;
-
-	@Aspect
-	public class AfterFinallyExample {
-
-		@After("execution(* com.xyz.dao.*.*(..))")
-		public void doReleaseLock() {
-			// ...
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	import org.aspectj.lang.annotation.Aspect
-	import org.aspectj.lang.annotation.After
-
-	@Aspect
-	class AfterFinallyExample {
-
-		@After("execution(* com.xyz.dao.*.*(..))")
-		fun doReleaseLock() {
-			// ...
-		}
-	}
----
-======
-
-[NOTE]
-====
-Note that `@After` advice in AspectJ is defined as "after finally advice", analogous
-to a finally block in a try-catch statement. It will be invoked for any outcome,
-normal return or exception thrown from the join point (user-declared target method),
-in contrast to `@AfterReturning` which only applies to successful normal returns.
-====
-
-
-[[aop-ataspectj-around-advice]]
-== Around Advice
-
-The last kind of advice is _around_ advice. Around advice runs "around" a matched
-method's execution. It has the opportunity to do work both before and after the method
-runs and to determine when, how, and even if the method actually gets to run at all.
-Around advice is often used if you need to share state before and after a method
-execution in a thread-safe manner – for example, starting and stopping a timer.
-
-[TIP]
-====
-Always use the least powerful form of advice that meets your requirements.
-
-For example, do not use _around_ advice if _before_ advice is sufficient for your needs.
-====
-
-Around advice is declared by annotating a method with the `@Around` annotation. The
-method should declare `Object` as its return type, and the first parameter of the method
-must be of type `ProceedingJoinPoint`. Within the body of the advice method, you must
-invoke `proceed()` on the `ProceedingJoinPoint` in order for the underlying method to
-run. Invoking `proceed()` without arguments will result in the caller's original
-arguments being supplied to the underlying method when it is invoked. For advanced use
-cases, there is an overloaded variant of the `proceed()` method which accepts an array of
-arguments (`Object[]`). The values in the array will be used as the arguments to the
-underlying method when it is invoked.
-
-[NOTE]
-====
-The behavior of `proceed` when called with an `Object[]` is a little different than the
-behavior of `proceed` for around advice compiled by the AspectJ compiler. For around
-advice written using the traditional AspectJ language, the number of arguments passed to
-`proceed` must match the number of arguments passed to the around advice (not the number
-of arguments taken by the underlying join point), and the value passed to proceed in a
-given argument position supplants the original value at the join point for the entity the
-value was bound to (do not worry if this does not make sense right now).
-
-The approach taken by Spring is simpler and a better match to its proxy-based,
-execution-only semantics. You only need to be aware of this difference if you compile
-`@AspectJ` aspects written for Spring and use `proceed` with arguments with the AspectJ
-compiler and weaver. There is a way to write such aspects that is 100% compatible across
-both Spring AOP and AspectJ, and this is discussed in the
-xref:core/aop/ataspectj/advice.adoc#aop-ataspectj-advice-proceeding-with-the-call[following section on advice parameters].
-====
-
-The value returned by the around advice is the return value seen by the caller of the
-method. For example, a simple caching aspect could return a value from a cache if it has
-one or invoke `proceed()` (and return that value) if it does not. Note that `proceed`
-may be invoked once, many times, or not at all within the body of the around advice. All
-of these are legal.
-
-WARNING: If you declare the return type of your around advice method as `void`, `null`
-will always be returned to the caller, effectively ignoring the result of any invocation
-of `proceed()`. It is therefore recommended that an around advice method declare a return
-type of `Object`. The advice method should typically return the value returned from an
-invocation of `proceed()`, even if the underlying method has a `void` return type.
-However, the advice may optionally return a cached value, a wrapped value, or some other
-value depending on the use case.
-
-The following example shows how to use around advice:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	import org.aspectj.lang.annotation.Aspect;
-	import org.aspectj.lang.annotation.Around;
-	import org.aspectj.lang.ProceedingJoinPoint;
-
-	@Aspect
-	public class AroundExample {
-
-		@Around("execution(* com.xyz..service.*.*(..))")
-		public Object doBasicProfiling(ProceedingJoinPoint pjp) throws Throwable {
-			// start stopwatch
-			Object retVal = pjp.proceed();
-			// stop stopwatch
-			return retVal;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	import org.aspectj.lang.annotation.Aspect
-	import org.aspectj.lang.annotation.Around
-	import org.aspectj.lang.ProceedingJoinPoint
-
-	@Aspect
-	class AroundExample {
-
-		@Around("execution(* com.xyz..service.*.*(..))")
-		fun doBasicProfiling(pjp: ProceedingJoinPoint): Any? {
-			// start stopwatch
-			val retVal = pjp.proceed()
-			// stop stopwatch
-			return retVal
-		}
-	}
----
-======
-
-[[aop-ataspectj-advice-params]]
-== Advice Parameters
-
-Spring offers fully typed advice, meaning that you declare the parameters you need in the
-advice signature (as we saw earlier for the returning and throwing examples) rather than
-work with `Object[]` arrays all the time. We see how to make argument and other contextual
-values available to the advice body later in this section. First, we take a look at how to
-write generic advice that can find out about the method the advice is currently advising.
-
-[[aop-ataspectj-advice-params-the-joinpoint]]
-=== Access to the Current `JoinPoint`
-
-Any advice method may declare, as its first parameter, a parameter of type
-`org.aspectj.lang.JoinPoint`. Note that around advice is required to declare a first
-parameter of type `ProceedingJoinPoint`, which is a subclass of `JoinPoint`.
-
-The `JoinPoint` interface provides a number of useful methods:
-
-* `getArgs()`: Returns the method arguments.
-* `getThis()`: Returns the proxy object.
-* `getTarget()`: Returns the target object.
-* `getSignature()`: Returns a description of the method that is being advised.
-* `toString()`: Prints a useful description of the method being advised.
-
-See the {aspectj-api}/org/aspectj/lang/JoinPoint.html[javadoc] for more detail.
-
-[[aop-ataspectj-advice-params-passing]]
-=== Passing Parameters to Advice
-
-We have already seen how to bind the returned value or exception value (using after
-returning and after throwing advice). To make argument values available to the advice
-body, you can use the binding form of `args`. If you use a parameter name in place of a
-type name in an `args` expression, the value of the corresponding argument is passed as
-the parameter value when the advice is invoked. An example should make this clearer.
-Suppose you want to advise the execution of DAO operations that take an `Account`
-object as the first parameter, and you need access to the account in the advice body.
-You could write the following:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Before("execution(* com.xyz.dao.*.*(..)) && args(account,..)")
-	public void validateAccount(Account account) {
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Before("execution(* com.xyz.dao.*.*(..)) && args(account,..)")
-	fun validateAccount(account: Account) {
-		// ...
-	}
----
-======
-
-The `args(account,..)` part of the pointcut expression serves two purposes. First, it
-restricts matching to only those method executions where the method takes at least one
-parameter, and the argument passed to that parameter is an instance of `Account`.
-Second, it makes the actual `Account` object available to the advice through the `account`
-parameter.
-
-Another way of writing this is to declare a pointcut that "provides" the `Account`
-object value when it matches a join point, and then refer to the named pointcut
-from the advice. This would look as follows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Pointcut("execution(* com.xyz.dao.*.*(..)) && args(account,..)")
-	private void accountDataAccessOperation(Account account) {}
-
-	@Before("accountDataAccessOperation(account)")
-	public void validateAccount(Account account) {
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Pointcut("execution(* com.xyz.dao.*.*(..)) && args(account,..)")
-	private fun accountDataAccessOperation(account: Account) {
-	}
-
-	@Before("accountDataAccessOperation(account)")
-	fun validateAccount(account: Account) {
-		// ...
-	}
----
-======
-
-See the AspectJ programming guide for more details.
-
-The proxy object (`this`), target object (`target`), and annotations (`@within`,
-`@target`, `@annotation`, and `@args`) can all be bound in a similar fashion. The next
-set of examples shows how to match the execution of methods annotated with an
-`@Auditable` annotation and extract the audit code:
-
-The following shows the definition of the `@Auditable` annotation:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Retention(RetentionPolicy.RUNTIME)
-	@Target(ElementType.METHOD)
-	public @interface Auditable {
-		AuditCode value();
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Retention(AnnotationRetention.RUNTIME)
-	@Target(AnnotationTarget.FUNCTION)
-	annotation class Auditable(val value: AuditCode)
----
-======
-
-The following shows the advice that matches the execution of `@Auditable` methods:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Before("com.xyz.Pointcuts.publicMethod() && @annotation(auditable)") // <1>
-	public void audit(Auditable auditable) {
-		AuditCode code = auditable.value();
-		// ...
-	}
----
-<1> References the `publicMethod` named pointcut defined in xref:core/aop/ataspectj/pointcuts.adoc#aop-pointcuts-combining[Combining Pointcut Expressions].
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Before("com.xyz.Pointcuts.publicMethod() && @annotation(auditable)") // <1>
-	fun audit(auditable: Auditable) {
-		val code = auditable.value()
-		// ...
-	}
----
-<1> References the `publicMethod` named pointcut defined in xref:core/aop/ataspectj/pointcuts.adoc#aop-pointcuts-combining[Combining Pointcut Expressions].
-======
-
-[[aop-ataspectj-advice-params-generics]]
-=== Advice Parameters and Generics
-
-Spring AOP can handle generics used in class declarations and method parameters. Suppose
-you have a generic type like the following:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	public interface Sample<T> {
-		void sampleGenericMethod(T param);
-		void sampleGenericCollectionMethod(Collection<T> param);
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	interface Sample<T> {
-		fun sampleGenericMethod(param: T)
-		fun sampleGenericCollectionMethod(param: Collection<T>)
-	}
----
-======
-
-You can restrict interception of method types to certain parameter types by
-tying the advice parameter to the parameter type for which you want to intercept the method:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Before("execution(* ..Sample+.sampleGenericMethod(*)) && args(param)")
-	public void beforeSampleMethod(MyType param) {
-		// Advice implementation
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Before("execution(* ..Sample+.sampleGenericMethod(*)) && args(param)")
-	fun beforeSampleMethod(param: MyType) {
-		// Advice implementation
-	}
----
-======
-
-This approach does not work for generic collections. So you cannot define a
-pointcut as follows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Before("execution(* ..Sample+.sampleGenericCollectionMethod(*)) && args(param)")
-	public void beforeSampleMethod(Collection<MyType> param) {
-		// Advice implementation
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Before("execution(* ..Sample+.sampleGenericCollectionMethod(*)) && args(param)")
-	fun beforeSampleMethod(param: Collection<MyType>) {
-		// Advice implementation
-	}
----
-======
-
-To make this work, we would have to inspect every element of the collection, which is not
-reasonable, as we also cannot decide how to treat `null` values in general. To achieve
-something similar to this, you have to type the parameter to `Collection<?>` and manually
-check the type of the elements.
-
-[[aop-ataspectj-advice-params-names]]
-=== Determining Argument Names
-
-Parameter binding in advice invocations relies on matching the names used in pointcut
-expressions to the parameter names declared in advice and pointcut method signatures.
-
-NOTE: This section uses the terms _argument_ and _parameter_ interchangeably, since
-AspectJ APIs refer to parameter names as argument names.
-
-Spring AOP uses the following `ParameterNameDiscoverer` implementations to determine
-parameter names. Each discoverer will be given a chance to discover parameter names, and
-the first successful discoverer wins. If none of the registered discoverers is capable
-of determining parameter names, an exception will be thrown.
-
-`AspectJAnnotationParameterNameDiscoverer` :: Uses parameter names that have been explicitly
-  specified by the user via the `argNames` attribute in the corresponding advice or
-  pointcut annotation. See xref:core/aop/ataspectj/advice.adoc#aop-ataspectj-advice-params-names-explicit[Explicit Argument Names] for details.
-`KotlinReflectionParameterNameDiscoverer` :: Uses Kotlin reflection APIs to determine
-  parameter names. This discoverer is only used if such APIs are present on the classpath.
-`StandardReflectionParameterNameDiscoverer` :: Uses the standard `java.lang.reflect.Parameter`
-  API to determine parameter names. Requires that code be compiled with the `-parameters`
-  flag for `javac`. Recommended approach on Java 8+.
-`AspectJAdviceParameterNameDiscoverer` :: Deduces parameter names from the pointcut
-  expression, `returning`, and `throwing` clauses. See the
-  {spring-framework-api}/aop/aspectj/AspectJAdviceParameterNameDiscoverer.html[javadoc]
-  for details on the algorithm used.
-
-[[aop-ataspectj-advice-params-names-explicit]]
-=== Explicit Argument Names
-
-@AspectJ advice and pointcut annotations have an optional `argNames` attribute that you
-can use to specify the argument names of the annotated method.
-
-[TIP]
-====
-If an @AspectJ aspect has been compiled by the AspectJ compiler (`ajc`) even without
-debug information, you do not need to add the `argNames` attribute, since the compiler
-retains the needed information.
-
-Similarly, if an @AspectJ aspect has been compiled with `javac` using the `-parameters`
-flag, you do not need to add the `argNames` attribute, since the compiler retains the
-needed information.
-====
-
-The following example shows how to use the `argNames` attribute:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Before(
-		value = "com.xyz.Pointcuts.publicMethod() && target(bean) && @annotation(auditable)", // <1>
-		argNames = "bean,auditable") // <2>
-	public void audit(Object bean, Auditable auditable) {
-		AuditCode code = auditable.value();
-		// ... use code and bean
-	}
----
-<1> References the `publicMethod` named pointcut defined in xref:core/aop/ataspectj/pointcuts.adoc#aop-pointcuts-combining[Combining Pointcut Expressions].
-<2> Declares `bean` and `auditable` as the argument names.
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Before(
-		value = "com.xyz.Pointcuts.publicMethod() && target(bean) && @annotation(auditable)", // <1>
-		argNames = "bean,auditable") // <2>
-	fun audit(bean: Any, auditable: Auditable) {
-		val code = auditable.value()
-		// ... use code and bean
-	}
----
-<1> References the `publicMethod` named pointcut defined in xref:core/aop/ataspectj/pointcuts.adoc#aop-pointcuts-combining[Combining Pointcut Expressions].
-<2> Declares `bean` and `auditable` as the argument names.
-======
-
-If the first parameter is of type `JoinPoint`, `ProceedingJoinPoint`, or
-`JoinPoint.StaticPart`, you can omit the name of the parameter from the value of the
-`argNames` attribute. For example, if you modify the preceding advice to receive the join
-point object, the `argNames` attribute does not need to include it:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Before(
-		value = "com.xyz.Pointcuts.publicMethod() && target(bean) && @annotation(auditable)", // <1>
-		argNames = "bean,auditable") // <2>
-	public void audit(JoinPoint jp, Object bean, Auditable auditable) {
-		AuditCode code = auditable.value();
-		// ... use code, bean, and jp
-	}
----
-<1> References the `publicMethod` named pointcut defined in xref:core/aop/ataspectj/pointcuts.adoc#aop-pointcuts-combining[Combining Pointcut Expressions].
-<2> Declares `bean` and `auditable` as the argument names.
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Before(
-		value = "com.xyz.Pointcuts.publicMethod() && target(bean) && @annotation(auditable)", // <1>
-		argNames = "bean,auditable") // <2>
-	fun audit(jp: JoinPoint, bean: Any, auditable: Auditable) {
-		val code = auditable.value()
-		// ... use code, bean, and jp
-	}
----
-<1> References the `publicMethod` named pointcut defined in xref:core/aop/ataspectj/pointcuts.adoc#aop-pointcuts-combining[Combining Pointcut Expressions].
-<2> Declares `bean` and `auditable` as the argument names.
-======
-
-The special treatment given to the first parameter of type `JoinPoint`,
-`ProceedingJoinPoint`, or `JoinPoint.StaticPart` is particularly convenient for advice
-methods that do not collect any other join point context. In such situations, you may
-omit the `argNames` attribute. For example, the following advice does not need to declare
-the `argNames` attribute:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Before("com.xyz.Pointcuts.publicMethod()") // <1>
-	public void audit(JoinPoint jp) {
-		// ... use jp
-	}
----
-<1> References the `publicMethod` named pointcut defined in xref:core/aop/ataspectj/pointcuts.adoc#aop-pointcuts-combining[Combining Pointcut Expressions].
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Before("com.xyz.Pointcuts.publicMethod()") // <1>
-	fun audit(jp: JoinPoint) {
-		// ... use jp
-	}
----
-<1> References the `publicMethod` named pointcut defined in xref:core/aop/ataspectj/pointcuts.adoc#aop-pointcuts-combining[Combining Pointcut Expressions].
-======
-
-
-[[aop-ataspectj-advice-proceeding-with-the-call]]
-=== Proceeding with Arguments
-
-We remarked earlier that we would describe how to write a `proceed` call with
-arguments that works consistently across Spring AOP and AspectJ. The solution is
-to ensure that the advice signature binds each of the method parameters in order.
-The following example shows how to do so:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Around("execution(List<Account> find*(..)) && " +
-			"com.xyz.CommonPointcuts.inDataAccessLayer() && " +
-			"args(accountHolderNamePattern)") // <1>
-	public Object preProcessQueryPattern(ProceedingJoinPoint pjp,
-			String accountHolderNamePattern) throws Throwable {
-		String newPattern = preProcess(accountHolderNamePattern);
-		return pjp.proceed(new Object[] {newPattern});
-	}
----
-<1> References the `inDataAccessLayer` named pointcut defined in xref:core/aop/ataspectj/pointcuts.adoc#aop-common-pointcuts[Sharing Named Pointcut Definitions].
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Around("execution(List<Account> find*(..)) && " +
-			"com.xyz.CommonPointcuts.inDataAccessLayer() && " +
-			"args(accountHolderNamePattern)") // <1>
-	fun preProcessQueryPattern(pjp: ProceedingJoinPoint,
-							accountHolderNamePattern: String): Any? {
-		val newPattern = preProcess(accountHolderNamePattern)
-		return pjp.proceed(arrayOf<Any>(newPattern))
-	}
----
-<1> References the `inDataAccessLayer` named pointcut defined in xref:core/aop/ataspectj/pointcuts.adoc#aop-common-pointcuts[Sharing Named Pointcut Definitions].
-======
-
-In many cases, you do this binding anyway (as in the preceding example).
-
-
-[[aop-ataspectj-advice-ordering]]
-== Advice Ordering
-
-What happens when multiple pieces of advice all want to run at the same join point?
-Spring AOP follows the same precedence rules as AspectJ to determine the order of advice
-execution. The highest precedence advice runs first "on the way in" (so, given two pieces
-of before advice, the one with highest precedence runs first). "On the way out" from a
-join point, the highest precedence advice runs last (so, given two pieces of after
-advice, the one with the highest precedence will run second).
-
-When two pieces of advice defined in different aspects both need to run at the same
-join point, unless you specify otherwise, the order of execution is undefined. You can
-control the order of execution by specifying precedence. This is done in the normal
-Spring way by either implementing the `org.springframework.core.Ordered` interface in
-the aspect class or annotating it with the `@Order` annotation. Given two aspects, the
-aspect returning the lower value from `Ordered.getOrder()` (or the annotation value) has
-the higher precedence.
-
-[NOTE]
-====
-Each of the distinct advice types of a particular aspect is conceptually meant to apply
-to the join point directly. As a consequence, an `@AfterThrowing` advice method is not
-supposed to receive an exception from an accompanying `@After`/`@AfterReturning` method.
-
-As of Spring Framework 5.2.7, advice methods defined in the same `@Aspect` class that
-need to run at the same join point are assigned precedence based on their advice type in
-the following order, from highest to lowest precedence: `@Around`, `@Before`, `@After`,
-`@AfterReturning`, `@AfterThrowing`. Note, however, that an `@After` advice method will
-effectively be invoked after any `@AfterReturning` or `@AfterThrowing` advice methods
-in the same aspect, following AspectJ's "after finally advice" semantics for `@After`.
-
-When two pieces of the same type of advice (for example, two `@After` advice methods)
-defined in the same `@Aspect` class both need to run at the same join point, the ordering
-is undefined (since there is no way to retrieve the source code declaration order through
-reflection for javac-compiled classes). Consider collapsing such advice methods into one
-advice method per join point in each `@Aspect` class or refactor the pieces of advice into
-separate `@Aspect` classes that you can order at the aspect level via `Ordered` or `@Order`.
-====
-
-
@@ -1,61 +0,0 @@
-[[aop-aspectj-support]]
-= Enabling @AspectJ Support
-
-To use @AspectJ aspects in a Spring configuration, you need to enable Spring support for
-configuring Spring AOP based on @AspectJ aspects and auto-proxying beans based on
-whether or not they are advised by those aspects. By auto-proxying, we mean that, if Spring
-determines that a bean is advised by one or more aspects, it automatically generates
-a proxy for that bean to intercept method invocations and ensures that advice is run
-as needed.
-
-The @AspectJ support can be enabled with XML- or Java-style configuration. In either
-case, you also need to ensure that AspectJ's `aspectjweaver.jar` library is on the
-classpath of your application (version 1.9 or later). This library is available in the
-`lib` directory of an AspectJ distribution or from the Maven Central repository.
-
-
-[[aop-enable-aspectj-java]]
-== Enabling @AspectJ Support with Java Configuration
-
-To enable @AspectJ support with Java `@Configuration`, add the `@EnableAspectJAutoProxy`
-annotation, as the following example shows:
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Configuration
-	@EnableAspectJAutoProxy
-	public class AppConfig {
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Configuration
-	@EnableAspectJAutoProxy
-	class AppConfig
----
-======
-
-[[aop-enable-aspectj-xml]]
-== Enabling @AspectJ Support with XML Configuration
-
-To enable @AspectJ support with XML-based configuration, use the `aop:aspectj-autoproxy`
-element, as the following example shows:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:aspectj-autoproxy/>
----
-
-This assumes that you use schema support as described in
-xref:core/appendix/xsd-schemas.adoc[XML Schema-based configuration].
-See xref:core/appendix/xsd-schemas.adoc#aop[the AOP schema] for how to
-import the tags in the `aop` namespace.
-
-
-
@@ -1,68 +0,0 @@
-[[aop-at-aspectj]]
-= Declaring an Aspect
-
-With @AspectJ support enabled, any bean defined in your application context with a
-class that is an @AspectJ aspect (has the `@Aspect` annotation) is automatically
-detected by Spring and used to configure Spring AOP. The next two examples show the
-minimal steps required for a not-very-useful aspect.
-
-The first of the two examples shows a regular bean definition in the application context
-that points to a bean class that is annotated with `@Aspect`:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<bean id="myAspect" class="com.xyz.NotVeryUsefulAspect">
-		<!-- configure properties of the aspect here -->
-	</bean>
----
-
-The second of the two examples shows the `NotVeryUsefulAspect` class definition, which is
-annotated with `@Aspect`:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary",chomp="-packages",fold="none"]
----
-	package com.xyz;
-
-	import org.aspectj.lang.annotation.Aspect;
-
-	@Aspect
-	public class NotVeryUsefulAspect {
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary",chomp="-packages",fold="none"]
----
-	package com.xyz
-
-	import org.aspectj.lang.annotation.Aspect
-
-	@Aspect
-	class NotVeryUsefulAspect
----
-======
-
-Aspects (classes annotated with `@Aspect`) can have methods and fields, the same as any
-other class. They can also contain pointcut, advice, and introduction (inter-type)
-declarations.
-
-.Autodetecting aspects through component scanning
-NOTE: You can register aspect classes as regular beans in your Spring XML configuration,
-via `@Bean` methods in `@Configuration` classes, or have Spring autodetect them through
-classpath scanning -- the same as any other Spring-managed bean. However, note that the
-`@Aspect` annotation is not sufficient for autodetection in the classpath. For that
-purpose, you need to add a separate `@Component` annotation (or, alternatively, a custom
-stereotype annotation that qualifies, as per the rules of Spring's component scanner).
-
-.Advising aspects with other aspects?
-NOTE: In Spring AOP, aspects themselves cannot be the targets of advice from other
-aspects. The `@Aspect` annotation on a class marks it as an aspect and, hence, excludes
-it from auto-proxying.
-
-
-
@@ -1,183 +0,0 @@
-[[aop-ataspectj-example]]
-= An AOP Example
-
-Now that you have seen how all the constituent parts work, we can put them together to do
-something useful.
-
-The execution of business services can sometimes fail due to concurrency issues (for
-example, a deadlock loser). If the operation is retried, it is likely to succeed
-on the next try. For business services where it is appropriate to retry in such
-conditions (idempotent operations that do not need to go back to the user for conflict
-resolution), we want to transparently retry the operation to avoid the client seeing a
-`PessimisticLockingFailureException`. This is a requirement that clearly cuts across
-multiple services in the service layer and, hence, is ideal for implementing through an
-aspect.
-
-Because we want to retry the operation, we need to use around advice so that we can
-call `proceed` multiple times. The following listing shows the basic aspect implementation:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Aspect
-	public class ConcurrentOperationExecutor implements Ordered {
-
-		private static final int DEFAULT_MAX_RETRIES = 2;
-
-		private int maxRetries = DEFAULT_MAX_RETRIES;
-		private int order = 1;
-
-		public void setMaxRetries(int maxRetries) {
-			this.maxRetries = maxRetries;
-		}
-
-		public int getOrder() {
-			return this.order;
-		}
-
-		public void setOrder(int order) {
-			this.order = order;
-		}
-
-		@Around("com.xyz.CommonPointcuts.businessService()") // <1>
-		public Object doConcurrentOperation(ProceedingJoinPoint pjp) throws Throwable {
-			int numAttempts = 0;
-			PessimisticLockingFailureException lockFailureException;
-			do {
-				numAttempts++;
-				try {
-					return pjp.proceed();
-				}
-				catch(PessimisticLockingFailureException ex) {
-					lockFailureException = ex;
-				}
-			} while(numAttempts <= this.maxRetries);
-			throw lockFailureException;
-		}
-	}
----
-<1> References the `businessService` named pointcut defined in xref:core/aop/ataspectj/pointcuts.adoc#aop-common-pointcuts[Sharing Named Pointcut Definitions].
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Aspect
-	class ConcurrentOperationExecutor : Ordered {
-
-		private val DEFAULT_MAX_RETRIES = 2
-		private var maxRetries = DEFAULT_MAX_RETRIES
-		private var order = 1
-
-		fun setMaxRetries(maxRetries: Int) {
-			this.maxRetries = maxRetries
-		}
-
-		override fun getOrder(): Int {
-			return this.order
-		}
-
-		fun setOrder(order: Int) {
-			this.order = order
-		}
-
-		@Around("com.xyz.CommonPointcuts.businessService()") // <1>
-		fun doConcurrentOperation(pjp: ProceedingJoinPoint): Any? {
-			var numAttempts = 0
-			var lockFailureException: PessimisticLockingFailureException
-			do {
-				numAttempts++
-				try {
-					return pjp.proceed()
-				} catch (ex: PessimisticLockingFailureException) {
-					lockFailureException = ex
-				}
-
-			} while (numAttempts <= this.maxRetries)
-			throw lockFailureException
-		}
-	}
----
-<1> References the `businessService` named pointcut defined in xref:core/aop/ataspectj/pointcuts.adoc#aop-common-pointcuts[Sharing Named Pointcut Definitions].
-======
-
-Note that the aspect implements the `Ordered` interface so that we can set the precedence of
-the aspect higher than the transaction advice (we want a fresh transaction each time we
-retry). The `maxRetries` and `order` properties are both configured by Spring. The
-main action happens in the `doConcurrentOperation` around advice. Notice that, for the
-moment, we apply the retry logic to each `businessService`. We try to proceed,
-and if we fail with a `PessimisticLockingFailureException`, we try again, unless
-we have exhausted all of our retry attempts.
-
-The corresponding Spring configuration follows:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:aspectj-autoproxy/>
-
-	<bean id="concurrentOperationExecutor"
-			class="com.xyz.service.impl.ConcurrentOperationExecutor">
-		<property name="maxRetries" value="3"/>
-		<property name="order" value="100"/>
-	</bean>
----
-
-To refine the aspect so that it retries only idempotent operations, we might define the following
-`Idempotent` annotation:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Retention(RetentionPolicy.RUNTIME)
-	// marker annotation
-	public @interface Idempotent {
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Retention(AnnotationRetention.RUNTIME)
-	// marker annotation
-	annotation class Idempotent
----
-======
-
-We can then use the annotation to annotate the implementation of service operations. The change
-to the aspect to retry only idempotent operations involves refining the pointcut
-expression so that only `@Idempotent` operations match, as follows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Around("execution(* com.xyz..service.*.*(..)) && " +
-			"@annotation(com.xyz.service.Idempotent)")
-	public Object doConcurrentOperation(ProceedingJoinPoint pjp) throws Throwable {
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Around("execution(* com.xyz..service.*.*(..)) && " +
-			"@annotation(com.xyz.service.Idempotent)")
-	fun doConcurrentOperation(pjp: ProceedingJoinPoint): Any? {
-		// ...
-	}
----
-======
-
-
-
@@ -1,65 +0,0 @@
-[[aop-instantiation-models]]
-= Aspect Instantiation Models
-
-NOTE: This is an advanced topic. If you are just starting out with AOP, you can safely skip
-it until later.
-
-By default, there is a single instance of each aspect within the application
-context. AspectJ calls this the singleton instantiation model. It is possible to define
-aspects with alternate lifecycles. Spring supports AspectJ's `perthis`, `pertarget`, and
-`pertypewithin` instantiation models; `percflow` and `percflowbelow` are not currently
-supported.
-
-You can declare a `perthis` aspect by specifying a `perthis` clause in the `@Aspect`
-annotation. Consider the following example:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Aspect("perthis(execution(* com.xyz..service.*.*(..)))")
-	public class MyAspect {
-
-		private int someState;
-
-		@Before("execution(* com.xyz..service.*.*(..))")
-		public void recordServiceUsage() {
-			// ...
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Aspect("perthis(execution(* com.xyz..service.*.*(..)))")
-	class MyAspect {
-
-		private val someState: Int = 0
-
-		@Before("execution(* com.xyz..service.*.*(..))")
-		fun recordServiceUsage() {
-			// ...
-		}
-	}
----
-======
-
-In the preceding example, the effect of the `perthis` clause is that one aspect instance
-is created for each unique service object that performs a business service (each unique
-object bound to `this` at join points matched by the pointcut expression). The aspect
-instance is created the first time that a method is invoked on the service object. The
-aspect goes out of scope when the service object goes out of scope. Before the aspect
-instance is created, none of the advice within it runs. As soon as the aspect instance
-has been created, the advice declared within it runs at matched join points, but only
-when the service object is the one with which this aspect is associated. See the AspectJ
-Programming Guide for more information on `per` clauses.
-
-The `pertarget` instantiation model works in exactly the same way as `perthis`, but it
-creates one aspect instance for each unique target object at matched join points.
-
-
-
@@ -1,79 +0,0 @@
-[[aop-introductions]]
-= Introductions
-
-Introductions (known as inter-type declarations in AspectJ) enable an aspect to declare
-that advised objects implement a given interface, and to provide an implementation of
-that interface on behalf of those objects.
-
-You can make an introduction by using the `@DeclareParents` annotation. This annotation
-is used to declare that matching types have a new parent (hence the name). For example,
-given an interface named `UsageTracked` and an implementation of that interface named
-`DefaultUsageTracked`, the following aspect declares that all implementors of service
-interfaces also implement the `UsageTracked` interface (e.g. for statistics via JMX):
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Aspect
-	public class UsageTracking {
-
-		@DeclareParents(value="com.xyz.service.*+", defaultImpl=DefaultUsageTracked.class)
-		public static UsageTracked mixin;
-
-		@Before("execution(* com.xyz..service.*.*(..)) && this(usageTracked)")
-		public void recordUsage(UsageTracked usageTracked) {
-			usageTracked.incrementUseCount();
-		}
-
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Aspect
-	class UsageTracking {
-
-		companion object {
-			@DeclareParents(value = "com.xyz.service.*+",
-				defaultImpl = DefaultUsageTracked::class)
-			lateinit var mixin: UsageTracked
-		}
-
-		@Before("execution(* com.xyz..service.*.*(..)) && this(usageTracked)")
-		fun recordUsage(usageTracked: UsageTracked) {
-			usageTracked.incrementUseCount()
-		}
-	}
----
-======
-
-The interface to be implemented is determined by the type of the annotated field. The
-`value` attribute of the `@DeclareParents` annotation is an AspectJ type pattern. Any
-bean of a matching type implements the `UsageTracked` interface. Note that, in the
-before advice of the preceding example, service beans can be directly used as
-implementations of the `UsageTracked` interface. If accessing a bean programmatically,
-you would write the following:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	UsageTracked usageTracked = context.getBean("myService", UsageTracked.class);
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	val usageTracked = context.getBean("myService", UsageTracked.class)
----
-======
-
-
@@ -1,586 +0,0 @@
-[[aop-pointcuts]]
-= Declaring a Pointcut
-
-Pointcuts determine join points of interest and thus enable us to control
-when advice runs. Spring AOP only supports method execution join points for Spring
-beans, so you can think of a pointcut as matching the execution of methods on Spring
-beans. A pointcut declaration has two parts: a signature comprising a name and any
-parameters and a pointcut expression that determines exactly which method
-executions we are interested in. In the @AspectJ annotation-style of AOP, a pointcut
-signature is provided by a regular method definition, and the pointcut expression is
-indicated by using the `@Pointcut` annotation (the method serving as the pointcut signature
-must have a `void` return type).
-
-An example may help make this distinction between a pointcut signature and a pointcut
-expression clear. The following example defines a pointcut named `anyOldTransfer` that
-matches the execution of any method named `transfer`:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Pointcut("execution(* transfer(..))") // the pointcut expression
-	private void anyOldTransfer() {} // the pointcut signature
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Pointcut("execution(* transfer(..))") // the pointcut expression
-	private fun anyOldTransfer() {} // the pointcut signature
----
-======
-
-The pointcut expression that forms the value of the `@Pointcut` annotation is a regular
-AspectJ pointcut expression. For a full discussion of AspectJ's pointcut language, see
-the {aspectj-docs-progguide}/index.html[AspectJ
-Programming Guide] (and, for extensions, the
-{aspectj-docs}/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).
-
-
-[[aop-pointcuts-designators]]
-== Supported Pointcut Designators
-
-Spring AOP supports the following AspectJ pointcut designators (PCD) for use in pointcut
-expressions:
-
-* `execution`: For matching method execution join points. This is the primary
-  pointcut designator to use when working with Spring AOP.
-* `within`: Limits matching to join points within certain types (the execution
-  of a method declared within a matching type when using Spring AOP).
-* `this`: Limits matching to join points (the execution of methods when using Spring
-  AOP) where the bean reference (Spring AOP proxy) is an instance of the given type.
-* `target`: Limits matching to join points (the execution of methods when using
-  Spring AOP) where the target object (application object being proxied) is an instance
-  of the given type.
-* `args`: Limits matching to join points (the execution of methods when using Spring
-  AOP) where the arguments are instances of the given types.
-* `@target`: Limits matching to join points (the execution of methods when using
-  Spring AOP) where the class of the executing object has an annotation of the given type.
-* `@args`: Limits matching to join points (the execution of methods when using Spring
-  AOP) where the runtime type of the actual arguments passed have annotations of the
-  given types.
-* `@within`: Limits matching to join points within types that have the given
-  annotation (the execution of methods declared in types with the given annotation when
-  using Spring AOP).
-* `@annotation`: Limits matching to join points where the subject of the join point
-  (the method being run in Spring AOP) has the given annotation.
-
-.Other pointcut types
-****
-The full AspectJ pointcut language supports additional pointcut designators that are not
-supported in Spring: `call`, `get`, `set`, `preinitialization`,
-`staticinitialization`, `initialization`, `handler`, `adviceexecution`, `withincode`, `cflow`,
-`cflowbelow`, `if`, `@this`, and `@withincode`. Use of these pointcut designators in pointcut
-expressions interpreted by Spring AOP results in an `IllegalArgumentException` being
-thrown.
-
-The set of pointcut designators supported by Spring AOP may be extended in future
-releases to support more of the AspectJ pointcut designators.
-****
-
-Because Spring AOP limits matching to only method execution join points, the preceding discussion
-of the pointcut designators gives a narrower definition than you can find in the
-AspectJ programming guide. In addition, AspectJ itself has type-based semantics and, at
-an execution join point, both `this` and `target` refer to the same object: the
-object executing the method. Spring AOP is a proxy-based system and differentiates
-between the proxy object itself (which is bound to `this`) and the target object behind the
-proxy (which is bound to `target`).
-
-[NOTE]
-====
-Due to the proxy-based nature of Spring's AOP framework, calls within the target object
-are, by definition, not intercepted. For JDK proxies, only public interface method
-calls on the proxy can be intercepted. With CGLIB, public and protected method calls on
-the proxy are intercepted (and even package-visible methods, if necessary). However,
-common interactions through proxies should always be designed through public signatures.
-
-Note that pointcut definitions are generally matched against any intercepted method.
-If a pointcut is strictly meant to be public-only, even in a CGLIB proxy scenario with
-potential non-public interactions through proxies, it needs to be defined accordingly.
-
-If your interception needs include method calls or even constructors within the target
-class, consider the use of Spring-driven xref:core/aop/using-aspectj.adoc#aop-aj-ltw[native AspectJ weaving] instead
-of Spring's proxy-based AOP framework. This constitutes a different mode of AOP usage
-with different characteristics, so be sure to make yourself familiar with weaving
-before making a decision.
-====
-
-Spring AOP also supports an additional PCD named `bean`. This PCD lets you limit
-the matching of join points to a particular named Spring bean or to a set of named
-Spring beans (when using wildcards). The `bean` PCD has the following form:
-
-[source,indent=0,subs="verbatim"]
----
-	bean(idOrNameOfBean)
----
-
-The `idOrNameOfBean` token can be the name of any Spring bean. Limited wildcard
-support that uses the `*` character is provided, so, if you establish some naming
-conventions for your Spring beans, you can write a `bean` PCD expression
-to select them. As is the case with other pointcut designators, the `bean` PCD can
-be used with the `&&` (and), `||` (or), and `!` (negation) operators, too.
-
-[NOTE]
-====
-The `bean` PCD is supported only in Spring AOP and not in
-native AspectJ weaving. It is a Spring-specific extension to the standard PCDs that
-AspectJ defines and is, therefore, not available for aspects declared in the `@Aspect` model.
-
-The `bean` PCD operates at the instance level (building on the Spring bean name
-concept) rather than at the type level only (to which weaving-based AOP is limited).
-Instance-based pointcut designators are a special capability of Spring's
-proxy-based AOP framework and its close integration with the Spring bean factory, where
-it is natural and straightforward to identify specific beans by name.
-====
-
-
-[[aop-pointcuts-combining]]
-== Combining Pointcut Expressions
-
-You can combine pointcut expressions by using `&&,` `||` and `!`. You can also refer to
-pointcut expressions by name. The following example shows three pointcut expressions:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary",chomp="-packages"]
----
-	package com.xyz;
-
-	public class Pointcuts {
-
-		@Pointcut("execution(public * *(..))")
-		public void publicMethod() {} // <1>
-
-		@Pointcut("within(com.xyz.trading..*)")
-		public void inTrading() {} // <2>
-
-		@Pointcut("publicMethod() && inTrading()")
-		public void tradingOperation() {} // <3>
-	}
----
-<1> `publicMethod` matches if a method execution join point represents the execution
-of any public method.
-<2> `inTrading` matches if a method execution is in the trading module.
-<3> `tradingOperation` matches if a method execution represents any public method in the
-trading module.
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary",chomp="-packages"]
----
-	package com.xyz
-
-	class Pointcuts {
-
-		@Pointcut("execution(public * *(..))")
-		fun publicMethod() {} // <1>
-
-		@Pointcut("within(com.xyz.trading..*)")
-		fun inTrading() {} // <2>
-
-		@Pointcut("publicMethod() && inTrading()")
-		fun tradingOperation() {} // <3>
-	}
----
-<1> `publicMethod` matches if a method execution join point represents the execution
-of any public method.
-<2> `inTrading` matches if a method execution is in the trading module.
-<3> `tradingOperation` matches if a method execution represents any public method in the
-trading module.
-======
-
-It is a best practice to build more complex pointcut expressions out of smaller _named
-pointcuts_, as shown above. When referring to pointcuts by name, normal Java visibility
-rules apply (you can see `private` pointcuts in the same type, `protected` pointcuts in
-the hierarchy, `public` pointcuts anywhere, and so on). Visibility does not affect
-pointcut matching.
-
-
-[[aop-common-pointcuts]]
-== Sharing Named Pointcut Definitions
-
-When working with enterprise applications, developers often have the need to refer to
-modules of the application and particular sets of operations from within several aspects.
-We recommend defining a dedicated class that captures commonly used _named pointcut_
-expressions for this purpose. Such a class typically resembles the following
-`CommonPointcuts` example (though what you name the class is up to you):
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary",chomp="-packages",fold="none"]
----
-	package com.xyz;
-
-	import org.aspectj.lang.annotation.Pointcut;
-
-	public class CommonPointcuts {
-
-		/**
-		 * A join point is in the web layer if the method is defined
-		 * in a type in the com.xyz.web package or any sub-package
-		 * under that.
-		 */
-		@Pointcut("within(com.xyz.web..*)")
-		public void inWebLayer() {}
-
-		/**
-		 * A join point is in the service layer if the method is defined
-		 * in a type in the com.xyz.service package or any sub-package
-		 * under that.
-		 */
-		@Pointcut("within(com.xyz.service..*)")
-		public void inServiceLayer() {}
-
-		/**
-		 * A join point is in the data access layer if the method is defined
-		 * in a type in the com.xyz.dao package or any sub-package
-		 * under that.
-		 */
-		@Pointcut("within(com.xyz.dao..*)")
-		public void inDataAccessLayer() {}
-
-		/**
-		 * A business service is the execution of any method defined on a service
-		 * interface. This definition assumes that interfaces are placed in the
-		 * "service" package, and that implementation types are in sub-packages.
-		 *
-		 * If you group service interfaces by functional area (for example,
-		 * in packages com.xyz.abc.service and com.xyz.def.service) then
-		 * the pointcut expression "execution(* com.xyz..service.*.*(..))"
-		 * could be used instead.
-		 *
-		 * Alternatively, you can write the expression using the 'bean'
-		 * PCD, like so "bean(*Service)". (This assumes that you have
-		 * named your Spring service beans in a consistent fashion.)
-		 */
-		@Pointcut("execution(* com.xyz..service.*.*(..))")
-		public void businessService() {}
-
-		/**
-		 * A data access operation is the execution of any method defined on a
-		 * DAO interface. This definition assumes that interfaces are placed in the
-		 * "dao" package, and that implementation types are in sub-packages.
-		 */
-		@Pointcut("execution(* com.xyz.dao.*.*(..))")
-		public void dataAccessOperation() {}
-
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary",chomp="-packages",fold="none"]
----
-	package com.xyz
-
-	import org.aspectj.lang.annotation.Pointcut
-
-	class CommonPointcuts {
-
-		/**
-		 * A join point is in the web layer if the method is defined
-		 * in a type in the com.xyz.web package or any sub-package
-		 * under that.
-		 */
-		@Pointcut("within(com.xyz.web..*)")
-		fun inWebLayer() {}
-
-		/**
-		 * A join point is in the service layer if the method is defined
-		 * in a type in the com.xyz.service package or any sub-package
-		 * under that.
-		 */
-		@Pointcut("within(com.xyz.service..*)")
-		fun inServiceLayer() {}
-
-		/**
-		 * A join point is in the data access layer if the method is defined
-		 * in a type in the com.xyz.dao package or any sub-package
-		 * under that.
-		 */
-		@Pointcut("within(com.xyz.dao..*)")
-		fun inDataAccessLayer() {}
-
-		/**
-		 * A business service is the execution of any method defined on a service
-		 * interface. This definition assumes that interfaces are placed in the
-		 * "service" package, and that implementation types are in sub-packages.
-		 *
-		 * If you group service interfaces by functional area (for example,
-		 * in packages com.xyz.abc.service and com.xyz.def.service) then
-		 * the pointcut expression "execution(* com.xyz..service.*.*(..))"
-		 * could be used instead.
-		 *
-		 * Alternatively, you can write the expression using the 'bean'
-		 * PCD, like so "bean(*Service)". (This assumes that you have
-		 * named your Spring service beans in a consistent fashion.)
-		 */
-		@Pointcut("execution(* com.xyz..service.*.*(..))")
-		fun businessService() {}
-
-		/**
-		 * A data access operation is the execution of any method defined on a
-		 * DAO interface. This definition assumes that interfaces are placed in the
-		 * "dao" package, and that implementation types are in sub-packages.
-		 */
-		@Pointcut("execution(* com.xyz.dao.*.*(..))")
-		fun dataAccessOperation() {}
-
-	}
----
-======
-
-You can refer to the pointcuts defined in such a class anywhere you need a pointcut
-expression by referencing the fully-qualified name of the class combined with the
-`@Pointcut` method's name. For example, to make the service layer transactional, you
-could write the following which references the
-`com.xyz.CommonPointcuts.businessService()` _named pointcut_:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:config>
-		<aop:advisor
-			pointcut="com.xyz.CommonPointcuts.businessService()"
-			advice-ref="tx-advice"/>
-	</aop:config>
-
-	<tx:advice id="tx-advice">
-		<tx:attributes>
-			<tx:method name="*" propagation="REQUIRED"/>
-		</tx:attributes>
-	</tx:advice>
----
-
-The `<aop:config>` and `<aop:advisor>` elements are discussed in xref:core/aop/schema.adoc[Schema-based AOP Support]. The
-transaction elements are discussed in xref:data-access/transaction.adoc[Transaction Management].
-
-
-[[aop-pointcuts-examples]]
-== Examples
-
-Spring AOP users are likely to use the `execution` pointcut designator the most often.
-The format of an execution expression follows:
-
-[literal,indent=0,subs="verbatim"]
----
-	execution(modifiers-pattern?
-				ret-type-pattern
-				declaring-type-pattern?name-pattern(param-pattern)
-				throws-pattern?)
----
-
-All parts except the returning type pattern (`ret-type-pattern` in the preceding snippet),
-the name pattern, and the parameters pattern are optional. The returning type pattern determines
-what the return type of the method must be in order for a join point to be matched.
-`{asterisk}` is most frequently used as the returning type pattern. It matches any return
-type. A fully-qualified type name matches only when the method returns the given
-type. The name pattern matches the method name. You can use the `{asterisk}` wildcard as all or
-part of a name pattern. If you specify a declaring type pattern,
-include a trailing `.` to join it to the name pattern component.
-The parameters pattern is slightly more complex: `()` matches a
-method that takes no parameters, whereas `(..)` matches any number (zero or more) of parameters.
-The `({asterisk})` pattern matches a method that takes one parameter of any type.
-`(*,String)` matches a method that takes two parameters. The first can be of any type, while the
-second must be a `String`. Consult the
-{aspectj-docs-progguide}/semantics-pointcuts.html[Language
-Semantics] section of the AspectJ Programming Guide for more information.
-
-The following examples show some common pointcut expressions:
-
-* The execution of any public method:
-+
-[literal,indent=0,subs="verbatim"]
----
-	execution(public * *(..))
----
-
-* The execution of any method with a name that begins with `set`:
-+
-[literal,indent=0,subs="verbatim"]
----
-	execution(* set*(..))
----
-
-* The execution of any method defined by the `AccountService` interface:
-+
-[literal,indent=0,subs="verbatim"]
----
-	execution(* com.xyz.service.AccountService.*(..))
----
-
-* The execution of any method defined in the `service` package:
-+
-[literal,indent=0,subs="verbatim"]
----
-	execution(* com.xyz.service.*.*(..))
----
-
-* The execution of any method defined in the service package or one of its sub-packages:
-+
-[literal,indent=0,subs="verbatim"]
----
-	execution(* com.xyz.service..*.*(..))
----
-
-* Any join point (method execution only in Spring AOP) within the service package:
-+
-[literal,indent=0,subs="verbatim"]
----
-	within(com.xyz.service.*)
----
-
-* Any join point (method execution only in Spring AOP) within the service package or one of its
-sub-packages:
-+
-[literal,indent=0,subs="verbatim"]
----
-	within(com.xyz.service..*)
----
-
-* Any join point (method execution only in Spring AOP) where the proxy implements the
-`AccountService` interface:
-+
-[literal,indent=0,subs="verbatim"]
----
-	this(com.xyz.service.AccountService)
----
-+
-NOTE: `this` is more commonly used in a binding form. See the section on xref:core/aop/ataspectj/advice.adoc[Declaring Advice]
-for how to make the proxy object available in the advice body.
-
-* Any join point (method execution only in Spring AOP) where the target object
-implements the `AccountService` interface:
-+
-[literal,indent=0,subs="verbatim"]
----
-	target(com.xyz.service.AccountService)
----
-+
-NOTE: `target` is more commonly used in a binding form. See the xref:core/aop/ataspectj/advice.adoc[Declaring Advice] section
-for how to make the target object available in the advice body.
-
-* Any join point (method execution only in Spring AOP) that takes a single parameter
-and where the argument passed at runtime is `Serializable`:
-+
-[literal,indent=0,subs="verbatim"]
----
-	args(java.io.Serializable)
----
-+
-NOTE: `args` is more commonly used in a binding form. See the xref:core/aop/ataspectj/advice.adoc[Declaring Advice] section
-for how to make the method arguments available in the advice body.
-+
-Note that the pointcut given in this example is different from `execution(*
-*(java.io.Serializable))`. The args version matches if the argument passed at runtime is
-`Serializable`, and the execution version matches if the method signature declares a single
-parameter of type `Serializable`.
-
-* Any join point (method execution only in Spring AOP) where the target object has a
-`@Transactional` annotation:
-+
-[literal,indent=0,subs="verbatim"]
----
-	@target(org.springframework.transaction.annotation.Transactional)
----
-+
-NOTE: You can also use `@target` in a binding form. See the xref:core/aop/ataspectj/advice.adoc[Declaring Advice] section for
-how to make the annotation object available in the advice body.
-
-* Any join point (method execution only in Spring AOP) where the declared type of the
-target object has an `@Transactional` annotation:
-+
-[literal,indent=0,subs="verbatim"]
----
-	@within(org.springframework.transaction.annotation.Transactional)
----
-+
-NOTE: You can also use `@within` in a binding form. See the xref:core/aop/ataspectj/advice.adoc[Declaring Advice] section for
-how to make the annotation object available in the advice body.
-
-* Any join point (method execution only in Spring AOP) where the executing method has an
-`@Transactional` annotation:
-+
-[literal,indent=0,subs="verbatim"]
----
-	@annotation(org.springframework.transaction.annotation.Transactional)
----
-+
-NOTE: You can also use `@annotation` in a binding form. See the xref:core/aop/ataspectj/advice.adoc[Declaring Advice] section
-for how to make the annotation object available in the advice body.
-
-* Any join point (method execution only in Spring AOP) which takes a single parameter,
-and where the runtime type of the argument passed has the `@Classified` annotation:
-+
-[literal,indent=0,subs="verbatim"]
----
-	@args(com.xyz.security.Classified)
----
-+
-NOTE: You can also use `@args` in a binding form. See the xref:core/aop/ataspectj/advice.adoc[Declaring Advice] section
-how to make the annotation object(s) available in the advice body.
-
-* Any join point (method execution only in Spring AOP) on a Spring bean named
-`tradeService`:
-+
-[literal,indent=0,subs="verbatim"]
----
-	bean(tradeService)
----
-
-* Any join point (method execution only in Spring AOP) on Spring beans having names that
-match the wildcard expression `*Service`:
-+
-[literal,indent=0,subs="verbatim"]
----
-	bean(*Service)
----
-
-
-[[writing-good-pointcuts]]
-== Writing Good Pointcuts
-
-During compilation, AspectJ processes pointcuts in order to optimize matching
-performance. Examining code and determining if each join point matches (statically or
-dynamically) a given pointcut is a costly process. (A dynamic match means the match
-cannot be fully determined from static analysis and that a test is placed in the code to
-determine if there is an actual match when the code is running). On first encountering a
-pointcut declaration, AspectJ rewrites it into an optimal form for the matching
-process. What does this mean? Basically, pointcuts are rewritten in DNF (Disjunctive
-Normal Form) and the components of the pointcut are sorted such that those components
-that are cheaper to evaluate are checked first. This means you do not have to worry
-about understanding the performance of various pointcut designators and may supply them
-in any order in a pointcut declaration.
-
-However, AspectJ can work only with what it is told. For optimal performance of
-matching, you should think about what you are trying to achieve and narrow the search
-space for matches as much as possible in the definition. The existing designators
-naturally fall into one of three groups: kinded, scoping, and contextual:
-
-* Kinded designators select a particular kind of join point:
-`execution`, `get`, `set`, `call`, and `handler`.
-* Scoping designators select a group of join points of interest
-(probably of many kinds): `within` and `withincode`
-* Contextual designators match (and optionally bind) based on context:
-`this`, `target`, and `@annotation`
-
-A well written pointcut should include at least the first two types (kinded and
-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 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.
-
-
-
@@ -1,113 +0,0 @@
-[[aop-choosing]]
-= Choosing which AOP Declaration Style to Use
-
-Once you have decided that an aspect is the best approach for implementing a given
-requirement, how do you decide between using Spring AOP or AspectJ and between the
-Aspect language (code) style, the @AspectJ annotation style, or the Spring XML style? These
-decisions are influenced by a number of factors including application requirements,
-development tools, and team familiarity with AOP.
-
-
-
-[[aop-spring-or-aspectj]]
-== Spring AOP or Full AspectJ?
-
-Use the simplest thing that can work. Spring AOP is simpler than using full AspectJ, as
-there is no requirement to introduce the AspectJ compiler / weaver into your development
-and build processes. If you only need to advise the execution of operations on Spring
-beans, Spring AOP is the right choice. If you need to advise objects not managed by
-the Spring container (such as domain objects, typically), you need to use
-AspectJ. You also need to use AspectJ if you wish to advise join points other than
-simple method executions (for example, field get or set join points and so on).
-
-When you use AspectJ, you have the choice of the AspectJ language syntax (also known as
-the "code style") or the @AspectJ annotation style. If aspects play a large
-role in your design, and you are able to use the https://www.eclipse.org/ajdt/[AspectJ
-Development Tools (AJDT)] plugin for Eclipse, the AspectJ language syntax is the
-preferred option. It is cleaner and simpler because the language was purposefully
-designed for writing aspects. If you do not use Eclipse or have only a few aspects
-that do not play a major role in your application, you may want to consider using
-the @AspectJ style, sticking with regular Java compilation in your IDE, and adding
-an aspect weaving phase to your build script.
-
-
-
-[[aop-ataspectj-or-xml]]
-== @AspectJ or XML for Spring AOP?
-
-If you have chosen to use Spring AOP, you have a choice of @AspectJ or XML style.
-There are various tradeoffs to consider.
-
-The XML style may be most familiar to existing Spring users, and it is backed by genuine
-POJOs. When using AOP as a tool to configure enterprise services, XML can be a good
-choice (a good test is whether you consider the pointcut expression to be a part of your
-configuration that you might want to change independently). With the XML style, it is
-arguably clearer from your configuration which aspects are present in the system.
-
-The XML style has two disadvantages. First, it does not fully encapsulate the
-implementation of the requirement it addresses in a single place. The DRY principle says
-that there should be a single, unambiguous, authoritative representation of any piece of
-knowledge within a system. When using the XML style, the knowledge of how a requirement
-is implemented is split across the declaration of the backing bean class and the XML in
-the configuration file. When you use the @AspectJ style, this information is encapsulated
-in a single module: the aspect. Secondly, the XML style is slightly more limited in what
-it can express than the @AspectJ style: Only the "singleton" aspect instantiation model
-is supported, and it is not possible to combine named pointcuts declared in XML.
-For example, in the @AspectJ style you can write something like the following:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Pointcut("execution(* get*())")
-	public void propertyAccess() {}
-
-	@Pointcut("execution(com.xyz.Account+ *(..))")
-	public void operationReturningAnAccount() {}
-
-	@Pointcut("propertyAccess() && operationReturningAnAccount()")
-	public void accountPropertyAccess() {}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Pointcut("execution(* get*())")
-	fun propertyAccess() {}
-
-	@Pointcut("execution(com.xyz.Account+ *(..))")
-	fun operationReturningAnAccount() {}
-
-	@Pointcut("propertyAccess() && operationReturningAnAccount()")
-	fun accountPropertyAccess() {}
----
-======
-
-In the XML style you can declare the first two pointcuts:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:pointcut id="propertyAccess"
-			expression="execution(* get*())"/>
-
-	<aop:pointcut id="operationReturningAnAccount"
-			expression="execution(com.xyz.Account+ *(..))"/>
----
-
-The downside of the XML approach is that you cannot define the
-`accountPropertyAccess` pointcut by combining these definitions.
-
-The @AspectJ style supports additional instantiation models and richer pointcut
-composition. It has the advantage of keeping the aspect as a modular unit. It also has
-the advantage that the @AspectJ aspects can be understood (and thus consumed) both by
-Spring AOP and by AspectJ. So, if you later decide you need the capabilities of AspectJ
-to implement additional requirements, you can easily migrate to a classic AspectJ setup.
-In general, the Spring team prefers the @AspectJ style for custom aspects beyond simple
-configuration of enterprise services.
-
-
-
-
@@ -1,79 +0,0 @@
-[[aop-introduction-defn]]
-= AOP Concepts
-
-Let us begin by defining some central AOP concepts and terminology. These terms are not
-Spring-specific. Unfortunately, AOP terminology is not particularly intuitive.
-However, it would be even more confusing if Spring used its own terminology.
-
-* Aspect: A modularization of a concern that cuts across multiple classes.
-  Transaction management is a good example of a crosscutting concern in enterprise Java
-  applications. In Spring AOP, aspects are implemented by using regular classes
-  (the xref:core/aop/schema.adoc[schema-based approach]) or regular classes annotated with the
-  `@Aspect` annotation (the xref:core/aop/ataspectj.adoc[@AspectJ style]).
-* Join point: A point during the execution of a program, such as the execution of a
-  method or the handling of an exception. In Spring AOP, a join point always
-  represents a method execution.
-* Advice: Action taken by an aspect at a particular join point. Different types of
-  advice include "around", "before", and "after" advice. (Advice types are discussed
-  later.) Many AOP frameworks, including Spring, model an advice as an interceptor and
-  maintain a chain of interceptors around the join point.
-* Pointcut: A predicate that matches join points. Advice is associated with a
-  pointcut expression and runs at any join point matched by the pointcut (for example,
-  the execution of a method with a certain name). The concept of join points as matched
-  by pointcut expressions is central to AOP, and Spring uses the AspectJ pointcut
-  expression language by default.
-* Introduction: Declaring additional methods or fields on behalf of a type. Spring
-  AOP lets you introduce new interfaces (and a corresponding implementation) to any
-  advised object. For example, you could use an introduction to make a bean implement an
-  `IsModified` interface, to simplify caching. (An introduction is known as an
-  inter-type declaration in the AspectJ community.)
-* Target object: An object being advised by one or more aspects. Also referred to as
-  the "advised object". Since Spring AOP is implemented by using runtime proxies, this
-  object is always a proxied object.
-* AOP proxy: An object created by the AOP framework in order to implement the aspect
-  contracts (advice method executions and so on). In the Spring Framework, an AOP proxy
-  is a JDK dynamic proxy or a CGLIB proxy.
-* Weaving: linking aspects with other application types or objects to create an
-  advised object. This can be done at compile time (using the AspectJ compiler, for
-  example), load time, or at runtime. Spring AOP, like other pure Java AOP frameworks,
-  performs weaving at runtime.
-
-Spring AOP includes the following types of advice:
-
-* Before advice: Advice that runs before a join point but that does not have
-  the ability to prevent execution flow proceeding to the join point (unless it throws
-  an exception).
-* After returning advice: Advice to be run after a join point completes
-  normally (for example, if a method returns without throwing an exception).
-* After throwing advice: Advice to be run if a method exits by throwing an
-  exception.
-* After (finally) advice: Advice to be run regardless of the means by which a
-  join point exits (normal or exceptional return).
-* Around advice: Advice that surrounds a join point such as a method invocation.
-  This is the most powerful kind of advice. Around advice can perform custom behavior
-  before and after the method invocation. It is also responsible for choosing whether to
-  proceed to the join point or to shortcut the advised method execution by returning its
-  own return value or throwing an exception.
-
-Around advice is the most general kind of advice. Since Spring AOP, like AspectJ,
-provides a full range of advice types, we recommend that you use the least powerful
-advice type that can implement the required behavior. For example, if you need only to
-update a cache with the return value of a method, you are better off implementing an
-after returning advice than an around advice, although an around advice can accomplish
-the same thing. Using the most specific advice type provides a simpler programming model
-with less potential for errors. For example, you do not need to invoke the `proceed()`
-method on the `JoinPoint` used for around advice, and, hence, you cannot fail to invoke it.
-
-All advice parameters are statically typed so that you work with advice parameters of
-the appropriate type (e.g. the type of the return value from a method execution) rather
-than `Object` arrays.
-
-The concept of join points matched by pointcuts is the key to AOP, which distinguishes
-it from older technologies offering only interception. Pointcuts enable advice to be
-targeted independently of the object-oriented hierarchy. For example, you can apply an
-around advice providing declarative transaction management to a set of methods that span
-multiple objects (such as all business operations in the service layer).
-
-
-
-
@@ -1,22 +0,0 @@
-[[aop-introduction-proxies]]
-= AOP Proxies
-:page-section-summary-toc: 1
-
-Spring AOP defaults to using standard JDK dynamic proxies for AOP proxies. This
-enables any interface (or set of interfaces) to be proxied.
-
-Spring AOP can also use CGLIB proxies. This is necessary to proxy classes rather than
-interfaces. By default, CGLIB is used if a business object does not implement an
-interface. As it is good practice to program to interfaces rather than classes, business
-classes normally implement one or more business interfaces. It is possible to
-xref:core/aop/proxying.adoc[force the use of CGLIB], in those (hopefully rare) cases where you
-need to advise a method that is not declared on an interface or where you need to
-pass a proxied object to a method as a concrete type.
-
-It is important to grasp the fact that Spring AOP is proxy-based. See
-xref:core/aop/proxying.adoc#aop-understanding-aop-proxies[Understanding AOP Proxies] for a thorough examination of exactly what this
-implementation detail actually means.
-
-
-
-
@@ -1,61 +0,0 @@
-[[aop-introduction-spring-defn]]
-= Spring AOP Capabilities and Goals
-
-Spring AOP is implemented in pure Java. There is no need for a special compilation
-process. Spring AOP does not need to control the class loader hierarchy and is thus
-suitable for use in a servlet container or application server.
-
-Spring AOP currently supports only method execution join points (advising the execution
-of methods on Spring beans). Field interception is not implemented, although support for
-field interception could be added without breaking the core Spring AOP APIs. If you need
-to advise field access and update join points, consider a language such as AspectJ.
-
-Spring AOP's approach to AOP differs from that of most other AOP frameworks. The aim is
-not to provide the most complete AOP implementation (although Spring AOP is quite
-capable). Rather, the aim is to provide a close integration between AOP implementation and
-Spring IoC, to help solve common problems in enterprise applications.
-
-Thus, for example, the Spring Framework's AOP functionality is normally used in
-conjunction with the Spring IoC container. Aspects are configured by using normal bean
-definition syntax (although this allows powerful "auto-proxying" capabilities). This is a
-crucial difference from other AOP implementations. You cannot do some things
-easily or efficiently with Spring AOP, such as advise very fine-grained objects (typically,
-domain objects). AspectJ is the best choice in such cases. However, our
-experience is that Spring AOP provides an excellent solution to most problems in
-enterprise Java applications that are amenable to AOP.
-
-Spring AOP never strives to compete with AspectJ to provide a comprehensive AOP
-solution. We believe that both proxy-based frameworks such as Spring AOP and full-blown
-frameworks such as AspectJ are valuable and that they are complementary, rather than in
-competition. Spring seamlessly integrates Spring AOP and IoC with AspectJ, to enable
-all uses of AOP within a consistent Spring-based application
-architecture. This integration does not affect the Spring AOP API or the AOP Alliance
-API. Spring AOP remains backward-compatible. See xref:core/aop-api.adoc[the following chapter]
-for a discussion of the Spring AOP APIs.
-
-[NOTE]
-====
-One of the central tenets of the Spring Framework is that of non-invasiveness. This
-is the idea that you should not be forced to introduce framework-specific classes and
-interfaces into your business or domain model. However, in some places, the Spring Framework
-does give you the option to introduce Spring Framework-specific dependencies into your
-codebase. The rationale in giving you such options is because, in certain scenarios, it
-might be just plain easier to read or code some specific piece of functionality in such
-a way. However, the Spring Framework (almost) always offers you the choice: You have the
-freedom to make an informed decision as to which option best suits your particular use
-case or scenario.
-
-One such choice that is relevant to this chapter is that of which AOP framework (and
-which AOP style) to choose. You have the choice of AspectJ, Spring AOP, or both. You
-also have the choice of either the @AspectJ annotation-style approach or the Spring XML
-configuration-style approach. The fact that this chapter chooses to introduce the
-@AspectJ-style approach first should not be taken as an indication that the Spring team
-favors the @AspectJ annotation-style approach over the Spring XML configuration-style.
-
-See xref:core/aop/choosing.adoc[Choosing which AOP Declaration Style to Use] for a more complete discussion of the advantages and disadvantages of
-each style.
-====
-
-
-
-
@@ -1,12 +0,0 @@
-[[aop-mixing-styles]]
-= Mixing Aspect Types
-:page-section-summary-toc: 1
-
-It is perfectly possible to mix @AspectJ style aspects by using the auto-proxying support,
-schema-defined `<aop:aspect>` aspects, `<aop:advisor>` declared advisors, and even proxies
-and interceptors in other styles in the same configuration. All of these are implemented
-by using the same underlying support mechanism and can co-exist without any difficulty.
-
-
-
-
@@ -1,281 +0,0 @@
-[[aop-proxying]]
-= Proxying Mechanisms
-
-Spring AOP uses either JDK dynamic proxies or CGLIB to create the proxy for a given
-target object. JDK dynamic proxies are built into the JDK, whereas CGLIB is a common
-open-source class definition library (repackaged into `spring-core`).
-
-If the target object to be proxied implements at least one interface, a JDK dynamic
-proxy is used. All of the interfaces implemented by the target type are proxied.
-If the target object does not implement any interfaces, a CGLIB proxy is created.
-
-If you want to force the use of CGLIB proxying (for example, to proxy every method
-defined for the target object, not only those implemented by its interfaces),
-you can do so. However, you should consider the following issues:
-
-* With CGLIB, `final` methods cannot be advised, as they cannot be overridden in
-  runtime-generated subclasses.
-* As of Spring 4.0, the constructor of your proxied object is NOT called twice anymore,
-  since the CGLIB proxy instance is created through Objenesis. Only if your JVM does
-  not allow for constructor bypassing, you might see double invocations and
-  corresponding debug log entries from Spring's AOP support.
-
-To force the use of CGLIB proxies, set the value of the `proxy-target-class` attribute
-of the `<aop:config>` element to true, as follows:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:config proxy-target-class="true">
-		<!-- other beans defined here... -->
-	</aop:config>
----
-
-To force CGLIB proxying when you use the @AspectJ auto-proxy support, set the
-`proxy-target-class` attribute of the `<aop:aspectj-autoproxy>` element to `true`,
-as follows:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:aspectj-autoproxy proxy-target-class="true"/>
----
-
-[NOTE]
-====
-Multiple `<aop:config/>` sections are collapsed into a single unified auto-proxy creator
-at runtime, which applies the _strongest_ proxy settings that any of the
-`<aop:config/>` sections (typically from different XML bean definition files) specified.
-This also applies to the `<tx:annotation-driven/>` and `<aop:aspectj-autoproxy/>`
-elements.
-
-To be clear, using `proxy-target-class="true"` on `<tx:annotation-driven/>`,
-`<aop:aspectj-autoproxy/>`, or `<aop:config/>` elements forces the use of CGLIB
-proxies _for all three of them_.
-====
-
-
-
-[[aop-understanding-aop-proxies]]
-== Understanding AOP Proxies
-
-Spring AOP is proxy-based. It is vitally important that you grasp the semantics of
-what that last statement actually means before you write your own aspects or use any of
-the Spring AOP-based aspects supplied with the Spring Framework.
-
-Consider first the scenario where you have a plain-vanilla, un-proxied,
-nothing-special-about-it, straight object reference, as the following
-code snippet shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	public class SimplePojo implements Pojo {
-
-		public void foo() {
-			// this next method invocation is a direct call on the 'this' reference
-			this.bar();
-		}
-
-		public void bar() {
-			// some logic...
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	class SimplePojo : Pojo {
-
-		fun foo() {
-			// this next method invocation is a direct call on the 'this' reference
-			this.bar()
-		}
-
-		fun bar() {
-			// some logic...
-		}
-	}
----
-======
-
-If you invoke a method on an object reference, the method is invoked directly on
-that object reference, as the following image and listing show:
-
-image::aop-proxy-plain-pojo-call.png[]
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	public class Main {
-
-		public static void main(String[] args) {
-			Pojo pojo = new SimplePojo();
-			// this is a direct method call on the 'pojo' reference
-			pojo.foo();
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	fun main() {
-		val pojo = SimplePojo()
-		// this is a direct method call on the 'pojo' reference
-		pojo.foo()
-	}
----
-======
-
-Things change slightly when the reference that client code has is a proxy. Consider the
-following diagram and code snippet:
-
-image::aop-proxy-call.png[]
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	public class Main {
-
-		public static void main(String[] args) {
-			ProxyFactory factory = new ProxyFactory(new SimplePojo());
-			factory.addInterface(Pojo.class);
-			factory.addAdvice(new RetryAdvice());
-
-			Pojo pojo = (Pojo) factory.getProxy();
-			// this is a method call on the proxy!
-			pojo.foo();
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-fun main() {
-	val factory = ProxyFactory(SimplePojo())
-	factory.addInterface(Pojo::class.java)
-	factory.addAdvice(RetryAdvice())
-
-	val pojo = factory.proxy as Pojo
-	// this is a method call on the proxy!
-	pojo.foo()
-}
----
-======
-
-The key thing to understand here is that the client code inside the `main(..)` method
-of the `Main` class has a reference to the proxy. This means that method calls on that
-object reference are calls on the proxy. As a result, the proxy can delegate to all of
-the interceptors (advice) that are relevant to that particular method call. However,
-once the call has finally reached the target object (the `SimplePojo` reference in
-this case), any method calls that it may make on itself, such as `this.bar()` or
-`this.foo()`, are going to be invoked against the `this` reference, and not the proxy.
-This has important implications. It means that self-invocation is not going to result
-in the advice associated with a method invocation getting a chance to run.
-
-Okay, so what is to be done about this? The best approach (the term "best" is used
-loosely here) is to refactor your code such that the self-invocation does not happen.
-This does entail some work on your part, but it is the best, least-invasive approach.
-The next approach is absolutely horrendous, and we hesitate to point it out, precisely
-because it is so horrendous. You can (painful as it is to us) totally tie the logic
-within your class to Spring AOP, as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	public class SimplePojo implements Pojo {
-
-		public void foo() {
-			// this works, but... gah!
-			((Pojo) AopContext.currentProxy()).bar();
-		}
-
-		public void bar() {
-			// some logic...
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	class SimplePojo : Pojo {
-
-		fun foo() {
-			// this works, but... gah!
-			(AopContext.currentProxy() as Pojo).bar()
-		}
-
-		fun bar() {
-			// some logic...
-		}
-	}
----
-======
-
-This totally couples your code to Spring AOP, and it makes the class itself aware of
-the fact that it is being used in an AOP context, which flies in the face of AOP. It
-also requires some additional configuration when the proxy is being created, as the
-following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	public class Main {
-
-		public static void main(String[] args) {
-			ProxyFactory factory = new ProxyFactory(new SimplePojo());
-			factory.addInterface(Pojo.class);
-			factory.addAdvice(new RetryAdvice());
-			factory.setExposeProxy(true);
-
-			Pojo pojo = (Pojo) factory.getProxy();
-			// this is a method call on the proxy!
-			pojo.foo();
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	fun main() {
-		val factory = ProxyFactory(SimplePojo())
-		factory.addInterface(Pojo::class.java)
-		factory.addAdvice(RetryAdvice())
-		factory.isExposeProxy = true
-
-		val pojo = factory.proxy as Pojo
-		// this is a method call on the proxy!
-		pojo.foo()
-	}
----
-======
-
-Finally, it must be noted that AspectJ does not have this self-invocation issue because
-it is not a proxy-based AOP framework.
-
-
-
-
@@ -1,12 +0,0 @@
-[[aop-resources]]
-= Further Resources
-:page-section-summary-toc: 1
-
-More information on AspectJ can be found on the {aspectj-site}[AspectJ website].
-
-_Eclipse AspectJ_ by Adrian Colyer et. al. (Addison-Wesley, 2005) provides a
-comprehensive introduction and reference for the AspectJ language.
-
-_AspectJ in Action_, Second Edition by Ramnivas Laddad (Manning, 2009) comes highly
-recommended. The focus of the book is on AspectJ, but a lot of general AOP themes are
-explored (in some depth).
@@ -1,987 +0,0 @@
-[[aop-schema]]
-= Schema-based AOP Support
-
-If you prefer an XML-based format, Spring also offers support for defining aspects
-using the `aop` namespace tags. The exact same pointcut expressions and advice kinds
-as when using the @AspectJ style are supported. Hence, in this section we focus on
-that syntax and refer the reader to the discussion in the previous section
-(xref:core/aop/ataspectj.adoc[@AspectJ support]) for an understanding of writing pointcut expressions and the binding
-of advice parameters.
-
-To use the aop namespace tags described in this section, you need to import the
-`spring-aop` schema, as described in xref:core/appendix/xsd-schemas.adoc[XML Schema-based configuration]
-. See xref:core/appendix/xsd-schemas.adoc#aop[the AOP schema]
-for how to import the tags in the `aop` namespace.
-
-Within your Spring configurations, all aspect and advisor elements must be placed within
-an `<aop:config>` element (you can have more than one `<aop:config>` element in an
-application context configuration). An `<aop:config>` element can contain pointcut,
-advisor, and aspect elements (note that these must be declared in that order).
-
-WARNING: The `<aop:config>` style of configuration makes heavy use of Spring's
-xref:core/aop-api/autoproxy.adoc[auto-proxying] mechanism. This can cause issues (such as advice
-not being woven) if you already use explicit auto-proxying through the use of
-`BeanNameAutoProxyCreator` or something similar. The recommended usage pattern is to
-use either only the `<aop:config>` style or only the `AutoProxyCreator` style and
-never mix them.
-
-
-
-[[aop-schema-declaring-an-aspect]]
-== Declaring an Aspect
-
-When you use the schema support, an aspect is a regular Java object defined as a bean in
-your Spring application context. The state and behavior are captured in the fields and
-methods of the object, and the pointcut and advice information are captured in the XML.
-
-You can declare an aspect by using the `<aop:aspect>` element, and reference the backing bean
-by using the `ref` attribute, as the following example shows:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:config>
-		<aop:aspect id="myAspect" ref="aBean">
-			...
-		</aop:aspect>
-	</aop:config>
-
-	<bean id="aBean" class="...">
-		...
-	</bean>
----
-
-The bean that backs the aspect (`aBean` in this case) can of course be configured and
-dependency injected just like any other Spring bean.
-
-
-
-[[aop-schema-pointcuts]]
-== Declaring a Pointcut
-
-You can declare a _named pointcut_ inside an `<aop:config>` element, letting the pointcut
-definition be shared across several aspects and advisors.
-
-A pointcut that represents the execution of any business service in the service layer can
-be defined as follows:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:config>
-
-		<aop:pointcut id="businessService"
-			expression="execution(* com.xyz.service.*.*(..))" />
-
-	</aop:config>
----
-
-Note that the pointcut expression itself uses the same AspectJ pointcut expression
-language as described in xref:core/aop/ataspectj.adoc[@AspectJ support]. If you use the schema based declaration
-style, you can also refer to _named pointcuts_ defined in `@Aspect` types within the
-pointcut expression. Thus, another way of defining the above pointcut would be as follows:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:config>
-
-		<aop:pointcut id="businessService"
-			expression="com.xyz.CommonPointcuts.businessService()" /> <1>
-
-	</aop:config>
----
-<1> References the `businessService` named pointcut defined in xref:core/aop/ataspectj/pointcuts.adoc#aop-common-pointcuts[Sharing Named Pointcut Definitions].
-
-Declaring a pointcut _inside_ an aspect is very similar to declaring a top-level pointcut,
-as the following example shows:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:config>
-
-		<aop:aspect id="myAspect" ref="aBean">
-
-			<aop:pointcut id="businessService"
-				expression="execution(* com.xyz.service.*.*(..))"/>
-
-			...
-		</aop:aspect>
-
-	</aop:config>
----
-
-In much the same way as an @AspectJ aspect, pointcuts declared by using the schema based
-definition style can collect join point context. For example, the following pointcut
-collects the `this` object as the join point context and passes it to the advice:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:config>
-
-		<aop:aspect id="myAspect" ref="aBean">
-
-			<aop:pointcut id="businessService"
-				expression="execution(* com.xyz.service.*.*(..)) &amp;&amp; this(service)"/>
-
-			<aop:before pointcut-ref="businessService" method="monitor"/>
-
-			...
-		</aop:aspect>
-
-	</aop:config>
----
-
-The advice must be declared to receive the collected join point context by including
-parameters of the matching names, as follows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	public void monitor(Object service) {
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	fun monitor(service: Any) {
-		// ...
-	}
----
-======
-
-When combining pointcut sub-expressions, `+&amp;&amp;+` is awkward within an XML
-document, so you can use the `and`, `or`, and `not` keywords in place of `+&amp;&amp;+`,
-`||`, and `!`, respectively. For example, the previous pointcut can be better written as
-follows:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:config>
-
-		<aop:aspect id="myAspect" ref="aBean">
-
-			<aop:pointcut id="businessService"
-				expression="execution(* com.xyz.service.*.*(..)) and this(service)"/>
-
-			<aop:before pointcut-ref="businessService" method="monitor"/>
-
-			...
-		</aop:aspect>
-
-	</aop:config>
----
-
-Note that pointcuts defined in this way are referred to by their XML `id` and cannot be
-used as named pointcuts to form composite pointcuts. The named pointcut support in the
-schema-based definition style is thus more limited than that offered by the @AspectJ
-style.
-
-
-
-[[aop-schema-advice]]
-== Declaring Advice
-
-The schema-based AOP support uses the same five kinds of advice as the @AspectJ style, and they have
-exactly the same semantics.
-
-
-[[aop-schema-advice-before]]
-=== Before Advice
-
-Before advice runs before a matched method execution. It is declared inside an
-`<aop:aspect>` by using the `<aop:before>` element, as the following example shows:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:aspect id="beforeExample" ref="aBean">
-
-		<aop:before
-			pointcut-ref="dataAccessOperation"
-			method="doAccessCheck"/>
-
-		...
-
-	</aop:aspect>
----
-
-In the example above, `dataAccessOperation` is the `id` of a _named pointcut_ defined at
-the top (`<aop:config>`) level (see xref:core/aop/schema.adoc#aop-schema-pointcuts[Declaring a Pointcut]).
-
-NOTE: As we noted in the discussion of the @AspectJ style, using _named pointcuts_ can
-significantly improve the readability of your code. See xref:core/aop/ataspectj/pointcuts.adoc#aop-common-pointcuts[Sharing Named Pointcut Definitions] for
-details.
-
-To define the pointcut inline instead, replace the `pointcut-ref` attribute with a
-`pointcut` attribute, as follows:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:aspect id="beforeExample" ref="aBean">
-
-		<aop:before
-			pointcut="execution(* com.xyz.dao.*.*(..))"
-			method="doAccessCheck"/>
-
-		...
-
-	</aop:aspect>
----
-
-The `method` attribute identifies a method (`doAccessCheck`) that provides the body of
-the advice. This method must be defined for the bean referenced by the aspect element
-that contains the advice. Before a data access operation is performed (a method execution
-join point matched by the pointcut expression), the `doAccessCheck` method on the aspect
-bean is invoked.
-
-
-[[aop-schema-advice-after-returning]]
-=== After Returning Advice
-
-After returning advice runs when a matched method execution completes normally. It is
-declared inside an `<aop:aspect>` in the same way as before advice. The following example
-shows how to declare it:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:aspect id="afterReturningExample" ref="aBean">
-
-		<aop:after-returning
-			pointcut="execution(* com.xyz.dao.*.*(..))"
-			method="doAccessCheck"/>
-
-		...
-	</aop:aspect>
----
-
-As in the @AspectJ style, you can get the return value within the advice body.
-To do so, use the `returning` attribute to specify the name of the parameter to which
-the return value should be passed, as the following example shows:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:aspect id="afterReturningExample" ref="aBean">
-
-		<aop:after-returning
-			pointcut="execution(* com.xyz.dao.*.*(..))"
-			returning="retVal"
-			method="doAccessCheck"/>
-
-		...
-	</aop:aspect>
----
-
-The `doAccessCheck` method must declare a parameter named `retVal`. The type of this
-parameter constrains matching in the same way as described for `@AfterReturning`. For
-example, you can declare the method signature as follows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	public void doAccessCheck(Object retVal) {...
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	fun doAccessCheck(retVal: Any) {...
----
-======
-
-
-[[aop-schema-advice-after-throwing]]
-=== After Throwing Advice
-
-After throwing advice runs when a matched method execution exits by throwing an
-exception. It is declared inside an `<aop:aspect>` by using the `after-throwing` element,
-as the following example shows:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:aspect id="afterThrowingExample" ref="aBean">
-
-		<aop:after-throwing
-			pointcut="execution(* com.xyz.dao.*.*(..))"
-			method="doRecoveryActions"/>
-
-		...
-	</aop:aspect>
----
-
-As in the @AspectJ style, you can get the thrown exception within the advice body.
-To do so, use the `throwing` attribute to specify the name of the parameter to
-which the exception should be passed as the following example shows:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:aspect id="afterThrowingExample" ref="aBean">
-
-		<aop:after-throwing
-			pointcut="execution(* com.xyz.dao.*.*(..))"
-			throwing="dataAccessEx"
-			method="doRecoveryActions"/>
-
-		...
-	</aop:aspect>
----
-
-The `doRecoveryActions` method must declare a parameter named `dataAccessEx`.
-The type of this parameter constrains matching in the same way as described for
-`@AfterThrowing`. For example, the method signature may be declared as follows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	public void doRecoveryActions(DataAccessException dataAccessEx) {...
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	fun doRecoveryActions(dataAccessEx: DataAccessException) {...
----
-======
-
-
-[[aop-schema-advice-after-finally]]
-=== After (Finally) Advice
-
-After (finally) advice runs no matter how a matched method execution exits.
-You can declare it by using the `after` element, as the following example shows:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:aspect id="afterFinallyExample" ref="aBean">
-
-		<aop:after
-			pointcut="execution(* com.xyz.dao.*.*(..))"
-			method="doReleaseLock"/>
-
-		...
-	</aop:aspect>
----
-
-
-[[aop-schema-advice-around]]
-=== Around Advice
-
-The last kind of advice is _around_ advice. Around advice runs "around" a matched
-method's execution. It has the opportunity to do work both before and after the method
-runs and to determine when, how, and even if the method actually gets to run at all.
-Around advice is often used if you need to share state before and after a method
-execution in a thread-safe manner – for example, starting and stopping a timer.
-
-[TIP]
-====
-Always use the least powerful form of advice that meets your requirements.
-
-For example, do not use _around_ advice if _before_ advice is sufficient for your needs.
-====
-
-You can declare around advice by using the `aop:around` element. The advice method should
-declare `Object` as its return type, and the first parameter of the method must be of
-type `ProceedingJoinPoint`. Within the body of the advice method, you must invoke
-`proceed()` on the `ProceedingJoinPoint` in order for the underlying method to run.
-Invoking `proceed()` without arguments will result in the caller's original arguments
-being supplied to the underlying method when it is invoked. For advanced use cases, there
-is an overloaded variant of the `proceed()` method which accepts an array of arguments
-(`Object[]`). The values in the array will be used as the arguments to the underlying
-method when it is invoked. See xref:core/aop/ataspectj/advice.adoc#aop-ataspectj-around-advice[Around Advice] for notes on calling
-`proceed` with an `Object[]`.
-
-The following example shows how to declare around advice in XML:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:aspect id="aroundExample" ref="aBean">
-
-		<aop:around
-			pointcut="execution(* com.xyz.service.*.*(..))"
-			method="doBasicProfiling"/>
-
-		...
-	</aop:aspect>
----
-
-The implementation of the `doBasicProfiling` advice can be exactly the same as in the
-@AspectJ example (minus the annotation, of course), as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	public Object doBasicProfiling(ProceedingJoinPoint pjp) throws Throwable {
-		// start stopwatch
-		Object retVal = pjp.proceed();
-		// stop stopwatch
-		return retVal;
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	fun doBasicProfiling(pjp: ProceedingJoinPoint): Any? {
-		// start stopwatch
-		val retVal = pjp.proceed()
-		// stop stopwatch
-		return pjp.proceed()
-	}
----
-======
-
-
-[[aop-schema-params]]
-=== Advice Parameters
-
-The schema-based declaration style supports fully typed advice in the same way as
-described for the @AspectJ support -- by matching pointcut parameters by name against
-advice method parameters. See xref:core/aop/ataspectj/advice.adoc#aop-ataspectj-advice-params[Advice Parameters] for details. If you wish
-to explicitly specify argument names for the advice methods (not relying on the
-detection strategies previously described), you can do so by using the `arg-names`
-attribute of the advice element, which is treated in the same manner as the `argNames`
-attribute in an advice annotation (as described in xref:core/aop/ataspectj/advice.adoc#aop-ataspectj-advice-params-names[Determining Argument Names]).
-The following example shows how to specify an argument name in XML:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:before
-		pointcut="com.xyz.Pointcuts.publicMethod() and @annotation(auditable)" <1>
-		method="audit"
-		arg-names="auditable" />
----
-<1> References the `publicMethod` named pointcut defined in xref:core/aop/ataspectj/pointcuts.adoc#aop-pointcuts-combining[Combining Pointcut Expressions].
-
-The `arg-names` attribute accepts a comma-delimited list of parameter names.
-
-The following slightly more involved example of the XSD-based approach shows
-some around advice used in conjunction with a number of strongly typed parameters:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary",chomp="-packages"]
----
-	package com.xyz.service;
-
-	public interface PersonService {
-
-		Person getPerson(String personName, int age);
-	}
-
-	public class DefaultPersonService implements PersonService {
-
-		public Person getPerson(String name, int age) {
-			return new Person(name, age);
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary",chomp="-packages"]
----
-	package com.xyz.service
-
-	interface PersonService {
-
-		fun getPerson(personName: String, age: Int): Person
-	}
-
-	class DefaultPersonService : PersonService {
-
-		fun getPerson(name: String, age: Int): Person {
-			return Person(name, age)
-		}
-	}
----
-======
-
-Next up is the aspect. Notice the fact that the `profile(..)` method accepts a number of
-strongly-typed parameters, the first of which happens to be the join point used to
-proceed with the method call. The presence of this parameter is an indication that the
-`profile(..)` is to be used as `around` advice, as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary",chomp="-packages"]
----
-	package com.xyz;
-
-	import org.aspectj.lang.ProceedingJoinPoint;
-	import org.springframework.util.StopWatch;
-
-	public class SimpleProfiler {
-
-		public Object profile(ProceedingJoinPoint call, String name, int age) throws Throwable {
-			StopWatch clock = new StopWatch("Profiling for '" + name + "' and '" + age + "'");
-			try {
-				clock.start(call.toShortString());
-				return call.proceed();
-			} finally {
-				clock.stop();
-				System.out.println(clock.prettyPrint());
-			}
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary",chomp="-packages"]
----
-	package com.xyz
-
-	import org.aspectj.lang.ProceedingJoinPoint
-	import org.springframework.util.StopWatch
-
-	class SimpleProfiler {
-
-		fun profile(call: ProceedingJoinPoint, name: String, age: Int): Any? {
-			val clock = StopWatch("Profiling for '$name' and '$age'")
-			try {
-				clock.start(call.toShortString())
-				return call.proceed()
-			} finally {
-				clock.stop()
-				println(clock.prettyPrint())
-			}
-		}
-	}
----
-======
-
-Finally, the following example XML configuration effects the execution of the
-preceding advice for a particular join point:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:aop="http://www.springframework.org/schema/aop"
-		xsi:schemaLocation="
-			http://www.springframework.org/schema/beans
-			https://www.springframework.org/schema/beans/spring-beans.xsd
-			http://www.springframework.org/schema/aop
-			https://www.springframework.org/schema/aop/spring-aop.xsd">
-
-		<!-- this is the object that will be proxied by Spring's AOP infrastructure -->
-		<bean id="personService" class="com.xyz.service.DefaultPersonService"/>
-
-		<!-- this is the actual advice itself -->
-		<bean id="profiler" class="com.xyz.SimpleProfiler"/>
-
-		<aop:config>
-			<aop:aspect ref="profiler">
-
-				<aop:pointcut id="theExecutionOfSomePersonServiceMethod"
-					expression="execution(* com.xyz.service.PersonService.getPerson(String,int))
-					and args(name, age)"/>
-
-				<aop:around pointcut-ref="theExecutionOfSomePersonServiceMethod"
-					method="profile"/>
-
-			</aop:aspect>
-		</aop:config>
-
-	</beans>
----
-
-Consider the following driver script:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	public class Boot {
-
-		public static void main(String[] args) {
-			ApplicationContext ctx = new ClassPathXmlApplicationContext("beans.xml");
-			PersonService person = ctx.getBean(PersonService.class);
-			person.getPerson("Pengo", 12);
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	fun main() {
-		val ctx = ClassPathXmlApplicationContext("beans.xml")
-		val person = ctx.getBean(PersonService.class)
-		person.getPerson("Pengo", 12)
-	}
----
-======
-
-With such a `Boot` class, we would get output similar to the following on standard output:
-
-[literal,subs="verbatim"]
----
-StopWatch 'Profiling for 'Pengo' and '12': running time (millis) = 0
-----------------------------------------
-ms     %     Task name
-----------------------------------------
-00000  ?  execution(getFoo)
----
-
-
-[[aop-ordering]]
-=== Advice Ordering
-
-When multiple pieces of advice need to run at the same join point (executing method)
-the ordering rules are as described in xref:core/aop/ataspectj/advice.adoc#aop-ataspectj-advice-ordering[Advice Ordering]. The precedence
-between aspects is determined via the `order` attribute in the `<aop:aspect>` element or
-by either adding the `@Order` annotation to the bean that backs the aspect or by having
-the bean implement the `Ordered` interface.
-
-[NOTE]
-====
-In contrast to the precedence rules for advice methods defined in the same `@Aspect`
-class, when two pieces of advice defined in the same `<aop:aspect>` element both need to
-run at the same join point, the precedence is determined by the order in which the advice
-elements are declared within the enclosing `<aop:aspect>` element, from highest to lowest
-precedence.
-
-For example, given an `around` advice and a `before` advice defined in the same
-`<aop:aspect>` element that apply to the same join point, to ensure that the `around`
-advice has higher precedence than the `before` advice, the `<aop:around>` element must be
-declared before the `<aop:before>` element.
-
-As a general rule of thumb, if you find that you have multiple pieces of advice defined
-in the same `<aop:aspect>` element that apply to the same join point, consider collapsing
-such advice methods into one advice method per join point in each `<aop:aspect>` element
-or refactor the pieces of advice into separate `<aop:aspect>` elements that you can order
-at the aspect level.
-====
-
-
-
-[[aop-schema-introductions]]
-== Introductions
-
-Introductions (known as inter-type declarations in AspectJ) let an aspect declare
-that advised objects implement a given interface and provide an implementation of
-that interface on behalf of those objects.
-
-You can make an introduction by using the `aop:declare-parents` element inside an `aop:aspect`.
-You can use the `aop:declare-parents` element to declare that matching types have a new parent (hence the name).
-For example, given an interface named `UsageTracked` and an implementation of that interface named
-`DefaultUsageTracked`, the following aspect declares that all implementors of service
-interfaces also implement the `UsageTracked` interface. (In order to expose statistics
-through JMX for example.)
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:aspect id="usageTrackerAspect" ref="usageTracking">
-
-		<aop:declare-parents
-			types-matching="com.xyz.service.*+"
-			implement-interface="com.xyz.service.tracking.UsageTracked"
-			default-impl="com.xyz.service.tracking.DefaultUsageTracked"/>
-
-		<aop:before
-			pointcut="execution(* com.xyz..service.*.*(..))
-				and this(usageTracked)"
-				method="recordUsage"/>
-
-	</aop:aspect>
----
-
-The class that backs the `usageTracking` bean would then contain the following method:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	public void recordUsage(UsageTracked usageTracked) {
-		usageTracked.incrementUseCount();
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	fun recordUsage(usageTracked: UsageTracked) {
-		usageTracked.incrementUseCount()
-	}
----
-======
-
-The interface to be implemented is determined by the `implement-interface` attribute. The
-value of the `types-matching` attribute is an AspectJ type pattern. Any bean of a
-matching type implements the `UsageTracked` interface. Note that, in the before
-advice of the preceding example, service beans can be directly used as implementations of
-the `UsageTracked` interface. To access a bean programmatically, you could write the
-following:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	UsageTracked usageTracked = context.getBean("myService", UsageTracked.class);
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	val usageTracked = context.getBean("myService", UsageTracked.class)
----
-======
-
-
-
-[[aop-schema-instantiation-models]]
-== Aspect Instantiation Models
-
-The only supported instantiation model for schema-defined aspects is the singleton
-model. Other instantiation models may be supported in future releases.
-
-
-
-[[aop-schema-advisors]]
-== Advisors
-
-The concept of "advisors" comes from the AOP support defined in Spring
-and does not have a direct equivalent in AspectJ. An advisor is like a small
-self-contained aspect that has a single piece of advice. The advice itself is
-represented by a bean and must implement one of the advice interfaces described in
-xref:core/aop-api/advice.adoc#aop-api-advice-types[Advice Types in Spring]. Advisors can take advantage of AspectJ pointcut expressions.
-
-Spring supports the advisor concept with the `<aop:advisor>` element. You most
-commonly see it used in conjunction with transactional advice, which also has its own
-namespace support in Spring. The following example shows an advisor:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:config>
-
-		<aop:pointcut id="businessService"
-			expression="execution(* com.xyz.service.*.*(..))"/>
-
-		<aop:advisor
-			pointcut-ref="businessService"
-			advice-ref="tx-advice" />
-
-	</aop:config>
-
-	<tx:advice id="tx-advice">
-		<tx:attributes>
-			<tx:method name="*" propagation="REQUIRED"/>
-		</tx:attributes>
-	</tx:advice>
----
-
-As well as the `pointcut-ref` attribute used in the preceding example, you can also use the
-`pointcut` attribute to define a pointcut expression inline.
-
-To define the precedence of an advisor so that the advice can participate in ordering,
-use the `order` attribute to define the `Ordered` value of the advisor.
-
-
-
-[[aop-schema-example]]
-== An AOP Schema Example
-
-This section shows how the concurrent locking failure retry example from
-xref:core/aop/ataspectj/example.adoc[An AOP Example] looks when rewritten with the schema support.
-
-The execution of business services can sometimes fail due to concurrency issues (for
-example, a deadlock loser). If the operation is retried, it is likely to succeed
-on the next try. For business services where it is appropriate to retry in such
-conditions (idempotent operations that do not need to go back to the user for conflict
-resolution), we want to transparently retry the operation to avoid the client seeing a
-`PessimisticLockingFailureException`. This is a requirement that clearly cuts across
-multiple services in the service layer and, hence, is ideal for implementing through an
-aspect.
-
-Because we want to retry the operation, we need to use around advice so that we can
-call `proceed` multiple times. The following listing shows the basic aspect implementation
-(which is a regular Java class that uses the schema support):
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	public class ConcurrentOperationExecutor implements Ordered {
-
-		private static final int DEFAULT_MAX_RETRIES = 2;
-
-		private int maxRetries = DEFAULT_MAX_RETRIES;
-		private int order = 1;
-
-		public void setMaxRetries(int maxRetries) {
-			this.maxRetries = maxRetries;
-		}
-
-		public int getOrder() {
-			return this.order;
-		}
-
-		public void setOrder(int order) {
-			this.order = order;
-		}
-
-		public Object doConcurrentOperation(ProceedingJoinPoint pjp) throws Throwable {
-			int numAttempts = 0;
-			PessimisticLockingFailureException lockFailureException;
-			do {
-				numAttempts++;
-				try {
-					return pjp.proceed();
-				}
-				catch(PessimisticLockingFailureException ex) {
-					lockFailureException = ex;
-				}
-			} while(numAttempts <= this.maxRetries);
-			throw lockFailureException;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	class ConcurrentOperationExecutor : Ordered {
-
-		private val DEFAULT_MAX_RETRIES = 2
-
-		private var maxRetries = DEFAULT_MAX_RETRIES
-		private var order = 1
-
-		fun setMaxRetries(maxRetries: Int) {
-			this.maxRetries = maxRetries
-		}
-
-		override fun getOrder(): Int {
-			return this.order
-		}
-
-		fun setOrder(order: Int) {
-			this.order = order
-		}
-
-		fun doConcurrentOperation(pjp: ProceedingJoinPoint): Any? {
-			var numAttempts = 0
-			var lockFailureException: PessimisticLockingFailureException
-			do {
-				numAttempts++
-				try {
-					return pjp.proceed()
-				} catch (ex: PessimisticLockingFailureException) {
-					lockFailureException = ex
-				}
-
-			} while (numAttempts <= this.maxRetries)
-			throw lockFailureException
-		}
-	}
----
-======
-
-Note that the aspect implements the `Ordered` interface so that we can set the precedence of
-the aspect higher than the transaction advice (we want a fresh transaction each time we
-retry). The `maxRetries` and `order` properties are both configured by Spring. The
-main action happens in the `doConcurrentOperation` around advice method. We try to
-proceed. If we fail with a `PessimisticLockingFailureException`, we try again,
-unless we have exhausted all of our retry attempts.
-
-NOTE: This class is identical to the one used in the @AspectJ example, but with the
-annotations removed.
-
-The corresponding Spring configuration is as follows:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:config>
-
-		<aop:aspect id="concurrentOperationRetry" ref="concurrentOperationExecutor">
-
-			<aop:pointcut id="idempotentOperation"
-				expression="execution(* com.xyz.service.*.*(..))"/>
-
-			<aop:around
-				pointcut-ref="idempotentOperation"
-				method="doConcurrentOperation"/>
-
-		</aop:aspect>
-
-	</aop:config>
-
-	<bean id="concurrentOperationExecutor"
-		class="com.xyz.service.impl.ConcurrentOperationExecutor">
-			<property name="maxRetries" value="3"/>
-			<property name="order" value="100"/>
-	</bean>
----
-
-Notice that, for the time being, we assume that all business services are idempotent. If
-this is not the case, we can refine the aspect so that it retries only genuinely
-idempotent operations, by introducing an `Idempotent` annotation and using the annotation
-to annotate the implementation of service operations, as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim",role="primary"]
----
-	@Retention(RetentionPolicy.RUNTIME)
-	// marker annotation
-	public @interface Idempotent {
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim",role="secondary"]
----
-	@Retention(AnnotationRetention.RUNTIME)
-	// marker annotation
-	annotation class Idempotent
----
-======
-
-The
-change to the aspect to retry only idempotent operations involves refining the
-pointcut expression so that only `@Idempotent` operations match, as follows:
-
-[source,xml,indent=0,subs="verbatim"]
----
-	<aop:pointcut id="idempotentOperation"
-			expression="execution(* com.xyz.service.*.*(..)) and
-			@annotation(com.xyz.service.Idempotent)"/>
----
-
-
-
-
@@ -1,7 +0,0 @@
-[[appendix]]
-= Appendix
-:page-section-summary-toc: 1
-
-
-
-
@@ -1,57 +0,0 @@
-[[application-startup-steps]]
-= Application Startup Steps
-
-This part of the appendix lists the existing `StartupSteps` that the core container is instrumented with.
-
-WARNING: The name and detailed information about each startup step is not part of the public contract and
-is subject to change; this is considered as an implementation detail of the core container and will follow
-its behavior changes.
-
-.Application startup steps defined in the core container
-|===
-| Name| Description| Tags
-
-| `spring.beans.instantiate`
-| Instantiation of a bean and its dependencies.
-| `beanName` the name of the bean, `beanType` the type required at the injection point.
-
-| `spring.beans.smart-initialize`
-| Initialization of `SmartInitializingSingleton` beans.
-| `beanName` the name of the bean.
-
-| `spring.context.annotated-bean-reader.create`
-| Creation of the `AnnotatedBeanDefinitionReader`.
-|
-
-| `spring.context.base-packages.scan`
-| Scanning of base packages.
-| `packages` array of base packages for scanning.
-
-| `spring.context.beans.post-process`
-| Beans post-processing phase.
-|
-
-| `spring.context.bean-factory.post-process`
-| Invocation of the `BeanFactoryPostProcessor` beans.
-| `postProcessor` the current post-processor.
-
-| `spring.context.beandef-registry.post-process`
-| Invocation of the `BeanDefinitionRegistryPostProcessor` beans.
-| `postProcessor` the current post-processor.
-
-| `spring.context.component-classes.register`
-| Registration of component classes through `AnnotationConfigApplicationContext#register`.
-| `classes` array of given classes for registration.
-
-| `spring.context.config-classes.enhance`
-| Enhancement of configuration classes with CGLIB proxies.
-| `classCount` count of enhanced classes.
-
-| `spring.context.config-classes.parse`
-| Configuration classes parsing phase with the `ConfigurationClassPostProcessor`.
-| `classCount` count of processed classes.
-
-| `spring.context.refresh`
-| Application context refresh phase.
-|
-|===
@@ -1,672 +0,0 @@
-[[xsd-schemas]]
-= XML Schemas
-
-This part of the appendix lists XML schemas related to the core container.
-
-
-
-[[xsd-schemas-util]]
-== The `util` Schema
-
-As the name implies, the `util` tags deal with common, utility configuration
-issues, such as configuring collections, referencing constants, and so forth.
-To use the tags in the `util` schema, you need to have the following preamble at the top
-of your Spring XML configuration file (the text in the snippet references the
-correct schema so that the tags in the `util` namespace are available to you):
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<?xml version="1.0" encoding="UTF-8"?>
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:util="http://www.springframework.org/schema/util"
-		xsi:schemaLocation="
-			http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
-			http://www.springframework.org/schema/util https://www.springframework.org/schema/util/spring-util.xsd">
-
-			<!-- bean definitions here -->
-
-	</beans>
----
-
-
-[[xsd-schemas-util-constant]]
-=== Using `<util:constant/>`
-
-Consider the following bean definition:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="..." class="...">
-		<property name="isolation">
-			<bean id="java.sql.Connection.TRANSACTION_SERIALIZABLE"
-					class="org.springframework.beans.factory.config.FieldRetrievingFactoryBean" />
-		</property>
-	</bean>
----
-
-The preceding configuration uses a Spring `FactoryBean` implementation (the
-`FieldRetrievingFactoryBean`) to set the value of the `isolation` property on a bean
-to the value of the `java.sql.Connection.TRANSACTION_SERIALIZABLE` constant. This is
-all well and good, but it is verbose and (unnecessarily) exposes Spring's internal
-plumbing to the end user.
-
-The following XML Schema-based version is more concise, clearly expresses the
-developer's intent ("`inject this constant value`"), and it reads better:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="..." class="...">
-		<property name="isolation">
-			<util:constant static-field="java.sql.Connection.TRANSACTION_SERIALIZABLE"/>
-		</property>
-	</bean>
----
-
-[[xsd-schemas-util-frfb]]
-==== Setting a Bean Property or Constructor Argument from a Field Value
-
-{spring-framework-api}/beans/factory/config/FieldRetrievingFactoryBean.html[`FieldRetrievingFactoryBean`]
-is a `FactoryBean` that retrieves a `static` or non-static field value. It is typically
-used for retrieving `public` `static` `final` constants, which may then be used to set a
-property value or constructor argument for another bean.
-
-The following example shows how a `static` field is exposed, by using the
-{spring-framework-api}/beans/factory/config/FieldRetrievingFactoryBean.html#setStaticField(java.lang.String)[`staticField`]
-property:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="myField"
-			class="org.springframework.beans.factory.config.FieldRetrievingFactoryBean">
-		<property name="staticField" value="java.sql.Connection.TRANSACTION_SERIALIZABLE"/>
-	</bean>
----
-
-There is also a convenience usage form where the `static` field is specified as the bean
-name, as the following example shows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="java.sql.Connection.TRANSACTION_SERIALIZABLE"
-			class="org.springframework.beans.factory.config.FieldRetrievingFactoryBean"/>
----
-
-This does mean that there is no longer any choice in what the bean `id` is (so any other
-bean that refers to it also has to use this longer name), but this form is very
-concise to define and very convenient to use as an inner bean since the `id` does not have
-to be specified for the bean reference, as the following example shows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="..." class="...">
-		<property name="isolation">
-			<bean id="java.sql.Connection.TRANSACTION_SERIALIZABLE"
-					class="org.springframework.beans.factory.config.FieldRetrievingFactoryBean" />
-		</property>
-	</bean>
----
-
-You can also access a non-static (instance) field of another bean, as
-described in the API documentation for the
-{spring-framework-api}/beans/factory/config/FieldRetrievingFactoryBean.html[`FieldRetrievingFactoryBean`]
-class.
-
-Injecting enumeration values into beans as either property or constructor arguments is
-easy to do in Spring. You do not actually have to do anything or know anything about
-the Spring internals (or even about classes such as the `FieldRetrievingFactoryBean`).
-The following example enumeration shows how easy injecting an enum value is:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary",chomp="-packages"]
----
-	package jakarta.persistence;
-
-	public enum PersistenceContextType {
-
-		TRANSACTION,
-		EXTENDED
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary",chomp="-packages"]
----
-	package jakarta.persistence
-
-	enum class PersistenceContextType {
-
-		TRANSACTION,
-		EXTENDED
-	}
----
-======
-
-Now consider the following setter of type `PersistenceContextType` and the corresponding bean definition:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary",chomp="-packages"]
----
-	package example;
-
-	public class Client {
-
-		private PersistenceContextType persistenceContextType;
-
-		public void setPersistenceContextType(PersistenceContextType type) {
-			this.persistenceContextType = type;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary",chomp="-packages"]
----
-	package example
-
-	class Client {
-
-		lateinit var persistenceContextType: PersistenceContextType
-	}
----
-======
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean class="example.Client">
-		<property name="persistenceContextType" value="TRANSACTION"/>
-	</bean>
----
-
-
-[[xsd-schemas-util-property-path]]
-=== Using `<util:property-path/>`
-
-Consider the following example:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- target bean to be referenced by name -->
-	<bean id="testBean" class="org.springframework.beans.TestBean" scope="prototype">
-		<property name="age" value="10"/>
-		<property name="spouse">
-			<bean class="org.springframework.beans.TestBean">
-				<property name="age" value="11"/>
-			</bean>
-		</property>
-	</bean>
-
-	<!-- results in 10, which is the value of property 'age' of bean 'testBean' -->
-	<bean id="testBean.age" class="org.springframework.beans.factory.config.PropertyPathFactoryBean"/>
----
-
-The preceding configuration uses a Spring `FactoryBean` implementation (the
-`PropertyPathFactoryBean`) to create a bean (of type `int`) called `testBean.age` that
-has a value equal to the `age` property of the `testBean` bean.
-
-Now consider the following example, which adds a `<util:property-path/>` element:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- target bean to be referenced by name -->
-	<bean id="testBean" class="org.springframework.beans.TestBean" scope="prototype">
-		<property name="age" value="10"/>
-		<property name="spouse">
-			<bean class="org.springframework.beans.TestBean">
-				<property name="age" value="11"/>
-			</bean>
-		</property>
-	</bean>
-
-	<!-- results in 10, which is the value of property 'age' of bean 'testBean' -->
-	<util:property-path id="name" path="testBean.age"/>
----
-
-The value of the `path` attribute of the `<property-path/>` element follows the form of
-`beanName.beanProperty`. In this case, it picks up the `age` property of the bean named
-`testBean`. The value of that `age` property is `10`.
-
-[[xsd-schemas-util-property-path-dependency]]
-==== Using `<util:property-path/>` to Set a Bean Property or Constructor Argument
-
-`PropertyPathFactoryBean` is a `FactoryBean` that evaluates a property path on a given
-target object. The target object can be specified directly or by a bean name. You can then use this
-value in another bean definition as a property value or constructor
-argument.
-
-The following example shows a path being used against another bean, by name:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- target bean to be referenced by name -->
-	<bean id="person" class="org.springframework.beans.TestBean" scope="prototype">
-		<property name="age" value="10"/>
-		<property name="spouse">
-			<bean class="org.springframework.beans.TestBean">
-				<property name="age" value="11"/>
-			</bean>
-		</property>
-	</bean>
-
-	<!-- results in 11, which is the value of property 'spouse.age' of bean 'person' -->
-	<bean id="theAge"
-			class="org.springframework.beans.factory.config.PropertyPathFactoryBean">
-		<property name="targetBeanName" value="person"/>
-		<property name="propertyPath" value="spouse.age"/>
-	</bean>
----
-
-In the following example, a path is evaluated against an inner bean:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- results in 12, which is the value of property 'age' of the inner bean -->
-	<bean id="theAge"
-			class="org.springframework.beans.factory.config.PropertyPathFactoryBean">
-		<property name="targetObject">
-			<bean class="org.springframework.beans.TestBean">
-				<property name="age" value="12"/>
-			</bean>
-		</property>
-		<property name="propertyPath" value="age"/>
-	</bean>
----
-
-There is also a shortcut form, where the bean name is the property path.
-The following example shows the shortcut form:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- results in 10, which is the value of property 'age' of bean 'person' -->
-	<bean id="person.age"
-			class="org.springframework.beans.factory.config.PropertyPathFactoryBean"/>
----
-
-This form does mean that there is no choice in the name of the bean. Any reference to it
-also has to use the same `id`, which is the path. If used as an inner
-bean, there is no need to refer to it at all, as the following example shows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="..." class="...">
-		<property name="age">
-			<bean id="person.age"
-					class="org.springframework.beans.factory.config.PropertyPathFactoryBean"/>
-		</property>
-	</bean>
----
-
-You can specifically set the result type in the actual definition. This is not necessary
-for most use cases, but it can sometimes be useful. See the javadoc for more info on
-this feature.
-
-
-[[xsd-schemas-util-properties]]
-=== Using `<util:properties/>`
-
-Consider the following example:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- creates a java.util.Properties instance with values loaded from the supplied location -->
-	<bean id="jdbcConfiguration" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
-		<property name="location" value="classpath:com/foo/jdbc-production.properties"/>
-	</bean>
----
-
-The preceding configuration uses a Spring `FactoryBean` implementation (the
-`PropertiesFactoryBean`) to instantiate a `java.util.Properties` instance with values
-loaded from the supplied xref:web/webflux-webclient/client-builder.adoc#webflux-client-builder-reactor-resources[`Resource`] location).
-
-The following example uses a `util:properties` element to make a more concise representation:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- creates a java.util.Properties instance with values loaded from the supplied location -->
-	<util:properties id="jdbcConfiguration" location="classpath:com/foo/jdbc-production.properties"/>
----
-
-
-[[xsd-schemas-util-list]]
-=== Using `<util:list/>`
-
-Consider the following example:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- creates a java.util.List instance with values loaded from the supplied 'sourceList' -->
-	<bean id="emails" class="org.springframework.beans.factory.config.ListFactoryBean">
-		<property name="sourceList">
-			<list>
-				<value>pechorin@hero.org</value>
-				<value>raskolnikov@slums.org</value>
-				<value>stavrogin@gov.org</value>
-				<value>porfiry@gov.org</value>
-			</list>
-		</property>
-	</bean>
----
-
-The preceding configuration uses a Spring `FactoryBean` implementation (the
-`ListFactoryBean`) to create a `java.util.List` instance and initialize it with values taken
-from the supplied `sourceList`.
-
-The following example uses a `<util:list/>` element to make a more concise representation:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- creates a java.util.List instance with the supplied values -->
-	<util:list id="emails">
-		<value>pechorin@hero.org</value>
-		<value>raskolnikov@slums.org</value>
-		<value>stavrogin@gov.org</value>
-		<value>porfiry@gov.org</value>
-	</util:list>
----
-
-You can also explicitly control the exact type of `List` that is instantiated and
-populated by using the `list-class` attribute on the `<util:list/>` element. For
-example, if we really need a `java.util.LinkedList` to be instantiated, we could use the
-following configuration:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<util:list id="emails" list-class="java.util.LinkedList">
-		<value>jackshaftoe@vagabond.org</value>
-		<value>eliza@thinkingmanscrumpet.org</value>
-		<value>vanhoek@pirate.org</value>
-		<value>d'Arcachon@nemesis.org</value>
-	</util:list>
----
-
-If no `list-class` attribute is supplied, the container chooses a `List` implementation.
-
-
-[[xsd-schemas-util-map]]
-=== Using `<util:map/>`
-
-Consider the following example:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- creates a java.util.Map instance with values loaded from the supplied 'sourceMap' -->
-	<bean id="emails" class="org.springframework.beans.factory.config.MapFactoryBean">
-		<property name="sourceMap">
-			<map>
-				<entry key="pechorin" value="pechorin@hero.org"/>
-				<entry key="raskolnikov" value="raskolnikov@slums.org"/>
-				<entry key="stavrogin" value="stavrogin@gov.org"/>
-				<entry key="porfiry" value="porfiry@gov.org"/>
-			</map>
-		</property>
-	</bean>
----
-
-The preceding configuration uses a Spring `FactoryBean` implementation (the
-`MapFactoryBean`) to create a `java.util.Map` instance initialized with key-value pairs
-taken from the supplied `'sourceMap'`.
-
-The following example uses a `<util:map/>` element to make a more concise representation:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- creates a java.util.Map instance with the supplied key-value pairs -->
-	<util:map id="emails">
-		<entry key="pechorin" value="pechorin@hero.org"/>
-		<entry key="raskolnikov" value="raskolnikov@slums.org"/>
-		<entry key="stavrogin" value="stavrogin@gov.org"/>
-		<entry key="porfiry" value="porfiry@gov.org"/>
-	</util:map>
----
-
-You can also explicitly control the exact type of `Map` that is instantiated and
-populated by using the `'map-class'` attribute on the `<util:map/>` element. For
-example, if we really need a `java.util.TreeMap` to be instantiated, we could use the
-following configuration:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<util:map id="emails" map-class="java.util.TreeMap">
-		<entry key="pechorin" value="pechorin@hero.org"/>
-		<entry key="raskolnikov" value="raskolnikov@slums.org"/>
-		<entry key="stavrogin" value="stavrogin@gov.org"/>
-		<entry key="porfiry" value="porfiry@gov.org"/>
-	</util:map>
----
-
-If no `'map-class'` attribute is supplied, the container chooses a `Map` implementation.
-
-
-[[xsd-schemas-util-set]]
-=== Using `<util:set/>`
-
-Consider the following example:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- creates a java.util.Set instance with values loaded from the supplied 'sourceSet' -->
-	<bean id="emails" class="org.springframework.beans.factory.config.SetFactoryBean">
-		<property name="sourceSet">
-			<set>
-				<value>pechorin@hero.org</value>
-				<value>raskolnikov@slums.org</value>
-				<value>stavrogin@gov.org</value>
-				<value>porfiry@gov.org</value>
-			</set>
-		</property>
-	</bean>
----
-
-The preceding configuration uses a Spring `FactoryBean` implementation (the
-`SetFactoryBean`) to create a `java.util.Set` instance initialized with values taken
-from the supplied `sourceSet`.
-
-The following example uses a `<util:set/>` element to make a more concise representation:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- creates a java.util.Set instance with the supplied values -->
-	<util:set id="emails">
-		<value>pechorin@hero.org</value>
-		<value>raskolnikov@slums.org</value>
-		<value>stavrogin@gov.org</value>
-		<value>porfiry@gov.org</value>
-	</util:set>
----
-
-You can also explicitly control the exact type of `Set` that is instantiated and
-populated by using the `set-class` attribute on the `<util:set/>` element. For
-example, if we really need a `java.util.TreeSet` to be instantiated, we could use the
-following configuration:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<util:set id="emails" set-class="java.util.TreeSet">
-		<value>pechorin@hero.org</value>
-		<value>raskolnikov@slums.org</value>
-		<value>stavrogin@gov.org</value>
-		<value>porfiry@gov.org</value>
-	</util:set>
----
-
-If no `set-class` attribute is supplied, the container chooses a `Set` implementation.
-
-
-
-[[xsd-schemas-aop]]
-== The `aop` Schema
-
-The `aop` tags deal with configuring all things AOP in Spring, including Spring's
-own proxy-based AOP framework and Spring's integration with the AspectJ AOP framework.
-These tags are comprehensively covered in the chapter entitled xref:core/aop.adoc[Aspect Oriented Programming with Spring]
-.
-
-In the interest of completeness, to use the tags in the `aop` schema, you need to have
-the following preamble at the top of your Spring XML configuration file (the text in the
-snippet references the correct schema so that the tags in the `aop` namespace
-are available to you):
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<?xml version="1.0" encoding="UTF-8"?>
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:aop="http://www.springframework.org/schema/aop"
-		xsi:schemaLocation="
-			http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
-			http://www.springframework.org/schema/aop https://www.springframework.org/schema/aop/spring-aop.xsd">
-
-		<!-- bean definitions here -->
-
-	</beans>
----
-
-
-
-[[xsd-schemas-context]]
-== The `context` Schema
-
-The `context` tags deal with `ApplicationContext` configuration that relates to plumbing
-- that is, not usually beans that are important to an end-user but rather beans that do
-a lot of the "`grunt`" work in Spring, such as `BeanfactoryPostProcessors`. The following
-snippet references the correct schema so that the elements in the `context` namespace are
-available to you:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<?xml version="1.0" encoding="UTF-8"?>
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:context="http://www.springframework.org/schema/context"
-		xsi:schemaLocation="
-			http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
-			http://www.springframework.org/schema/context https://www.springframework.org/schema/context/spring-context.xsd">
-
-		<!-- bean definitions here -->
-
-	</beans>
----
-
-
-[[xsd-schemas-context-pphc]]
-=== Using `<property-placeholder/>`
-
-This element activates the replacement of `${...}` placeholders, which are resolved against a
-specified properties file (as a xref:web/webflux-webclient/client-builder.adoc#webflux-client-builder-reactor-resources[Spring resource location]). This element
-is a convenience mechanism that sets up a xref:core/beans/factory-extension.adoc#beans-factory-placeholderconfigurer[`PropertySourcesPlaceholderConfigurer`]
- for you. If you need more control over the specific
-`PropertySourcesPlaceholderConfigurer` setup, you can explicitly define it as a bean yourself.
-
-[WARNING]
-=====
-Only one such element should be defined for a given application with the properties
-that it needs. Several property placeholders can be configured as long as they have distinct
-placeholder syntax (`${...}`).
-
-If you need to modularize the source of properties used for the replacement, you should
-not create multiple properties placeholders. Rather, each module should contribute a
-`PropertySource` to the `Environment`. Alternatively, you can create your own
-`PropertySourcesPlaceholderConfigurer` bean that gathers the properties to use.
-=====
-
-[[xsd-schemas-context-ac]]
-=== Using `<annotation-config/>`
-
-This element activates the Spring infrastructure to detect annotations in bean classes:
-
-* Spring's xref:core/beans/basics.adoc#beans-factory-metadata[`@Configuration`] model
-* xref:core/beans/annotation-config.adoc[`@Autowired`/`@Inject`], `@Value`, and `@Lookup`
-* JSR-250's `@Resource`, `@PostConstruct`, and `@PreDestroy` (if available)
-* JAX-WS's `@WebServiceRef` and EJB 3's `@EJB` (if available)
-* JPA's `@PersistenceContext` and `@PersistenceUnit` (if available)
-* Spring's xref:core/beans/context-introduction.adoc#context-functionality-events-annotation[`@EventListener`]
-
-Alternatively, you can choose to explicitly activate the individual `BeanPostProcessors`
-for those annotations.
-
-NOTE: This element does not activate processing of Spring's
-xref:data-access/transaction/declarative/annotations.adoc[`@Transactional`] annotation;
-you can use the <<data-access.adoc#tx-decl-explained, `<tx:annotation-driven/>`>>
-element for that purpose. Similarly, Spring's
-xref:integration/cache/annotations.adoc[caching annotations] need to be explicitly
-xref:integration/cache/annotations.adoc#cache-annotation-enable[enabled] as well.
-
-
-[[xsd-schemas-context-component-scan]]
-=== Using `<component-scan/>`
-
-This element is detailed in the section on xref:core/beans/annotation-config.adoc[annotation-based container configuration]
-.
-
-
-[[xsd-schemas-context-ltw]]
-=== Using `<load-time-weaver/>`
-
-This element is detailed in the section on xref:core/aop/using-aspectj.adoc#aop-aj-ltw[load-time weaving with AspectJ in the Spring Framework]
-.
-
-
-[[xsd-schemas-context-sc]]
-=== Using `<spring-configured/>`
-
-This element is detailed in the section on xref:core/aop/using-aspectj.adoc#aop-atconfigurable[using AspectJ to dependency inject domain objects with Spring]
-.
-
-
-[[xsd-schemas-context-mbe]]
-=== Using `<mbean-export/>`
-
-This element is detailed in the section on xref:integration/jmx/naming.adoc#jmx-context-mbeanexport[configuring annotation-based MBean export]
-.
-
-
-
-[[xsd-schemas-beans]]
-== The Beans Schema
-
-Last but not least, we have the elements in the `beans` schema. These elements
-have been in Spring since the very dawn of the framework. Examples of the various elements
-in the `beans` schema are not shown here because they are quite comprehensively covered
-in xref:core/beans/dependencies/factory-properties-detailed.adoc[dependencies and configuration in detail]
-(and, indeed, in that entire xref:web/webmvc-view/mvc-xslt.adoc#mvc-view-xslt-beandefs[chapter]).
-
-Note that you can add zero or more key-value pairs to `<bean/>` XML definitions.
-What, if anything, is done with this extra metadata is totally up to your own custom
-logic (and so is typically only of use if you write your own custom elements as described
-in the appendix entitled xref:core/appendix/xml-custom.adoc[XML Schema Authoring]).
-
-The following example shows the `<meta/>` element in the context of a surrounding `<bean/>`
-(note that, without any logic to interpret it, the metadata is effectively useless
-as it stands).
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<?xml version="1.0" encoding="UTF-8"?>
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xsi:schemaLocation="
-			http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd">
-
-		<bean id="foo" class="x.y.Foo">
-			<meta key="cacheName" value="foo"/> <1>
-			<property name="name" value="Rick"/>
-		</bean>
-
-	</beans>
----
-<1> This is the example `meta` element
-
-In the case of the preceding example, you could assume that there is some logic that consumes
-the bean definition and sets up some caching infrastructure that uses the supplied metadata.
-
-
-
-
@@ -1,9 +0,0 @@
-[[beans]]
-= The IoC Container
-:page-section-summary-toc: 1
-
-This chapter covers Spring's Inversion of Control (IoC) container.
-
-
-
-
@@ -1,81 +0,0 @@
-[[beans-annotation-config]]
-= Annotation-based Container Configuration
-
-.Are annotations better than XML for configuring Spring?
-****
-The introduction of annotation-based configuration raised the question of whether this
-approach is "`better`" than XML. The short answer is "`it depends.`" The long answer is
-that each approach has its pros and cons, and, usually, it is up to the developer to
-decide which strategy suits them better. Due to the way they are defined, annotations
-provide a lot of context in their declaration, leading to shorter and more concise
-configuration. However, XML excels at wiring up components without touching their source
-code or recompiling them. Some developers prefer having the wiring close to the source
-while others argue that annotated classes are no longer POJOs and, furthermore, that the
-configuration becomes decentralized and harder to control.
-
-No matter the choice, Spring can accommodate both styles and even mix them together.
-It is worth pointing out that through its xref:core/beans/java.adoc[JavaConfig] option, Spring lets
-annotations be used in a non-invasive way, without touching the target components'
-source code and that, in terms of tooling, all configuration styles are supported by
-{spring-site-tools}[Spring Tools] for Eclipse, Visual Studio Code, and Theia.
-****
-
-An alternative to XML setup is provided by annotation-based configuration, which relies
-on bytecode metadata for wiring up components instead of XML declarations. Instead of
-using XML to describe a bean wiring, the developer moves the configuration into the
-component class itself by using annotations on the relevant class, method, or field
-declaration. As mentioned in xref:core/beans/factory-extension.adoc#beans-factory-extension-bpp-examples-aabpp[Example: The `AutowiredAnnotationBeanPostProcessor`], using a
-`BeanPostProcessor` in conjunction with annotations is a common means of extending the
-Spring IoC container. For example, the xref:core/beans/annotation-config/autowired.adoc[`@Autowired`]
-annotation provides the same capabilities as described in xref:core/beans/dependencies/factory-autowire.adoc[Autowiring Collaborators] but
-with more fine-grained control and wider applicability. In addition, Spring provides
-support for JSR-250 annotations, such as `@PostConstruct` and `@PreDestroy`, as well as
-support for JSR-330 (Dependency Injection for Java) annotations contained in the
-`jakarta.inject` package such as `@Inject` and `@Named`. Details about those annotations
-can be found in the xref:core/beans/standard-annotations.adoc[relevant section].
-
-[NOTE]
-====
-Annotation injection is performed before XML injection. Thus, the XML configuration
-overrides the annotations for properties wired through both approaches.
-====
-
-As always, you can register the post-processors as individual bean definitions, but they
-can also be implicitly registered by including the following tag in an XML-based Spring
-configuration (notice the inclusion of the `context` namespace):
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<?xml version="1.0" encoding="UTF-8"?>
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:context="http://www.springframework.org/schema/context"
-		xsi:schemaLocation="http://www.springframework.org/schema/beans
-			https://www.springframework.org/schema/beans/spring-beans.xsd
-			http://www.springframework.org/schema/context
-			https://www.springframework.org/schema/context/spring-context.xsd">
-
-		<context:annotation-config/>
-
-	</beans>
----
-
-The `<context:annotation-config/>` element implicitly registers the following post-processors:
-
-* {spring-framework-api}/context/annotation/ConfigurationClassPostProcessor.html[`ConfigurationClassPostProcessor`]
-* {spring-framework-api}/beans/factory/annotation/AutowiredAnnotationBeanPostProcessor.html[`AutowiredAnnotationBeanPostProcessor`]
-* {spring-framework-api}/context/annotation/CommonAnnotationBeanPostProcessor.html[`CommonAnnotationBeanPostProcessor`]
-* {spring-framework-api}/orm/jpa/support/PersistenceAnnotationBeanPostProcessor.html[`PersistenceAnnotationBeanPostProcessor`]
-* {spring-framework-api}/context/event/EventListenerMethodProcessor.html[`EventListenerMethodProcessor`]
-
-[NOTE]
-====
-`<context:annotation-config/>` only looks for annotations on beans in the same
-application context in which it is defined. This means that, if you put
-`<context:annotation-config/>` in a `WebApplicationContext` for a `DispatcherServlet`,
-it only checks for `@Autowired` beans in your controllers, and not your services. See
-xref:web/webmvc/mvc-servlet.adoc[The DispatcherServlet] for more information.
-====
-
-
-
@@ -1,114 +0,0 @@
-[[beans-autowired-annotation-primary]]
-= Fine-tuning Annotation-based Autowiring with `@Primary`
-
-Because autowiring by type may lead to multiple candidates, it is often necessary to have
-more control over the selection process. One way to accomplish this is with Spring's
-`@Primary` annotation. `@Primary` indicates that a particular bean should be given
-preference when multiple beans are candidates to be autowired to a single-valued
-dependency. If exactly one primary bean exists among the candidates, it becomes the
-autowired value.
-
-Consider the following configuration that defines `firstMovieCatalog` as the
-primary `MovieCatalog`:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	@Configuration
-	public class MovieConfiguration {
-
-		@Bean
-		@Primary
-		public MovieCatalog firstMovieCatalog() { ... }
-
-		@Bean
-		public MovieCatalog secondMovieCatalog() { ... }
-
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Configuration
-	class MovieConfiguration {
-
-		@Bean
-		@Primary
-		fun firstMovieCatalog(): MovieCatalog { ... }
-
-		@Bean
-		fun secondMovieCatalog(): MovieCatalog { ... }
-
-		// ...
-	}
----
-======
-
-With the preceding configuration, the following `MovieRecommender` is autowired with the
-`firstMovieCatalog`:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class MovieRecommender {
-
-		@Autowired
-		private MovieCatalog movieCatalog;
-
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-class MovieRecommender {
-
-	@Autowired
-	private lateinit var movieCatalog: MovieCatalog
-
-	// ...
-}
----
-======
-
-The corresponding bean definitions follow:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<?xml version="1.0" encoding="UTF-8"?>
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:context="http://www.springframework.org/schema/context"
-		xsi:schemaLocation="http://www.springframework.org/schema/beans
-			https://www.springframework.org/schema/beans/spring-beans.xsd
-			http://www.springframework.org/schema/context
-			https://www.springframework.org/schema/context/spring-context.xsd">
-
-		<context:annotation-config/>
-
-		<bean class="example.SimpleMovieCatalog" primary="true">
-			<!-- inject any dependencies required by this bean -->
-		</bean>
-
-		<bean class="example.SimpleMovieCatalog">
-			<!-- inject any dependencies required by this bean -->
-		</bean>
-
-		<bean id="movieRecommender" class="example.MovieRecommender"/>
-
-	</beans>
----
-
-
-
@@ -1,587 +0,0 @@
-[[beans-autowired-annotation-qualifiers]]
-= Fine-tuning Annotation-based Autowiring with Qualifiers
-
-`@Primary` is an effective way to use autowiring by type with several instances when one
-primary candidate can be determined. When you need more control over the selection process,
-you can use Spring's `@Qualifier` annotation. You can associate qualifier values
-with specific arguments, narrowing the set of type matches so that a specific bean is
-chosen for each argument. In the simplest case, this can be a plain descriptive value, as
-shown in the following example:
-
--
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class MovieRecommender {
-
-		@Autowired
-		@Qualifier("main")
-		private MovieCatalog movieCatalog;
-
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class MovieRecommender {
-
-		@Autowired
-		@Qualifier("main")
-		private lateinit var movieCatalog: MovieCatalog
-
-		// ...
-	}
----
-======
--
-
-You can also specify the `@Qualifier` annotation on individual constructor arguments or
-method parameters, as shown in the following example:
-
--
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class MovieRecommender {
-
-		private final MovieCatalog movieCatalog;
-
-		private final CustomerPreferenceDao customerPreferenceDao;
-
-		@Autowired
-		public void prepare(@Qualifier("main") MovieCatalog movieCatalog,
-				CustomerPreferenceDao customerPreferenceDao) {
-			this.movieCatalog = movieCatalog;
-			this.customerPreferenceDao = customerPreferenceDao;
-		}
-
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class MovieRecommender {
-
-		private lateinit var movieCatalog: MovieCatalog
-
-		private lateinit var customerPreferenceDao: CustomerPreferenceDao
-
-		@Autowired
-		fun prepare(@Qualifier("main") movieCatalog: MovieCatalog,
-					customerPreferenceDao: CustomerPreferenceDao) {
-			this.movieCatalog = movieCatalog
-			this.customerPreferenceDao = customerPreferenceDao
-		}
-
-		// ...
-	}
----
-======
--
-
-The following example shows corresponding bean definitions.
-
--
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<?xml version="1.0" encoding="UTF-8"?>
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:context="http://www.springframework.org/schema/context"
-		xsi:schemaLocation="http://www.springframework.org/schema/beans
-			https://www.springframework.org/schema/beans/spring-beans.xsd
-			http://www.springframework.org/schema/context
-			https://www.springframework.org/schema/context/spring-context.xsd">
-
-		<context:annotation-config/>
-
-		<bean class="example.SimpleMovieCatalog">
-			<qualifier value="main"/> <1>
-
-			<!-- inject any dependencies required by this bean -->
-		</bean>
-
-		<bean class="example.SimpleMovieCatalog">
-			<qualifier value="action"/> <2>
-
-			<!-- inject any dependencies required by this bean -->
-		</bean>
-
-		<bean id="movieRecommender" class="example.MovieRecommender"/>
-
-	</beans>
----
-<1> The bean with the `main` qualifier value is wired with the constructor argument that
-is qualified with the same value.
-<2> The bean with the `action` qualifier value is wired with the constructor argument that
-is qualified with the same value.
--
-
-For a fallback match, the bean name is considered a default qualifier value. Thus, you
-can define the bean with an `id` of `main` instead of the nested qualifier element, leading
-to the same matching result. However, although you can use this convention to refer to
-specific beans by name, `@Autowired` is fundamentally about type-driven injection with
-optional semantic qualifiers. This means that qualifier values, even with the bean name
-fallback, always have narrowing semantics within the set of type matches. They do not
-semantically express a reference to a unique bean `id`. Good qualifier values are `main`
-or `EMEA` or `persistent`, expressing characteristics of a specific component that are
-independent from the bean `id`, which may be auto-generated in case of an anonymous bean
-definition such as the one in the preceding example.
-
-Qualifiers also apply to typed collections, as discussed earlier -- for example, to
-`Set<MovieCatalog>`. In this case, all matching beans, according to the declared
-qualifiers, are injected as a collection. This implies that qualifiers do not have to be
-unique. Rather, they constitute filtering criteria. For example, you can define
-multiple `MovieCatalog` beans with the same qualifier value "`action`", all of which are
-injected into a `Set<MovieCatalog>` annotated with `@Qualifier("action")`.
-
-[TIP]
-====
-Letting qualifier values select against target bean names, within the type-matching
-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.
-
-Since version 6.1, this requires the `-parameters` Java compiler flag to be present.
-====
-
-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`
-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
-`@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
-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
-particular never primary. On the contrary, they always end up as lowest precedence.
-In practice, you should use self references as a last resort only (for example, for
-calling other methods on the same instance through the bean's transactional proxy).
-Consider factoring out the affected methods to a separate delegate bean in such a scenario.
-Alternatively, you can use `@Resource`, which may obtain a proxy back to the current bean
-by its unique name.
-
-[NOTE]
-====
-Trying to inject the results from `@Bean` methods on the same configuration class is
-effectively a self-reference scenario as well. Either lazily resolve such references
-in the method signature where it is actually needed (as opposed to an autowired field
-in the configuration class) or declare the affected `@Bean` methods as `static`,
-decoupling them from the containing configuration class instance and its lifecycle.
-Otherwise, such beans are only considered in the fallback phase, with matching beans
-on other configuration classes selected as primary candidates instead (if available).
-====
-
-`@Autowired` applies to fields, constructors, and multi-argument methods, allowing for
-narrowing through qualifier annotations at the parameter level. In contrast, `@Resource`
-is supported only for fields and bean property setter methods with a single argument.
-As a consequence, you should stick with qualifiers if your injection target is a
-constructor or a multi-argument method.
-
-You can create your own custom qualifier annotations. To do so, define an annotation and
-provide the `@Qualifier` annotation within your definition, as the following example shows:
-
--
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	@Target({ElementType.FIELD, ElementType.PARAMETER})
-	@Retention(RetentionPolicy.RUNTIME)
-	@Qualifier
-	public @interface Genre {
-
-		String value();
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Target(AnnotationTarget.FIELD, AnnotationTarget.VALUE_PARAMETER)
-	@Retention(AnnotationRetention.RUNTIME)
-	@Qualifier
-	annotation class Genre(val value: String)
----
-======
--
-
-Then you can provide the custom qualifier on autowired fields and parameters, as the
-following example shows:
-
--
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class MovieRecommender {
-
-		@Autowired
-		@Genre("Action")
-		private MovieCatalog actionCatalog;
-
-		private MovieCatalog comedyCatalog;
-
-		@Autowired
-		public void setComedyCatalog(@Genre("Comedy") MovieCatalog comedyCatalog) {
-			this.comedyCatalog = comedyCatalog;
-		}
-
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class MovieRecommender {
-
-		@Autowired
-		@Genre("Action")
-		private lateinit var actionCatalog: MovieCatalog
-
-		private lateinit var comedyCatalog: MovieCatalog
-
-		@Autowired
-		fun setComedyCatalog(@Genre("Comedy") comedyCatalog: MovieCatalog) {
-			this.comedyCatalog = comedyCatalog
-		}
-
-		// ...
-	}
----
-======
--
-
-Next, you can provide the information for the candidate bean definitions. You can add
-`<qualifier/>` tags as sub-elements of the `<bean/>` tag and then specify the `type` and
-`value` to match your custom qualifier annotations. The type is matched against the
-fully-qualified class name of the annotation. Alternately, as a convenience if no risk of
-conflicting names exists, you can use the short class name. The following example
-demonstrates both approaches:
-
--
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<?xml version="1.0" encoding="UTF-8"?>
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:context="http://www.springframework.org/schema/context"
-		xsi:schemaLocation="http://www.springframework.org/schema/beans
-			https://www.springframework.org/schema/beans/spring-beans.xsd
-			http://www.springframework.org/schema/context
-			https://www.springframework.org/schema/context/spring-context.xsd">
-
-		<context:annotation-config/>
-
-		<bean class="example.SimpleMovieCatalog">
-			<qualifier type="Genre" value="Action"/>
-			<!-- inject any dependencies required by this bean -->
-		</bean>
-
-		<bean class="example.SimpleMovieCatalog">
-			<qualifier type="example.Genre" value="Comedy"/>
-			<!-- inject any dependencies required by this bean -->
-		</bean>
-
-		<bean id="movieRecommender" class="example.MovieRecommender"/>
-
-	</beans>
----
--
-
-In xref:core/beans/classpath-scanning.adoc[Classpath Scanning and Managed Components], you can see an annotation-based alternative to
-providing the qualifier metadata in XML. Specifically, see xref:core/beans/classpath-scanning.adoc#beans-scanning-qualifiers[Providing Qualifier Metadata with Annotations].
-
-In some cases, using an annotation without a value may suffice. This can be
-useful when the annotation serves a more generic purpose and can be applied across
-several different types of dependencies. For example, you may provide an offline
-catalog that can be searched when no Internet connection is available. First, define
-the simple annotation, as the following example shows:
-
--
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	@Target({ElementType.FIELD, ElementType.PARAMETER})
-	@Retention(RetentionPolicy.RUNTIME)
-	@Qualifier
-	public @interface Offline {
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Target(AnnotationTarget.FIELD, AnnotationTarget.VALUE_PARAMETER)
-	@Retention(AnnotationRetention.RUNTIME)
-	@Qualifier
-	annotation class Offline
----
-======
--
-
-Then add the annotation to the field or property to be autowired, as shown in the
-following example:
-
--
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class MovieRecommender {
-
-		@Autowired
-		@Offline // <1>
-		private MovieCatalog offlineCatalog;
-
-		// ...
-	}
----
-<1> This line adds the `@Offline` annotation.
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-class MovieRecommender {
-
-	@Autowired
-	@Offline // <1>
-	private lateinit var offlineCatalog: MovieCatalog
-
-	// ...
-}
----
-<1> This line adds the `@Offline` annotation.
-======
--
-
-Now the bean definition only needs a qualifier `type`, as shown in the following example:
-
--
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean class="example.SimpleMovieCatalog">
-		<qualifier type="Offline"/> <1>
-		<!-- inject any dependencies required by this bean -->
-	</bean>
----
-<1> This element specifies the qualifier.
--
-
-
-You can also define custom qualifier annotations that accept named attributes in
-addition to or instead of the simple `value` attribute. If multiple attribute values are
-then specified on a field or parameter to be autowired, a bean definition must match
-all such attribute values to be considered an autowire candidate. As an example,
-consider the following annotation definition:
-
--
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	@Target({ElementType.FIELD, ElementType.PARAMETER})
-	@Retention(RetentionPolicy.RUNTIME)
-	@Qualifier
-	public @interface MovieQualifier {
-
-		String genre();
-
-		Format format();
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Target(AnnotationTarget.FIELD, AnnotationTarget.VALUE_PARAMETER)
-	@Retention(AnnotationRetention.RUNTIME)
-	@Qualifier
-	annotation class MovieQualifier(val genre: String, val format: Format)
----
-======
--
-
-In this case `Format` is an enum, defined as follows:
-
--
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public enum Format {
-		VHS, DVD, BLURAY
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	enum class Format {
-		VHS, DVD, BLURAY
-	}
----
-======
--
-
-The fields to be autowired are annotated with the custom qualifier and include values
-for both attributes: `genre` and `format`, as the following example shows:
-
--
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class MovieRecommender {
-
-		@Autowired
-		@MovieQualifier(format=Format.VHS, genre="Action")
-		private MovieCatalog actionVhsCatalog;
-
-		@Autowired
-		@MovieQualifier(format=Format.VHS, genre="Comedy")
-		private MovieCatalog comedyVhsCatalog;
-
-		@Autowired
-		@MovieQualifier(format=Format.DVD, genre="Action")
-		private MovieCatalog actionDvdCatalog;
-
-		@Autowired
-		@MovieQualifier(format=Format.BLURAY, genre="Comedy")
-		private MovieCatalog comedyBluRayCatalog;
-
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class MovieRecommender {
-
-		@Autowired
-		@MovieQualifier(format = Format.VHS, genre = "Action")
-		private lateinit var actionVhsCatalog: MovieCatalog
-
-		@Autowired
-		@MovieQualifier(format = Format.VHS, genre = "Comedy")
-		private lateinit var comedyVhsCatalog: MovieCatalog
-
-		@Autowired
-		@MovieQualifier(format = Format.DVD, genre = "Action")
-		private lateinit var actionDvdCatalog: MovieCatalog
-
-		@Autowired
-		@MovieQualifier(format = Format.BLURAY, genre = "Comedy")
-		private lateinit var comedyBluRayCatalog: MovieCatalog
-
-		// ...
-	}
----
-======
--
-
-Finally, the bean definitions should contain matching qualifier values. This example
-also demonstrates that you can use bean meta attributes instead of the
-`<qualifier/>` elements. If available, the `<qualifier/>` element and its attributes take
-precedence, but the autowiring mechanism falls back on the values provided within the
-`<meta/>` tags if no such qualifier is present, as in the last two bean definitions in
-the following example:
-
--
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<?xml version="1.0" encoding="UTF-8"?>
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:context="http://www.springframework.org/schema/context"
-		xsi:schemaLocation="http://www.springframework.org/schema/beans
-			https://www.springframework.org/schema/beans/spring-beans.xsd
-			http://www.springframework.org/schema/context
-			https://www.springframework.org/schema/context/spring-context.xsd">
-
-		<context:annotation-config/>
-
-		<bean class="example.SimpleMovieCatalog">
-			<qualifier type="MovieQualifier">
-				<attribute key="format" value="VHS"/>
-				<attribute key="genre" value="Action"/>
-			</qualifier>
-			<!-- inject any dependencies required by this bean -->
-		</bean>
-
-		<bean class="example.SimpleMovieCatalog">
-			<qualifier type="MovieQualifier">
-				<attribute key="format" value="VHS"/>
-				<attribute key="genre" value="Comedy"/>
-			</qualifier>
-			<!-- inject any dependencies required by this bean -->
-		</bean>
-
-		<bean class="example.SimpleMovieCatalog">
-			<meta key="format" value="DVD"/>
-			<meta key="genre" value="Action"/>
-			<!-- inject any dependencies required by this bean -->
-		</bean>
-
-		<bean class="example.SimpleMovieCatalog">
-			<meta key="format" value="BLURAY"/>
-			<meta key="genre" value="Comedy"/>
-			<!-- inject any dependencies required by this bean -->
-		</bean>
-
-	</beans>
----
--
-
-
-
@@ -1,490 +0,0 @@
-[[beans-autowired-annotation]]
-= Using `@Autowired`
-
-[NOTE]
-====
-JSR 330's `@Inject` annotation can be used in place of Spring's `@Autowired` annotation in the
-examples included in this section. See xref:core/beans/standard-annotations.adoc[here] for more details.
-====
-
-You can apply the `@Autowired` annotation to constructors, as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class MovieRecommender {
-
-		private final CustomerPreferenceDao customerPreferenceDao;
-
-		@Autowired
-		public MovieRecommender(CustomerPreferenceDao customerPreferenceDao) {
-			this.customerPreferenceDao = customerPreferenceDao;
-		}
-
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class MovieRecommender @Autowired constructor(
-		private val customerPreferenceDao: CustomerPreferenceDao)
----
-======
-
-[NOTE]
-====
-As of Spring Framework 4.3, an `@Autowired` annotation on such a constructor is no longer
-necessary if the target bean defines only one constructor to begin with. However, if
-several constructors are available and there is no primary/default constructor, at least
-one of the constructors must be annotated with `@Autowired` in order to instruct the
-container which one to use. See the discussion on
-xref:core/beans/annotation-config/autowired.adoc#beans-autowired-annotation-constructor-resolution[constructor resolution] for details.
-====
-
-You can also apply the `@Autowired` annotation to _traditional_ setter methods,
-as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class SimpleMovieLister {
-
-		private MovieFinder movieFinder;
-
-		@Autowired
-		public void setMovieFinder(MovieFinder movieFinder) {
-			this.movieFinder = movieFinder;
-		}
-
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class SimpleMovieLister {
-
-		@set:Autowired
-		lateinit var movieFinder: MovieFinder
-
-		// ...
-
-	}
----
-======
-
-You can also apply the annotation to methods with arbitrary names and multiple
-arguments, as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class MovieRecommender {
-
-		private MovieCatalog movieCatalog;
-
-		private CustomerPreferenceDao customerPreferenceDao;
-
-		@Autowired
-		public void prepare(MovieCatalog movieCatalog,
-				CustomerPreferenceDao customerPreferenceDao) {
-			this.movieCatalog = movieCatalog;
-			this.customerPreferenceDao = customerPreferenceDao;
-		}
-
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class MovieRecommender {
-
-		private lateinit var movieCatalog: MovieCatalog
-
-		private lateinit var customerPreferenceDao: CustomerPreferenceDao
-
-		@Autowired
-		fun prepare(movieCatalog: MovieCatalog,
-					customerPreferenceDao: CustomerPreferenceDao) {
-			this.movieCatalog = movieCatalog
-			this.customerPreferenceDao = customerPreferenceDao
-		}
-
-		// ...
-	}
----
-======
-
-You can apply `@Autowired` to fields as well and even mix it with constructors, as the
-following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class MovieRecommender {
-
-		private final CustomerPreferenceDao customerPreferenceDao;
-
-		@Autowired
-		private MovieCatalog movieCatalog;
-
-		@Autowired
-		public MovieRecommender(CustomerPreferenceDao customerPreferenceDao) {
-			this.customerPreferenceDao = customerPreferenceDao;
-		}
-
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class MovieRecommender @Autowired constructor(
-		private val customerPreferenceDao: CustomerPreferenceDao) {
-
-		@Autowired
-		private lateinit var movieCatalog: MovieCatalog
-
-		// ...
-	}
----
-======
-
-[TIP]
-====
-Make sure that your target components (for example, `MovieCatalog` or `CustomerPreferenceDao`)
-are consistently declared by the type that you use for your `@Autowired`-annotated
-injection points. Otherwise, injection may fail due to a "no type match found" error at runtime.
-
-For XML-defined beans or component classes found via classpath scanning, the container
-usually knows the concrete type up front. However, for `@Bean` factory methods, you need
-to make sure that the declared return type is sufficiently expressive. For components
-that implement several interfaces or for components potentially referred to by their
-implementation type, consider declaring the most specific return type on your factory
-method (at least as specific as required by the injection points referring to your bean).
-====
-
-You can also instruct Spring to provide all beans of a particular type from the
-`ApplicationContext` by adding the `@Autowired` annotation to a field or method that
-expects an array of that type, as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class MovieRecommender {
-
-		@Autowired
-		private MovieCatalog[] movieCatalogs;
-
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class MovieRecommender {
-
-		@Autowired
-		private lateinit var movieCatalogs: Array<MovieCatalog>
-
-		// ...
-	}
----
-======
-
-The same applies for typed collections, as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class MovieRecommender {
-
-		private Set<MovieCatalog> movieCatalogs;
-
-		@Autowired
-		public void setMovieCatalogs(Set<MovieCatalog> movieCatalogs) {
-			this.movieCatalogs = movieCatalogs;
-		}
-
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class MovieRecommender {
-
-		@Autowired
-		lateinit var movieCatalogs: Set<MovieCatalog>
-
-		// ...
-	}
----
-======
-
-[[beans-factory-ordered]]
-[TIP]
-====
-Your target beans can implement the `org.springframework.core.Ordered` interface or use
-the `@Order` or standard `@Priority` annotation if you want items in the array or list
-to be sorted in a specific order. Otherwise, their order follows the registration
-order of the corresponding target bean definitions in the container.
-
-You can declare the `@Order` annotation at the target class level and on `@Bean` methods,
-potentially for individual bean definitions (in case of multiple definitions that
-use the same bean class). `@Order` values may influence priorities at injection points,
-but be aware that they do not influence singleton startup order, which is an
-orthogonal concern determined by dependency relationships and `@DependsOn` declarations.
-
-Note that the standard `jakarta.annotation.Priority` annotation is not available at the
-`@Bean` level, since it cannot be declared on methods. Its semantics can be modeled
-through `@Order` values in combination with `@Primary` on a single bean for each type.
-====
-
-Even typed `Map` instances can be autowired as long as the expected key type is `String`.
-The map values contain all beans of the expected type, and the keys contain the
-corresponding bean names, as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class MovieRecommender {
-
-		private Map<String, MovieCatalog> movieCatalogs;
-
-		@Autowired
-		public void setMovieCatalogs(Map<String, MovieCatalog> movieCatalogs) {
-			this.movieCatalogs = movieCatalogs;
-		}
-
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class MovieRecommender {
-
-		@Autowired
-		lateinit var movieCatalogs: Map<String, MovieCatalog>
-
-		// ...
-	}
----
-======
-
-By default, autowiring fails when no matching candidate beans are available for a given
-injection point. In the case of a declared array, collection, or map, at least one
-matching element is expected.
-
-The default behavior is to treat annotated methods and fields as indicating required
-dependencies. You can change this behavior as demonstrated in the following example,
-enabling the framework to skip a non-satisfiable injection point through marking it as
-non-required (i.e., by setting the `required` attribute in `@Autowired` to `false`):
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class SimpleMovieLister {
-
-		private MovieFinder movieFinder;
-
-		@Autowired(required = false)
-		public void setMovieFinder(MovieFinder movieFinder) {
-			this.movieFinder = movieFinder;
-		}
-
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class SimpleMovieLister {
-
-		@Autowired(required = false)
-		var movieFinder: MovieFinder? = null
-
-		// ...
-	}
----
-======
-
-[NOTE]
-====
-A non-required method will not be called at all if its dependency (or one of its
-dependencies, in case of multiple arguments) is not available. A non-required field will
-not get populated at all in such cases, leaving its default value in place.
-
-In other words, setting the `required` attribute to `false` indicates that the
-corresponding property is _optional_ for autowiring purposes, and the property will be
-ignored if it cannot be autowired. This allows properties to be assigned default values
-that can be optionally overridden via dependency injection.
-====
-
-[[beans-autowired-annotation-constructor-resolution]]
-Injected constructor and factory method arguments are a special case since the `required`
-attribute in `@Autowired` has a somewhat different meaning due to Spring's constructor
-resolution algorithm that may potentially deal with multiple constructors. Constructor
-and factory method arguments are effectively required by default but with a few special
-rules in a single-constructor scenario, such as multi-element injection points (arrays,
-collections, maps) resolving to empty instances if no matching beans are available. This
-allows for a common implementation pattern where all dependencies can be declared in a
-unique multi-argument constructor — for example, declared as a single public constructor
-without an `@Autowired` annotation.
-
-[NOTE]
-====
-Only one constructor of any given bean class may declare `@Autowired` with the `required`
-attribute set to `true`, indicating _the_ constructor to autowire when used as a Spring
-bean. As a consequence, if the `required` attribute is left at its default value `true`,
-only a single constructor may be annotated with `@Autowired`. If multiple constructors
-declare the annotation, they will all have to declare `required=false` in order to be
-considered as candidates for autowiring (analogous to `autowire=constructor` in XML).
-The constructor with the greatest number of dependencies that can be satisfied by matching
-beans in the Spring container will be chosen. If none of the candidates can be satisfied,
-then a primary/default constructor (if present) will be used. Similarly, if a class
-declares multiple constructors but none of them is annotated with `@Autowired`, then a
-primary/default constructor (if present) will be used. If a class only declares a single
-constructor to begin with, it will always be used, even if not annotated. Note that an
-annotated constructor does not have to be public.
-====
-
-Alternatively, you can express the non-required nature of a particular dependency
-through Java 8's `java.util.Optional`, as the following example shows:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	public class SimpleMovieLister {
-
-		@Autowired
-		public void setMovieFinder(Optional<MovieFinder> movieFinder) {
-			...
-		}
-	}
----
-
-As of Spring Framework 5.0, you can also use a `@Nullable` annotation (of any kind
-in any package -- for example, `javax.annotation.Nullable` from JSR-305) or just leverage
-Kotlin built-in null-safety support:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class SimpleMovieLister {
-
-		@Autowired
-		public void setMovieFinder(@Nullable MovieFinder movieFinder) {
-			...
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class SimpleMovieLister {
-
-		@Autowired
-		var movieFinder: MovieFinder? = null
-
-		// ...
-	}
----
-======
-
-You can also use `@Autowired` for interfaces that are well-known resolvable
-dependencies: `BeanFactory`, `ApplicationContext`, `Environment`, `ResourceLoader`,
-`ApplicationEventPublisher`, and `MessageSource`. These interfaces and their extended
-interfaces, such as `ConfigurableApplicationContext` or `ResourcePatternResolver`, are
-automatically resolved, with no special setup necessary. The following example autowires
-an `ApplicationContext` object:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class MovieRecommender {
-
-		@Autowired
-		private ApplicationContext context;
-
-		public MovieRecommender() {
-		}
-
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-class MovieRecommender {
-
-	@Autowired
-	lateinit var context: ApplicationContext
-
-	// ...
-}
----
-======
-
-[NOTE]
-====
-The `@Autowired`, `@Inject`, `@Value`, and `@Resource` annotations are handled by Spring
-`BeanPostProcessor` implementations. This means that you cannot apply these annotations
-within your own `BeanPostProcessor` or `BeanFactoryPostProcessor` types (if any).
-These types must be 'wired up' explicitly by using XML or a Spring `@Bean` method.
-====
-
-
-
@@ -1,33 +0,0 @@
-[[beans-custom-autowire-configurer]]
-= Using `CustomAutowireConfigurer`
-
-{spring-framework-api}/beans/factory/annotation/CustomAutowireConfigurer.html[`CustomAutowireConfigurer`]
-is a `BeanFactoryPostProcessor` that lets you register your own custom qualifier
-annotation types, even if they are not annotated with Spring's `@Qualifier` annotation.
-The following example shows how to use `CustomAutowireConfigurer`:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="customAutowireConfigurer"
-			class="org.springframework.beans.factory.annotation.CustomAutowireConfigurer">
-		<property name="customQualifierTypes">
-			<set>
-				<value>example.CustomQualifier</value>
-			</set>
-		</property>
-	</bean>
----
-
-The `AutowireCandidateResolver` determines autowire candidates by:
-
-* The `autowire-candidate` value of each bean definition
-* Any `default-autowire-candidates` patterns available on the `<beans/>` element
-* The presence of `@Qualifier` annotations and any custom annotations registered
-with the `CustomAutowireConfigurer`
-
-When multiple beans qualify as autowire candidates, the determination of a "`primary`" is
-as follows: If exactly one bean definition among the candidates has a `primary`
-attribute set to `true`, it is selected.
-
-
-
@@ -1,101 +0,0 @@
-[[beans-generics-as-qualifiers]]
-= Using Generics as Autowiring Qualifiers
-
-In addition to the `@Qualifier` annotation, you can use Java generic types
-as an implicit form of qualification. For example, suppose you have the following
-configuration:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	@Configuration
-	public class MyConfiguration {
-
-		@Bean
-		public StringStore stringStore() {
-			return new StringStore();
-		}
-
-		@Bean
-		public IntegerStore integerStore() {
-			return new IntegerStore();
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Configuration
-	class MyConfiguration {
-
-		@Bean
-		fun stringStore() = StringStore()
-
-		@Bean
-		fun integerStore() = IntegerStore()
-	}
----
-======
-
-Assuming that the preceding beans implement a generic interface, (that is, `Store<String>` and
-`Store<Integer>`), you can `@Autowire` the `Store` interface and the generic is
-used as a qualifier, as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	@Autowired
-	private Store<String> s1; // <String> qualifier, injects the stringStore bean
-
-	@Autowired
-	private Store<Integer> s2; // <Integer> qualifier, injects the integerStore bean
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Autowired
-	private lateinit var s1: Store<String> // <String> qualifier, injects the stringStore bean
-
-	@Autowired
-	private lateinit var s2: Store<Integer> // <Integer> qualifier, injects the integerStore bean
----
-======
-
-Generic qualifiers also apply when autowiring lists, `Map` instances and arrays. The
-following example autowires a generic `List`:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	// Inject all Store beans as long as they have an <Integer> generic
-	// Store<String> beans will not appear in this list
-	@Autowired
-	private List<Store<Integer>> s;
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	// Inject all Store beans as long as they have an <Integer> generic
-	// Store<String> beans will not appear in this list
-	@Autowired
-	private lateinit var s: List<Store<Integer>>
----
-======
-
-
-
@@ -1,70 +0,0 @@
-[[beans-postconstruct-and-predestroy-annotations]]
-= Using `@PostConstruct` and `@PreDestroy`
-
-The `CommonAnnotationBeanPostProcessor` not only recognizes the `@Resource` annotation
-but also the JSR-250 lifecycle annotations: `jakarta.annotation.PostConstruct` and
-`jakarta.annotation.PreDestroy`. Introduced in Spring 2.5, the support for these
-annotations offers an alternative to the lifecycle callback mechanism described in
-xref:core/beans/factory-nature.adoc#beans-factory-lifecycle-initializingbean[initialization callbacks] and
-xref:core/beans/factory-nature.adoc#beans-factory-lifecycle-disposablebean[destruction callbacks]. Provided that the
-`CommonAnnotationBeanPostProcessor` is registered within the Spring `ApplicationContext`,
-a method carrying one of these annotations is invoked at the same point in the lifecycle
-as the corresponding Spring lifecycle interface method or explicitly declared callback
-method. In the following example, the cache is pre-populated upon initialization and
-cleared upon destruction:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class CachingMovieLister {
-
-		@PostConstruct
-		public void populateMovieCache() {
-			// populates the movie cache upon initialization...
-		}
-
-		@PreDestroy
-		public void clearMovieCache() {
-			// clears the movie cache upon destruction...
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class CachingMovieLister {
-
-		@PostConstruct
-		fun populateMovieCache() {
-			// populates the movie cache upon initialization...
-		}
-
-		@PreDestroy
-		fun clearMovieCache() {
-			// clears the movie cache upon destruction...
-		}
-	}
----
-======
-
-For details about the effects of combining various lifecycle mechanisms, see
-xref:core/beans/factory-nature.adoc#beans-factory-lifecycle-combined-effects[Combining Lifecycle Mechanisms].
-
-[NOTE]
-====
-Like `@Resource`, the `@PostConstruct` and `@PreDestroy` annotation types were a part
-of the standard Java libraries from JDK 6 to 8. However, the entire `javax.annotation`
-package got separated from the core Java modules in JDK 9 and eventually removed in
-JDK 11. As of Jakarta EE 9, the package lives in `jakarta.annotation` now. If needed,
-the `jakarta.annotation-api` artifact needs to be obtained via Maven Central now,
-simply to be added to the application's classpath like any other library.
-====
-
-
-
-
@@ -1,145 +0,0 @@
-[[beans-resource-annotation]]
-= Injection with `@Resource`
-
-Spring also supports injection by using the JSR-250 `@Resource` annotation
-(`jakarta.annotation.Resource`) on fields or bean property setter methods.
-This is a common pattern in Jakarta EE: for example, in JSF-managed beans and JAX-WS
-endpoints. Spring supports this pattern for Spring-managed objects as well.
-
-`@Resource` takes a name attribute. By default, Spring interprets that value as
-the bean name to be injected. In other words, it follows by-name semantics,
-as demonstrated in the following example:
-
--
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class SimpleMovieLister {
-
-		private MovieFinder movieFinder;
-
-		@Resource(name="myMovieFinder") // <1>
-		public void setMovieFinder(MovieFinder movieFinder) {
-			this.movieFinder = movieFinder;
-		}
-	}
----
-<1> This line injects a `@Resource`.
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-class SimpleMovieLister {
-
-	@Resource(name="myMovieFinder") // <1>
-	private lateinit var movieFinder:MovieFinder
-}
----
-<1> This line injects a `@Resource`.
-======
--
-
-
-If no name is explicitly specified, the default name is derived from the field name or
-setter method. In case of a field, it takes the field name. In case of a setter method,
-it takes the bean property name. The following example is going to have the bean
-named `movieFinder` injected into its setter method:
-
--
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class SimpleMovieLister {
-
-		private MovieFinder movieFinder;
-
-		@Resource
-		public void setMovieFinder(MovieFinder movieFinder) {
-			this.movieFinder = movieFinder;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class SimpleMovieLister {
-
-		@set:Resource
-		private lateinit var movieFinder: MovieFinder
-
-	}
----
-======
--
-
-NOTE: The name provided with the annotation is resolved as a bean name by the
-`ApplicationContext` of which the `CommonAnnotationBeanPostProcessor` is aware.
-The names can be resolved through JNDI if you configure Spring's
-{spring-framework-api}/jndi/support/SimpleJndiBeanFactory.html[`SimpleJndiBeanFactory`]
-explicitly. However, we recommend that you rely on the default behavior and
-use Spring's JNDI lookup capabilities to preserve the level of indirection.
-
-In the exclusive case of `@Resource` usage with no explicit name specified, and similar
-to `@Autowired`, `@Resource` finds a primary type match instead of a specific named bean
-and resolves well known resolvable dependencies: the `BeanFactory`,
-`ApplicationContext`, `ResourceLoader`, `ApplicationEventPublisher`, and `MessageSource`
-interfaces.
-
-Thus, in the following example, the `customerPreferenceDao` field first looks for a bean
-named "customerPreferenceDao" and then falls back to a primary type match for the type
-`CustomerPreferenceDao`:
-
--
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class MovieRecommender {
-
-		@Resource
-		private CustomerPreferenceDao customerPreferenceDao;
-
-		@Resource
-		private ApplicationContext context; // <1>
-
-		public MovieRecommender() {
-		}
-
-		// ...
-	}
----
-<1> The `context` field is injected based on the known resolvable dependency type:
-`ApplicationContext`.
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class MovieRecommender {
-
-		@Resource
-		private lateinit var customerPreferenceDao: CustomerPreferenceDao
-
-
-		@Resource
-		private lateinit var context: ApplicationContext // <1>
-
-		// ...
-	}
----
-<1> The `context` field is injected based on the known resolvable dependency type:
-`ApplicationContext`.
-======
--
-
@@ -1,242 +0,0 @@
-[[beans-value-annotations]]
-= Using `@Value`
-
-`@Value` is typically used to inject externalized properties:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-    @Component
-    public class MovieRecommender {
-
-        private final String catalog;
-
-        public MovieRecommender(@Value("${catalog.name}") String catalog) {
-            this.catalog = catalog;
-        }
-    }
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Component
-	class MovieRecommender(@Value("\${catalog.name}") private val catalog: String)
----
-======
-
-With the following configuration:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-    @Configuration
-    @PropertySource("classpath:application.properties")
-    public class AppConfig { }
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Configuration
-	@PropertySource("classpath:application.properties")
-	class AppConfig
----
-======
-
-And the following `application.properties` file:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-    catalog.name=MovieCatalog
----
-
-In that case, the `catalog` parameter and field will be equal to the `MovieCatalog` value.
-
-A default lenient embedded value resolver is provided by Spring. It will try to resolve the
-property value and if it cannot be resolved, the property name (for example `${catalog.name}`)
-will be injected as the value. If you want to maintain strict control over nonexistent
-values, you should declare a `PropertySourcesPlaceholderConfigurer` bean, as the following
-example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	@Configuration
-	public class AppConfig {
-
-		@Bean
-		public static PropertySourcesPlaceholderConfigurer propertyPlaceholderConfigurer() {
-			return new PropertySourcesPlaceholderConfigurer();
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Configuration
-	class AppConfig {
-
-		@Bean
-		fun propertyPlaceholderConfigurer() = PropertySourcesPlaceholderConfigurer()
-	}
----
-======
-
-NOTE: When configuring a `PropertySourcesPlaceholderConfigurer` using JavaConfig, the
-`@Bean` method must be `static`.
-
-Using the above configuration ensures Spring initialization failure if any `${}`
-placeholder could not be resolved. It is also possible to use methods like
-`setPlaceholderPrefix`, `setPlaceholderSuffix`, or `setValueSeparator` to customize
-placeholders.
-
-NOTE: Spring Boot configures by default a `PropertySourcesPlaceholderConfigurer` bean that
-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.
-
-It is possible to provide a default value as following:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-    @Component
-    public class MovieRecommender {
-
-        private final String catalog;
-
-        public MovieRecommender(@Value("${catalog.name:defaultCatalog}") String catalog) {
-            this.catalog = catalog;
-        }
-    }
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Component
-	class MovieRecommender(@Value("\${catalog.name:defaultCatalog}") private val catalog: String)
----
-======
-
-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:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-    @Configuration
-    public class AppConfig {
-
-        @Bean
-        public ConversionService conversionService() {
-            DefaultFormattingConversionService conversionService = new DefaultFormattingConversionService();
-            conversionService.addConverter(new MyCustomConverter());
-            return conversionService;
-        }
-    }
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Configuration
-	class AppConfig {
-
-		@Bean
-		fun conversionService(): ConversionService {
-			return DefaultFormattingConversionService().apply {
-				addConverter(MyCustomConverter())
-			}
-		}
-	}
----
-======
-
-When `@Value` contains a xref:core/expressions.adoc[`SpEL` expression] the value will be dynamically
-computed at runtime as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-    @Component
-    public class MovieRecommender {
-
-        private final String catalog;
-
-        public MovieRecommender(@Value("#{systemProperties['user.catalog'] + 'Catalog' }") String catalog) {
-            this.catalog = catalog;
-        }
-    }
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Component
-	class MovieRecommender(
-		@Value("#{systemProperties['user.catalog'] + 'Catalog' }") private val catalog: String)
----
-======
-
-SpEL also enables the use of more complex data structures:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-    @Component
-    public class MovieRecommender {
-
-        private final Map<String, Integer> countOfMoviesPerCatalog;
-
-        public MovieRecommender(
-                @Value("#{{'Thriller': 100, 'Comedy': 300}}") Map<String, Integer> countOfMoviesPerCatalog) {
-            this.countOfMoviesPerCatalog = countOfMoviesPerCatalog;
-        }
-    }
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Component
-	class MovieRecommender(
-		@Value("#{{'Thriller': 100, 'Comedy': 300}}") private val countOfMoviesPerCatalog: Map<String, Int>)
----
-======
-
-
@@ -1,423 +0,0 @@
-[[beans-basics]]
-= Container Overview
-
-The `org.springframework.context.ApplicationContext` interface represents the Spring IoC
-container and is responsible for instantiating, configuring, and assembling the
-beans. The container gets its instructions on what objects to
-instantiate, configure, and assemble by reading configuration metadata. The
-configuration metadata is represented in XML, Java annotations, or Java code. It lets
-you express the objects that compose your application and the rich interdependencies
-between those objects.
-
-Several implementations of the `ApplicationContext` interface are supplied
-with Spring. In stand-alone applications, it is common to create an
-instance of
-{spring-framework-api}/context/support/ClassPathXmlApplicationContext.html[`ClassPathXmlApplicationContext`]
-or {spring-framework-api}/context/support/FileSystemXmlApplicationContext.html[`FileSystemXmlApplicationContext`].
-While XML has been the traditional format for defining configuration metadata, you can
-instruct the container to use Java annotations or code as the metadata format by
-providing a small amount of XML configuration to declaratively enable support for these
-additional metadata formats.
-
-In most application scenarios, explicit user code is not required to instantiate one or
-more instances of a Spring IoC container. For example, in a web application scenario, a
-simple eight (or so) lines of boilerplate web descriptor XML in the `web.xml` file
-of the application typically suffices (see
-xref:core/beans/context-introduction.adoc#context-create[Convenient ApplicationContext Instantiation for Web Applications]).
-If you use the {spring-site-tools}[Spring Tools for Eclipse] (an Eclipse-powered
-development environment), you can easily create this boilerplate configuration with a
-few mouse clicks or keystrokes.
-
-The following diagram shows a high-level view of how Spring works. Your application classes
-are combined with configuration metadata so that, after the `ApplicationContext` is
-created and initialized, you have a fully configured and executable system or
-application.
-
-.The Spring IoC container
-image::container-magic.png[]
-
-
-
-[[beans-factory-metadata]]
-== Configuration Metadata
-
-As the preceding diagram shows, the Spring IoC container consumes a form of
-configuration metadata. This configuration metadata represents how you, as an
-application developer, tell the Spring container to instantiate, configure, and assemble
-the objects in your application.
-
-Configuration metadata is traditionally supplied in a simple and intuitive XML format,
-which is what most of this chapter uses to convey key concepts and features of the
-Spring IoC container.
-
-NOTE: XML-based metadata is not the only allowed form of configuration metadata.
-The Spring IoC container itself is totally decoupled from the format in which this
-configuration metadata is actually written. These days, many developers choose
-xref:core/beans/java.adoc[Java-based configuration] for their Spring applications.
-
-For information about using other forms of metadata with the Spring container, see:
-
-* xref:core/beans/annotation-config.adoc[Annotation-based configuration]: define beans using
-  annotation-based configuration metadata.
-* xref:core/beans/java.adoc[Java-based configuration]: define beans external to your application
-  classes by using Java rather than XML files. To use these features, see the
-  {spring-framework-api}/context/annotation/Configuration.html[`@Configuration`],
-  {spring-framework-api}/context/annotation/Bean.html[`@Bean`],
-  {spring-framework-api}/context/annotation/Import.html[`@Import`],
-  and {spring-framework-api}/context/annotation/DependsOn.html[`@DependsOn`] annotations.
-
-Spring configuration consists of at least one and typically more than one bean
-definition that the container must manage. XML-based configuration metadata configures these
-beans as `<bean/>` elements inside a top-level `<beans/>` element. Java
-configuration typically uses `@Bean`-annotated methods within a `@Configuration` class.
-
-These bean definitions correspond to the actual objects that make up your application.
-Typically, you define service layer objects, persistence layer objects such as
-repositories or data access objects (DAOs), presentation objects such as Web controllers,
-infrastructure objects such as a JPA `EntityManagerFactory`, JMS queues, and so forth.
-Typically, one does not configure fine-grained domain objects in the container, because
-it is usually the responsibility of repositories and business logic to create and load
-domain objects.
-
-The following example shows the basic structure of XML-based configuration metadata:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<?xml version="1.0" encoding="UTF-8"?>
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xsi:schemaLocation="http://www.springframework.org/schema/beans
-			https://www.springframework.org/schema/beans/spring-beans.xsd">
-
-		<bean id="..." class="..."> <1> <2>
-			<!-- collaborators and configuration for this bean go here -->
-		</bean>
-
-		<bean id="..." class="...">
-			<!-- collaborators and configuration for this bean go here -->
-		</bean>
-
-		<!-- more bean definitions go here -->
-
-	</beans>
----
-
-<1> The `id` attribute is a string that identifies the individual bean definition.
-<2> The `class` attribute defines the type of the bean and uses the fully qualified
-class name.
-
-The value of the `id` attribute can be used to refer to collaborating objects. The XML
-for referring to collaborating objects is not shown in this example. See
-xref:core/beans/dependencies.adoc[Dependencies] for more information.
-
-
-
-[[beans-factory-instantiation]]
-== Instantiating a Container
-
-The location path or paths
-supplied to an `ApplicationContext` constructor are resource strings that let
-the container load configuration metadata from a variety of external resources, such
-as the local file system, the Java `CLASSPATH`, and so on.
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	ApplicationContext context = new ClassPathXmlApplicationContext("services.xml", "daos.xml");
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-    val context = ClassPathXmlApplicationContext("services.xml", "daos.xml")
----
-======
-
-[NOTE]
-====
-After you learn about Spring's IoC container, you may want to know more about Spring's
-`Resource` abstraction (as described in
-xref:core/resources.adoc[Resources])
-which provides a convenient mechanism for reading an InputStream from locations defined
-in a URI syntax. In particular, `Resource` paths are used to construct applications contexts,
-as described in xref:core/resources.adoc#resources-app-ctx[Application Contexts and Resource Paths].
-====
-
-The following example shows the service layer objects `(services.xml)` configuration file:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<?xml version="1.0" encoding="UTF-8"?>
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xsi:schemaLocation="http://www.springframework.org/schema/beans
-			https://www.springframework.org/schema/beans/spring-beans.xsd">
-
-		<!-- services -->
-
-		<bean id="petStore" class="org.springframework.samples.jpetstore.services.PetStoreServiceImpl">
-			<property name="accountDao" ref="accountDao"/>
-			<property name="itemDao" ref="itemDao"/>
-			<!-- additional collaborators and configuration for this bean go here -->
-		</bean>
-
-		<!-- more bean definitions for services go here -->
-
-	</beans>
----
-
-The following example shows the data access objects `daos.xml` file:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<?xml version="1.0" encoding="UTF-8"?>
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xsi:schemaLocation="http://www.springframework.org/schema/beans
-			https://www.springframework.org/schema/beans/spring-beans.xsd">
-
-		<bean id="accountDao"
-			class="org.springframework.samples.jpetstore.dao.jpa.JpaAccountDao">
-			<!-- additional collaborators and configuration for this bean go here -->
-		</bean>
-
-		<bean id="itemDao" class="org.springframework.samples.jpetstore.dao.jpa.JpaItemDao">
-			<!-- additional collaborators and configuration for this bean go here -->
-		</bean>
-
-		<!-- more bean definitions for data access objects go here -->
-
-	</beans>
----
-
-In the preceding example, the service layer consists of the `PetStoreServiceImpl` class
-and two data access objects of the types `JpaAccountDao` and `JpaItemDao` (based
-on the JPA Object-Relational Mapping standard). The `property name` element refers to the
-name of the JavaBean property, and the `ref` element refers to the name of another bean
-definition. This linkage between `id` and `ref` elements expresses the dependency between
-collaborating objects. For details of configuring an object's dependencies, see
-xref:core/beans/dependencies.adoc[Dependencies].
-
-
-[[beans-factory-xml-import]]
-=== Composing XML-based Configuration Metadata
-
-It can be useful to have bean definitions span multiple XML files. Often, each individual
-XML configuration file represents a logical layer or module in your architecture.
-
-You can use the application context constructor to load bean definitions from all these
-XML fragments. This constructor takes multiple `Resource` locations, as was shown in the
-xref:core/beans/basics.adoc#beans-factory-instantiation[previous section]. Alternatively,
-use one or more occurrences of the `<import/>` element to load bean definitions from
-another file or files. The following example shows how to do so:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<beans>
-		<import resource="services.xml"/>
-		<import resource="resources/messageSource.xml"/>
-		<import resource="/resources/themeSource.xml"/>
-
-		<bean id="bean1" class="..."/>
-		<bean id="bean2" class="..."/>
-	</beans>
----
-
-In the preceding example, external bean definitions are loaded from three files:
-`services.xml`, `messageSource.xml`, and `themeSource.xml`. All location paths are
-relative to the definition file doing the importing, so `services.xml` must be in the
-same directory or classpath location as the file doing the importing, while
-`messageSource.xml` and `themeSource.xml` must be in a `resources` location below the
-location of the importing file. As you can see, a leading slash is ignored. However, given
-that these paths are relative, it is better form not to use the slash at all. The
-contents of the files being imported, including the top level `<beans/>` element, must
-be valid XML bean definitions, according to the Spring Schema.
-
-[NOTE]
-====
-It is possible, but not recommended, to reference files in parent directories using a
-relative "../" path. Doing so creates a dependency on a file that is outside the current
-application. In particular, this reference is not recommended for `classpath:` URLs (for
-example, `classpath:../services.xml`), where the runtime resolution process chooses the
-"`nearest`" classpath root and then looks into its parent directory. Classpath
-configuration changes may lead to the choice of a different, incorrect directory.
-
-You can always use fully qualified resource locations instead of relative paths: for
-example, `file:C:/config/services.xml` or `classpath:/config/services.xml`. However, be
-aware that you are coupling your application's configuration to specific absolute
-locations. It is generally preferable to keep an indirection for such absolute
-locations -- for example, through "${...}" placeholders that are resolved against JVM
-system properties at runtime.
-====
-
-The namespace itself provides the import directive feature. Further
-configuration features beyond plain bean definitions are available in a selection
-of XML namespaces provided by Spring -- for example, the `context` and `util` namespaces.
-
-
-[[groovy-bean-definition-dsl]]
-=== The Groovy Bean Definition DSL
-
-As a further example for externalized configuration metadata, bean definitions can also
-be expressed in Spring's Groovy Bean Definition DSL, as known from the Grails framework.
-Typically, such configuration live in a ".groovy" file with the structure shown in the
-following example:
-
-[source,groovy,indent=0,subs="verbatim,quotes"]
----
-	beans {
-		dataSource(BasicDataSource) {
-			driverClassName = "org.hsqldb.jdbcDriver"
-			url = "jdbc:hsqldb:mem:grailsDB"
-			username = "sa"
-			password = ""
-			settings = [mynew:"setting"]
-		}
-		sessionFactory(SessionFactory) {
-			dataSource = dataSource
-		}
-		myService(MyService) {
-			nestedBean = { AnotherBean bean ->
-				dataSource = dataSource
-			}
-		}
-	}
----
-
-This configuration style is largely equivalent to XML bean definitions and even
-supports Spring's XML configuration namespaces. It also allows for importing XML
-bean definition files through an `importBeans` directive.
-
-
-
-[[beans-factory-client]]
-== Using the Container
-
-The `ApplicationContext` is the interface for an advanced factory capable of maintaining
-a registry of different beans and their dependencies. By using the method
-`T getBean(String name, Class<T> requiredType)`, you can retrieve instances of your beans.
-
-The `ApplicationContext` lets you read bean definitions and access them, as the following
-example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	// create and configure beans
-	ApplicationContext context = new ClassPathXmlApplicationContext("services.xml", "daos.xml");
-
-	// retrieve configured instance
-	PetStoreService service = context.getBean("petStore", PetStoreService.class);
-
-	// use configured instance
-	List<String> userList = service.getUsernameList();
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-    import org.springframework.beans.factory.getBean
-
-	// create and configure beans
-    val context = ClassPathXmlApplicationContext("services.xml", "daos.xml")
-
-    // retrieve configured instance
-    val service = context.getBean<PetStoreService>("petStore")
-
-    // use configured instance
-    var userList = service.getUsernameList()
----
-======
-
-With Groovy configuration, bootstrapping looks very similar. It has a different context
-implementation class which is Groovy-aware (but also understands XML bean definitions).
-The following example shows Groovy configuration:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	ApplicationContext context = new GenericGroovyApplicationContext("services.groovy", "daos.groovy");
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-val context = GenericGroovyApplicationContext("services.groovy", "daos.groovy")
----
-======
-
-The most flexible variant is `GenericApplicationContext` in combination with reader
-delegates -- for example, with `XmlBeanDefinitionReader` for XML files, as the following
-example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	GenericApplicationContext context = new GenericApplicationContext();
-	new XmlBeanDefinitionReader(context).loadBeanDefinitions("services.xml", "daos.xml");
-	context.refresh();
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	val context = GenericApplicationContext()
-	XmlBeanDefinitionReader(context).loadBeanDefinitions("services.xml", "daos.xml")
-	context.refresh()
----
-======
-
-You can also use the `GroovyBeanDefinitionReader` for Groovy files, as the following
-example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	GenericApplicationContext context = new GenericApplicationContext();
-	new GroovyBeanDefinitionReader(context).loadBeanDefinitions("services.groovy", "daos.groovy");
-	context.refresh();
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	val context = GenericApplicationContext()
-	GroovyBeanDefinitionReader(context).loadBeanDefinitions("services.groovy", "daos.groovy")
-	context.refresh()
----
-======
-
-You can mix and match such reader delegates on the same `ApplicationContext`,
-reading bean definitions from diverse configuration sources.
-
-You can then use `getBean` to retrieve instances of your beans. The `ApplicationContext`
-interface has a few other methods for retrieving beans, but, ideally, your application
-code should never use them. Indeed, your application code should have no calls to the
-`getBean()` method at all and thus have no dependency on Spring APIs at all. For example,
-Spring's integration with web frameworks provides dependency injection for various web
-framework components such as controllers and JSF-managed beans, letting you declare
-a dependency on a specific bean through metadata (such as an autowiring annotation).
-
-
-
-
@@ -1,171 +0,0 @@
-[[beans-beanfactory]]
-= The `BeanFactory` API
-
-The `BeanFactory` API provides the underlying basis for Spring's IoC functionality.
-Its specific contracts are mostly used in integration with other parts of Spring and
-related third-party frameworks, and its `DefaultListableBeanFactory` implementation
-is a key delegate within the higher-level `GenericApplicationContext` container.
-
-`BeanFactory` and related interfaces (such as `BeanFactoryAware`, `InitializingBean`,
-`DisposableBean`) are important integration points for other framework components.
-By not requiring any annotations or even reflection, they allow for very efficient
-interaction between the container and its components. Application-level beans may
-use the same callback interfaces but typically prefer declarative dependency
-injection instead, either through annotations or through programmatic configuration.
-
-Note that the core `BeanFactory` API level and its `DefaultListableBeanFactory`
-implementation do not make assumptions about the configuration format or any
-component annotations to be used. All of these flavors come in through extensions
-(such as `XmlBeanDefinitionReader` and `AutowiredAnnotationBeanPostProcessor`) and
-operate on shared `BeanDefinition` objects as a core metadata representation.
-This is the essence of what makes Spring's container so flexible and extensible.
-
-
-
-[[context-introduction-ctx-vs-beanfactory]]
-== `BeanFactory` or `ApplicationContext`?
-
-This section explains the differences between the `BeanFactory` and
-`ApplicationContext` container levels and the implications on bootstrapping.
-
-You should use an `ApplicationContext` unless you have a good reason for not doing so, with
-`GenericApplicationContext` and its subclass `AnnotationConfigApplicationContext`
-as the common implementations for custom bootstrapping. These are the primary entry
-points to Spring's core container for all common purposes: loading of configuration
-files, triggering a classpath scan, programmatically registering bean definitions
-and annotated classes, and (as of 5.0) registering functional bean definitions.
-
-Because an `ApplicationContext` includes all the functionality of a `BeanFactory`, it is
-generally recommended over a plain `BeanFactory`, except for scenarios where full
-control over bean processing is needed. Within an `ApplicationContext` (such as the
-`GenericApplicationContext` implementation), several kinds of beans are detected
-by convention (that is, by bean name or by bean type -- in particular, post-processors),
-while a plain `DefaultListableBeanFactory` is agnostic about any special beans.
-
-For many extended container features, such as annotation processing and AOP proxying,
-the xref:core/beans/factory-extension.adoc#beans-factory-extension-bpp[`BeanPostProcessor` extension point] is essential.
-If you use only a plain `DefaultListableBeanFactory`, such post-processors do not
-get detected and activated by default. This situation could be confusing, because
-nothing is actually wrong with your bean configuration. Rather,  in such a scenario,
-the container needs to be fully bootstrapped through additional setup.
-
-The following table lists features provided by the `BeanFactory` and
-`ApplicationContext` interfaces and implementations.
-
-[[context-introduction-ctx-vs-beanfactory-feature-matrix]]
-.Feature Matrix
-[cols="50%,25%,25%"]
-|===
-| Feature | `BeanFactory` | `ApplicationContext`
-
-| Bean instantiation/wiring
-| Yes
-| Yes
-
-| Integrated lifecycle management
-| No
-| Yes
-
-| Automatic `BeanPostProcessor` registration
-| No
-| Yes
-
-| Automatic `BeanFactoryPostProcessor` registration
-| No
-| Yes
-
-| Convenient `MessageSource` access (for internationalization)
-| No
-| Yes
-
-| Built-in `ApplicationEvent` publication mechanism
-| No
-| Yes
-|===
-
-To explicitly register a bean post-processor with a `DefaultListableBeanFactory`,
-you need to programmatically call `addBeanPostProcessor`, as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
-	// populate the factory with bean definitions
-
-	// now register any needed BeanPostProcessor instances
-	factory.addBeanPostProcessor(new AutowiredAnnotationBeanPostProcessor());
-	factory.addBeanPostProcessor(new MyBeanPostProcessor());
-
-	// now start using the factory
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	val factory = DefaultListableBeanFactory()
-	// populate the factory with bean definitions
-
-	// now register any needed BeanPostProcessor instances
-	factory.addBeanPostProcessor(AutowiredAnnotationBeanPostProcessor())
-	factory.addBeanPostProcessor(MyBeanPostProcessor())
-
-	// now start using the factory
----
-======
-
-To apply a `BeanFactoryPostProcessor` to a plain `DefaultListableBeanFactory`,
-you need to call its `postProcessBeanFactory` method, as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
-	XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory);
-	reader.loadBeanDefinitions(new FileSystemResource("beans.xml"));
-
-	// bring in some property values from a Properties file
-	PropertySourcesPlaceholderConfigurer cfg = new PropertySourcesPlaceholderConfigurer();
-	cfg.setLocation(new FileSystemResource("jdbc.properties"));
-
-	// now actually do the replacement
-	cfg.postProcessBeanFactory(factory);
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	val factory = DefaultListableBeanFactory()
-	val reader = XmlBeanDefinitionReader(factory)
-	reader.loadBeanDefinitions(FileSystemResource("beans.xml"))
-
-	// bring in some property values from a Properties file
-	val cfg = PropertySourcesPlaceholderConfigurer()
-	cfg.setLocation(FileSystemResource("jdbc.properties"))
-
-	// now actually do the replacement
-	cfg.postProcessBeanFactory(factory)
----
-======
-
-In both cases, the explicit registration steps are inconvenient, which is
-why the various `ApplicationContext` variants are preferred over a plain
-`DefaultListableBeanFactory` in Spring-backed applications, especially when
-relying on `BeanFactoryPostProcessor` and `BeanPostProcessor` instances for extended
-container functionality in a typical enterprise setup.
-
-[NOTE]
-====
-An `AnnotationConfigApplicationContext` has all common annotation post-processors
-registered and may bring in additional processors underneath the
-covers through configuration annotations, such as `@EnableTransactionManagement`.
-At the abstraction level of Spring's annotation-based configuration model,
-the notion of bean post-processors becomes a mere internal container detail.
-====
@@ -1,84 +0,0 @@
-[[beans-child-bean-definitions]]
-= Bean Definition Inheritance
-
-A bean definition can contain a lot of configuration information, including constructor
-arguments, property values, and container-specific information, such as the initialization
-method, a static factory method name, and so on. A child bean definition inherits
-configuration data from a parent definition. The child definition can override some
-values or add others as needed. Using parent and child bean definitions can save a lot
-of typing. Effectively, this is a form of templating.
-
-If you work with an `ApplicationContext` interface programmatically, child bean
-definitions are represented by the `ChildBeanDefinition` class. Most users do not work
-with them on this level. Instead, they configure bean definitions declaratively in a class
-such as the `ClassPathXmlApplicationContext`. When you use XML-based configuration
-metadata, you can indicate a child bean definition by using the `parent` attribute,
-specifying the parent bean as the value of this attribute. The following example shows how
-to do so:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="inheritedTestBean" abstract="true"
-			class="org.springframework.beans.TestBean">
-		<property name="name" value="parent"/>
-		<property name="age" value="1"/>
-	</bean>
-
-	<bean id="inheritsWithDifferentClass"
-			class="org.springframework.beans.DerivedTestBean"
-			parent="inheritedTestBean" init-method="initialize">  <1>
-		<property name="name" value="override"/>
-		<!-- the age property value of 1 will be inherited from parent -->
-	</bean>
----
-<1> Note the `parent` attribute.
-
-A child bean definition uses the bean class from the parent definition if none is
-specified but can also override it. In the latter case, the child bean class must be
-compatible with the parent (that is, it must accept the parent's property values).
-
-A child bean definition inherits scope, constructor argument values, property values, and
-method overrides from the parent, with the option to add new values. Any scope, initialization
-method, destroy method, or `static` factory method settings that you specify
-override the corresponding parent settings.
-
-The remaining settings are always taken from the child definition: depends on,
-autowire mode, dependency check, singleton, and lazy init.
-
-The preceding example explicitly marks the parent bean definition as abstract by using
-the `abstract` attribute. If the parent definition does not specify a class, explicitly
-marking the parent bean definition as `abstract` is required, as the following example
-shows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="inheritedTestBeanWithoutClass" abstract="true">
-		<property name="name" value="parent"/>
-		<property name="age" value="1"/>
-	</bean>
-
-	<bean id="inheritsWithClass" class="org.springframework.beans.DerivedTestBean"
-			parent="inheritedTestBeanWithoutClass" init-method="initialize">
-		<property name="name" value="override"/>
-		<!-- age will inherit the value of 1 from the parent bean definition-->
-	</bean>
----
-
-The parent bean cannot be instantiated on its own because it is incomplete, and it is
-also explicitly marked as `abstract`. When a definition is `abstract`, it is
-usable only as a pure template bean definition that serves as a parent definition for
-child definitions. Trying to use such an `abstract` parent bean on its own, by referring
-to it as a ref property of another bean or doing an explicit `getBean()` call with the
-parent bean ID returns an error. Similarly, the container's internal
-`preInstantiateSingletons()` method ignores bean definitions that are defined as
-abstract.
-
-NOTE: `ApplicationContext` pre-instantiates all singletons by default. Therefore, it is
-important (at least for singleton beans) that if you have a (parent) bean definition
-which you intend to use only as a template, and this definition specifies a class, you
-must make sure to set the __abstract__ attribute to __true__, otherwise the application
-context will actually (attempt to) pre-instantiate the `abstract` bean.
-
-
-
-
@@ -1,52 +0,0 @@
-[[context-load-time-weaver]]
-= Registering a `LoadTimeWeaver`
-
-The `LoadTimeWeaver` is used by Spring to dynamically transform classes as they are
-loaded into the Java virtual machine (JVM).
-
-To enable load-time weaving, you can add the `@EnableLoadTimeWeaving` to one of your
-`@Configuration` classes, as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	@Configuration
-	@EnableLoadTimeWeaving
-	public class AppConfig {
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Configuration
-	@EnableLoadTimeWeaving
-	class AppConfig
----
-======
-
-Alternatively, for XML configuration, you can use the `context:load-time-weaver` element:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<beans>
-		<context:load-time-weaver/>
-	</beans>
----
-
-Once configured for the `ApplicationContext`, any bean within that `ApplicationContext`
-may implement `LoadTimeWeaverAware`, thereby receiving a reference to the load-time
-weaver instance. This is particularly useful in combination with
-xref:data-access/orm/jpa.adoc[Spring's JPA support] where load-time weaving may be
-necessary for JPA class transformation.
-Consult the
-{spring-framework-api}/orm/jpa/LocalContainerEntityManagerFactoryBean.html[`LocalContainerEntityManagerFactoryBean`]
-javadoc for more detail. For more on AspectJ load-time weaving, see xref:core/aop/using-aspectj.adoc#aop-aj-ltw[Load-time Weaving with AspectJ in the Spring Framework].
-
-
-
-
@@ -1,448 +0,0 @@
-[[beans-definition]]
-= Bean Overview
-
-A Spring IoC container manages one or more beans. These beans are created with the
-configuration metadata that you supply to the container (for example, in the form of XML
-`<bean/>` definitions).
-
-Within the container itself, these bean definitions are represented as `BeanDefinition`
-objects, which contain (among other information) the following metadata:
-
-* A package-qualified class name: typically, the actual implementation class of the
-  bean being defined.
-* Bean behavioral configuration elements, which state how the bean should behave in the
-  container (scope, lifecycle callbacks, and so forth).
-* References to other beans that are needed for the bean to do its work. These
-  references are also called collaborators or dependencies.
-* Other configuration settings to set in the newly created object -- for example, the size
-  limit of the pool or the number of connections to use in a bean that manages a
-  connection pool.
-
-This metadata translates to a set of properties that make up each bean definition.
-The following table describes these properties:
-
-[[beans-factory-bean-definition-tbl]]
-.The bean definition
-|===
-| Property| Explained in...
-
-| Class
-| xref:core/beans/definition.adoc#beans-factory-class[Instantiating Beans]
-
-| Name
-| xref:core/beans/definition.adoc#beans-beanname[Naming Beans]
-
-| Scope
-| xref:core/beans/factory-scopes.adoc[Bean Scopes]
-
-| Constructor arguments
-| xref:core/beans/dependencies/factory-collaborators.adoc[Dependency Injection]
-
-| Properties
-| xref:core/beans/dependencies/factory-collaborators.adoc[Dependency Injection]
-
-| Autowiring mode
-| xref:core/beans/dependencies/factory-autowire.adoc[Autowiring Collaborators]
-
-| Lazy initialization mode
-| xref:core/beans/dependencies/factory-lazy-init.adoc[Lazy-initialized Beans]
-
-| Initialization method
-| xref:core/beans/factory-nature.adoc#beans-factory-lifecycle-initializingbean[Initialization Callbacks]
-
-| Destruction method
-| xref:core/beans/factory-nature.adoc#beans-factory-lifecycle-disposablebean[Destruction Callbacks]
-|===
-
-In addition to bean definitions that contain information on how to create a specific
-bean, the `ApplicationContext` implementations also permit the registration of existing
-objects that are created outside the container (by users). This is done by accessing the
-ApplicationContext's `BeanFactory` through the `getBeanFactory()` method, which returns
-the `DefaultListableBeanFactory` implementation. `DefaultListableBeanFactory` supports
-this registration through the `registerSingleton(..)` and `registerBeanDefinition(..)`
-methods. However, typical applications work solely with beans defined through regular
-bean definition metadata.
-
-[NOTE]
-====
-Bean metadata and manually supplied singleton instances need to be registered as early
-as possible, in order for the container to properly reason about them during autowiring
-and other introspection steps. While overriding existing metadata and existing
-singleton instances is supported to some degree, the registration of new beans at
-runtime (concurrently with live access to the factory) is not officially supported and may
-lead to concurrent access exceptions, inconsistent state in the bean container, or both.
-====
-
-
-
-[[beans-beanname]]
-== Naming Beans
-
-Every bean has one or more identifiers. These identifiers must be unique within the
-container that hosts the bean. A bean usually has only one identifier. However, if it
-requires more than one, the extra ones can be considered aliases.
-
-In XML-based configuration metadata, you use the `id` attribute, the `name` attribute, or
-both to specify bean identifiers. The `id` attribute lets you specify exactly one `id`.
-Conventionally, these names are alphanumeric ('myBean', 'someService', etc.), but they
-can contain special characters as well. If you want to introduce other aliases for the
-bean, you can also specify them in the `name` attribute, separated by a comma (`,`),
-semicolon (`;`), or white space. Although the `id` attribute is defined as an
-`xsd:string` type, bean `id` uniqueness is enforced by the container, though not by XML
-parsers.
-
-You are not required to supply a `name` or an `id` for a bean. If you do not supply a
-`name` or `id` explicitly, the container generates a unique name for that bean. However,
-if you want to refer to that bean by name, through the use of the `ref` element or a
-Service Locator style lookup, you must provide a name.
-Motivations for not supplying a name are related to using xref:core/beans/dependencies/factory-properties-detailed.adoc#beans-inner-beans[inner beans]
- and xref:core/beans/dependencies/factory-autowire.adoc[autowiring collaborators].
-
-.Bean Naming Conventions
-****
-The convention is to use the standard Java convention for instance field names when
-naming beans. That is, bean names start with a lowercase letter and are camel-cased
-from there. Examples of such names include `accountManager`,
-`accountService`, `userDao`, `loginController`, and so forth.
-
-Naming beans consistently makes your configuration easier to read and understand.
-Also, if you use Spring AOP, it helps a lot when applying advice to a set of beans
-related by name.
-****
-
-NOTE: With component scanning in the classpath, Spring generates bean names for unnamed
-components, following the rules described earlier: essentially, taking the simple class name
-and turning its initial character to lower-case. However, in the (unusual) special
-case when there is more than one character and both the first and second characters
-are upper case, the original casing gets preserved. These are the same rules as
-defined by `java.beans.Introspector.decapitalize` (which Spring uses here).
-
-
-[[beans-beanname-alias]]
-=== Aliasing a Bean outside the Bean Definition
-
-In a bean definition itself, you can supply more than one name for the bean, by using a
-combination of up to one name specified by the `id` attribute and any number of other
-names in the `name` attribute. These names can be equivalent aliases to the same bean
-and are useful for some situations, such as letting each component in an application
-refer to a common dependency by using a bean name that is specific to that component
-itself.
-
-Specifying all aliases where the bean is actually defined is not always adequate,
-however. It is sometimes desirable to introduce an alias for a bean that is defined
-elsewhere. This is commonly the case in large systems where configuration is split
-amongst each subsystem, with each subsystem having its own set of object definitions.
-In XML-based configuration metadata, you can use the `<alias/>` element to accomplish
-this. The following example shows how to do so:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<alias name="fromName" alias="toName"/>
----
-
-In this case, a bean (in the same container) named `fromName` may also,
-after the use of this alias definition, be referred to as `toName`.
-
-For example, the configuration metadata for subsystem A may refer to a DataSource by the
-name of `subsystemA-dataSource`. The configuration metadata for subsystem B may refer to
-a DataSource by the name of `subsystemB-dataSource`. When composing the main application
-that uses both these subsystems, the main application refers to the DataSource by the
-name of `myApp-dataSource`. To have all three names refer to the same object, you can
-add the following alias definitions to the configuration metadata:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<alias name="myApp-dataSource" alias="subsystemA-dataSource"/>
-	<alias name="myApp-dataSource" alias="subsystemB-dataSource"/>
----
-
-Now each component and the main application can refer to the dataSource through a name
-that is unique and guaranteed not to clash with any other definition (effectively
-creating a namespace), yet they refer to the same bean.
-
-.Java-configuration
-****
-If you use Java Configuration, the `@Bean` annotation can be used to provide aliases.
-See xref:core/beans/java/bean-annotation.adoc[Using the `@Bean` Annotation] for details.
-****
-
-
-
-[[beans-factory-class]]
-== Instantiating Beans
-
-A bean definition is essentially a recipe for creating one or more objects. The
-container looks at the recipe for a named bean when asked and uses the configuration
-metadata encapsulated by that bean definition to create (or acquire) an actual object.
-
-If you use XML-based configuration metadata, you specify the type (or class) of object
-that is to be instantiated in the `class` attribute of the `<bean/>` element. This
-`class` attribute (which, internally, is a `Class` property on a `BeanDefinition`
-instance) is usually mandatory. (For exceptions, see
-xref:core/beans/definition.adoc#beans-factory-class-instance-factory-method[Instantiation by Using an Instance Factory Method] and xref:core/beans/child-bean-definitions.adoc[Bean Definition Inheritance].)
-You can use the `Class` property in one of two ways:
-
-* Typically, to specify the bean class to be constructed in the case where the container
-  itself directly creates the bean by calling its constructor reflectively, somewhat
-  equivalent to Java code with the `new` operator.
-* To specify the actual class containing the `static` factory method that is
-  invoked to create the object, in the less common case where the container invokes a
-  `static` factory method on a class to create the bean. The object type returned
-  from the invocation of the `static` factory method may be the same class or another
-  class entirely.
-
-.Nested class names
-****
-If you want to configure a bean definition for a nested class, you may use either the
-binary name or the source name of the nested class.
-
-For example, if you have a class called `SomeThing` in the `com.example` package, and
-this `SomeThing` class has a `static` nested class called `OtherThing`, they can be
-separated by a dollar sign (`$`) or a dot (`.`). So the value of the `class` attribute in
-a bean definition would be `com.example.SomeThing$OtherThing` or
-`com.example.SomeThing.OtherThing`.
-****
-
-
-[[beans-factory-class-ctor]]
-=== Instantiation with a Constructor
-
-When you create a bean by the constructor approach, all normal classes are usable by and
-compatible with Spring. That is, the class being developed does not need to implement
-any specific interfaces or to be coded in a specific fashion. Simply specifying the bean
-class should suffice. However, depending on what type of IoC you use for that specific
-bean, you may need a default (empty) constructor.
-
-The Spring IoC container can manage virtually any class you want it to manage. It is
-not limited to managing true JavaBeans. Most Spring users prefer actual JavaBeans with
-only a default (no-argument) constructor and appropriate setters and getters modeled
-after the properties in the container. You can also have more exotic non-bean-style
-classes in your container. If, for example, you need to use a legacy connection pool
-that absolutely does not adhere to the JavaBean specification, Spring can manage it as
-well.
-
-With XML-based configuration metadata you can specify your bean class as follows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="exampleBean" class="examples.ExampleBean"/>
-
-	<bean name="anotherExample" class="examples.ExampleBeanTwo"/>
----
-
-For details about the mechanism for supplying arguments to the constructor (if required)
-and setting object instance properties after the object is constructed, see
-xref:core/beans/dependencies/factory-collaborators.adoc[Injecting Dependencies].
-
-
-[[beans-factory-class-static-factory-method]]
-=== Instantiation with a Static Factory Method
-
-When defining a bean that you create with a static factory method, use the `class`
-attribute to specify the class that contains the `static` factory method and an attribute
-named `factory-method` to specify the name of the factory method itself. You should be
-able to call this method (with optional arguments, as described later) and return a live
-object, which subsequently is treated as if it had been created through a constructor.
-One use for such a bean definition is to call `static` factories in legacy code.
-
-The following bean definition specifies that the bean will be created by calling a
-factory method. The definition does not specify the type (class) of the returned object,
-but rather the class containing the factory method. In this example, the
-`createInstance()` method must be a `static` method. The following example shows how to
-specify a factory method:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="clientService"
-		class="examples.ClientService"
-		factory-method="createInstance"/>
----
-
-The following example shows a class that would work with the preceding bean definition:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class ClientService {
-		private static ClientService clientService = new ClientService();
-		private ClientService() {}
-
-		public static ClientService createInstance() {
-			return clientService;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class ClientService private constructor() {
-		companion object {
-			private val clientService = ClientService()
-			@JvmStatic
-			fun createInstance() = clientService
-		}
-	}
----
-======
-
-For details about the mechanism for supplying (optional) arguments to the factory method
-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].
-
-
-[[beans-factory-class-instance-factory-method]]
-=== Instantiation by Using an Instance Factory Method
-
-Similar to instantiation through a xref:core/beans/definition.adoc#beans-factory-class-static-factory-method[static factory method]
-, instantiation with an instance factory method invokes a non-static
-method of an existing bean from the container to create a new bean. To use this
-mechanism, leave the `class` attribute empty and, in the `factory-bean` attribute,
-specify the name of a bean in the current (or parent or ancestor) container that contains
-the instance method that is to be invoked to create the object. Set the name of the
-factory method itself with the `factory-method` attribute. The following example shows
-how to configure such a bean:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- the factory bean, which contains a method called createClientServiceInstance() -->
-	<bean id="serviceLocator" class="examples.DefaultServiceLocator">
-		<!-- inject any dependencies required by this locator bean -->
-	</bean>
-
-	<!-- the bean to be created via the factory bean -->
-	<bean id="clientService"
-		factory-bean="serviceLocator"
-		factory-method="createClientServiceInstance"/>
----
-
-The following example shows the corresponding class:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class DefaultServiceLocator {
-
-		private static ClientService clientService = new ClientServiceImpl();
-
-		public ClientService createClientServiceInstance() {
-			return clientService;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class DefaultServiceLocator {
-		companion object {
-			private val clientService = ClientServiceImpl()
-		}
-		fun createClientServiceInstance(): ClientService {
-			return clientService
-		}
-	}
----
-======
-
-One factory class can also hold more than one factory method, as the following example shows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="serviceLocator" class="examples.DefaultServiceLocator">
-		<!-- inject any dependencies required by this locator bean -->
-	</bean>
-
-	<bean id="clientService"
-		factory-bean="serviceLocator"
-		factory-method="createClientServiceInstance"/>
-
-	<bean id="accountService"
-		factory-bean="serviceLocator"
-		factory-method="createAccountServiceInstance"/>
----
-
-The following example shows the corresponding class:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class DefaultServiceLocator {
-
-		private static ClientService clientService = new ClientServiceImpl();
-
-		private static AccountService accountService = new AccountServiceImpl();
-
-		public ClientService createClientServiceInstance() {
-			return clientService;
-		}
-
-		public AccountService createAccountServiceInstance() {
-			return accountService;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class DefaultServiceLocator {
-		companion object {
-			private val clientService = ClientServiceImpl()
-			private val accountService = AccountServiceImpl()
-		}
-
-		fun createClientServiceInstance(): ClientService {
-			return clientService
-		}
-
-		fun createAccountServiceInstance(): AccountService {
-			return accountService
-		}
-	}
----
-======
-
-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]
-.
-
-NOTE: In Spring documentation, "factory bean" refers to a bean that is configured in the
-Spring container and that creates objects through an
-xref:core/beans/definition.adoc#beans-factory-class-instance-factory-method[instance] or
-xref:core/beans/definition.adoc#beans-factory-class-static-factory-method[static] factory method. By contrast,
-`FactoryBean` (notice the capitalization) refers to a Spring-specific
-xref:core/beans/factory-extension.adoc#beans-factory-extension-factorybean[`FactoryBean`] implementation class.
-
-
-[[beans-factory-type-determination]]
-=== Determining a Bean's Runtime Type
-
-The runtime type of a specific bean is non-trivial to determine. A specified class in
-the bean metadata definition is just an initial class reference, potentially combined
-with a declared factory method or being a `FactoryBean` class which may lead to a
-different runtime type of the bean, or not being set at all in case of an instance-level
-factory method (which is resolved via the specified `factory-bean` name instead).
-Additionally, AOP proxying may wrap a bean instance with an interface-based proxy with
-limited exposure of the target bean's actual type (just its implemented interfaces).
-
-The recommended way to find out about the actual runtime type of a particular bean is
-a `BeanFactory.getType` call for the specified bean name. This takes all of the above
-cases into account and returns the type of object that a `BeanFactory.getBean` call is
-going to return for the same bean name.
-
-
-
-
@@ -1,12 +0,0 @@
-[[beans-dependencies]]
-= Dependencies
-:page-section-summary-toc: 1
-
-A typical enterprise application does not consist of a single object (or bean in the
-Spring parlance). Even the simplest application has a few objects that work together to
-present what the end-user sees as a coherent application. This next section explains how
-you go from defining a number of bean definitions that stand alone to a fully realized
-application where objects collaborate to achieve a goal.
-
-
-
@@ -1,127 +0,0 @@
-[[beans-factory-autowire]]
-= Autowiring Collaborators
-
-The Spring container can autowire relationships between collaborating beans. You can
-let Spring resolve collaborators (other beans) automatically for your bean by
-inspecting the contents of the `ApplicationContext`. Autowiring has the following
-advantages:
-
-* Autowiring can significantly reduce the need to specify properties or constructor
-  arguments. (Other mechanisms such as a bean template
-  xref:core/beans/child-bean-definitions.adoc[discussed elsewhere in this chapter] are also valuable
-  in this regard.)
-* Autowiring can update a configuration as your objects evolve. For example, if you need
-  to add a dependency to a class, that dependency can be satisfied automatically without
-  you needing to modify the configuration. Thus autowiring can be especially useful
-  during development, without negating the option of switching to explicit wiring when
-  the code base becomes more stable.
-
-When using XML-based configuration metadata (see xref:core/beans/dependencies/factory-collaborators.adoc[Dependency Injection]), you
-can specify the autowire mode for a bean definition with the `autowire` attribute of the
-`<bean/>` element. The autowiring functionality has four modes. You specify autowiring
-per bean and can thus choose which ones to autowire. The following table describes the
-four autowiring modes:
-
-[[beans-factory-autowiring-modes-tbl]]
-.Autowiring modes
-[cols="20%,80%"]
-|===
-| Mode| Explanation
-
-| `no`
-| (Default) No autowiring. Bean references must be defined by `ref` elements. Changing
-  the default setting is not recommended for larger deployments, because specifying
-  collaborators explicitly gives greater control and clarity. To some extent, it
-  documents the structure of a system.
-
-| `byName`
-| Autowiring by property name. Spring looks for a bean with the same name as the
-  property that needs to be autowired. For example, if a bean definition is set to
-  autowire by name and it contains a `master` property (that is, it has a
-  `setMaster(..)` method), Spring looks for a bean definition named `master` and uses
-  it to set the property.
-
-| `byType`
-| Lets a property be autowired if exactly one bean of the property type exists in
-  the container. If more than one exists, a fatal exception is thrown, which indicates
-  that you may not use `byType` autowiring for that bean. If there are no matching
-  beans, nothing happens (the property is not set).
-
-| `constructor`
-| Analogous to `byType` but applies to constructor arguments. If there is not exactly
-  one bean of the constructor argument type in the container, a fatal error is raised.
-|===
-
-With `byType` or `constructor` autowiring mode, you can wire arrays and
-typed collections. In such cases, all autowire candidates within the container that
-match the expected type are provided to satisfy the dependency. You can autowire
-strongly-typed `Map` instances if the expected key type is `String`. An autowired `Map`
-instance's values consist of all bean instances that match the expected type, and the
-`Map` instance's keys contain the corresponding bean names.
-
-
-[[beans-autowired-exceptions]]
-== Limitations and Disadvantages of Autowiring
-
-Autowiring works best when it is used consistently across a project. If autowiring is
-not used in general, it might be confusing to developers to use it to wire only one or
-two bean definitions.
-
-Consider the limitations and disadvantages of autowiring:
-
-* Explicit dependencies in `property` and `constructor-arg` settings always override
-  autowiring. You cannot autowire simple properties such as primitives,
-  `Strings`, and `Classes` (and arrays of such simple properties). This limitation is
-  by-design.
-* Autowiring is less exact than explicit wiring. Although, as noted in the earlier table,
-  Spring is careful to avoid guessing in case of ambiguity that might have unexpected
-  results. The relationships between your Spring-managed objects are no longer
-  documented explicitly.
-* Wiring information may not be available to tools that may generate documentation from
-  a Spring container.
-* Multiple bean definitions within the container may match the type specified by the
-  setter method or constructor argument to be autowired. For arrays, collections, or
-  `Map` instances, this is not necessarily a problem. However, for dependencies that
-  expect a single value, this ambiguity is not arbitrarily resolved. If no unique bean
-  definition is available, an exception is thrown.
-
-In the latter scenario, you have several options:
-
-* Abandon autowiring in favor of explicit wiring.
-* Avoid autowiring for a bean definition by setting its `autowire-candidate` attributes
-  to `false`, as described in the xref:core/beans/dependencies/factory-autowire.adoc#beans-factory-autowire-candidate[next section].
-* Designate a single bean definition as the primary candidate by setting the
-  `primary` attribute of its `<bean/>` element to `true`.
-* Implement the more fine-grained control available with annotation-based configuration,
-  as described in xref:core/beans/annotation-config.adoc[Annotation-based Container Configuration].
-
-
-
-[[beans-factory-autowire-candidate]]
-== Excluding a Bean from Autowiring
-
-On a per-bean basis, you can exclude a bean from autowiring. In Spring's XML format, set
-the `autowire-candidate` attribute of the `<bean/>` element to `false`. The container
-makes that specific bean definition unavailable to the autowiring infrastructure
-(including annotation style configurations such as xref:core/beans/annotation-config/autowired.adoc[`@Autowired`]
-).
-
-NOTE: The `autowire-candidate` attribute is designed to only affect type-based autowiring.
-It does not affect explicit references by name, which get resolved even if the
-specified bean is not marked as an autowire candidate. As a consequence, autowiring
-by name nevertheless injects a bean if the name matches.
-
-You can also limit autowire candidates based on pattern-matching against bean names. The
-top-level `<beans/>` element accepts one or more patterns within its
-`default-autowire-candidates` attribute. For example, to limit autowire candidate status
-to any bean whose name ends with `Repository`, provide a value of `*Repository`. To
-provide multiple patterns, define them in a comma-separated list. An explicit value of
-`true` or `false` for a bean definition's `autowire-candidate` attribute always takes
-precedence. For such beans, the pattern matching rules do not apply.
-
-These techniques are useful for beans that you never want to be injected into other
-beans by autowiring. It does not mean that an excluded bean cannot itself be configured by
-using autowiring. Rather, the bean itself is not a candidate for autowiring other beans.
-
-
-
@@ -1,608 +0,0 @@
-[[beans-factory-collaborators]]
-= Dependency Injection
-
-Dependency injection (DI) is a process whereby objects define their dependencies
-(that is, the other objects with which they work) only through constructor arguments,
-arguments to a factory method, or properties that are set on the object instance after
-it is constructed or returned from a factory method. The container then injects those
-dependencies when it creates the bean. This process is fundamentally the inverse (hence
-the name, Inversion of Control) of the bean itself controlling the instantiation
-or location of its dependencies on its own by using direct construction of classes or
-the Service Locator pattern.
-
-Code is cleaner with the DI principle, and decoupling is more effective when objects are
-provided with their dependencies. The object does not look up its dependencies and does
-not know the location or class of the dependencies. As a result, your classes become easier
-to test, particularly when the dependencies are on interfaces or abstract base classes,
-which allow for stub or mock implementations to be used in unit tests.
-
-DI exists in two major variants: xref:core/beans/dependencies/factory-collaborators.adoc#beans-constructor-injection[Constructor-based dependency injection]
- and xref:core/beans/dependencies/factory-collaborators.adoc#beans-setter-injection[Setter-based dependency injection].
-
-
-[[beans-constructor-injection]]
-== Constructor-based Dependency Injection
-
-Constructor-based DI is accomplished by the container invoking a constructor with a
-number of arguments, each representing a dependency. Calling a `static` factory method
-with specific arguments to construct the bean is nearly equivalent, and this discussion
-treats arguments to a constructor and to a `static` factory method similarly. The
-following example shows a class that can only be dependency-injected with constructor
-injection:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class SimpleMovieLister {
-
-		// the SimpleMovieLister has a dependency on a MovieFinder
-		private final MovieFinder movieFinder;
-
-		// a constructor so that the Spring container can inject a MovieFinder
-		public SimpleMovieLister(MovieFinder movieFinder) {
-			this.movieFinder = movieFinder;
-		}
-
-		// business logic that actually uses the injected MovieFinder is omitted...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	// a constructor so that the Spring container can inject a MovieFinder
-	class SimpleMovieLister(private val movieFinder: MovieFinder) {
-		// business logic that actually uses the injected MovieFinder is omitted...
-	}
----
-======
-
-Notice that there is nothing special about this class. It is a POJO that
-has no dependencies on container specific interfaces, base classes, or annotations.
-
-[[beans-factory-ctor-arguments-resolution]]
-=== Constructor Argument Resolution
-
-Constructor argument resolution matching occurs by using the argument's type. If no
-potential ambiguity exists in the constructor arguments of a bean definition, the
-order in which the constructor arguments are defined in a bean definition is the order
-in which those arguments are supplied to the appropriate constructor when the bean is
-being instantiated. Consider the following class:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary",chomp="-packages"]
----
-	package x.y;
-
-	public class ThingOne {
-
-		public ThingOne(ThingTwo thingTwo, ThingThree thingThree) {
-			// ...
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary",chomp="-packages"]
----
-	package x.y
-
-	class ThingOne(thingTwo: ThingTwo, thingThree: ThingThree)
----
-======
-
-Assuming that the `ThingTwo` and `ThingThree` classes are not related by inheritance, no
-potential ambiguity exists. Thus, the following configuration works fine, and you do not
-need to specify the constructor argument indexes or types explicitly in the
-`<constructor-arg/>` element.
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<beans>
-		<bean id="beanOne" class="x.y.ThingOne">
-			<constructor-arg ref="beanTwo"/>
-			<constructor-arg ref="beanThree"/>
-		</bean>
-
-		<bean id="beanTwo" class="x.y.ThingTwo"/>
-
-		<bean id="beanThree" class="x.y.ThingThree"/>
-	</beans>
----
-
-When another bean is referenced, the type is known, and matching can occur (as was the
-case with the preceding example). When a simple type is used, such as
-`<value>true</value>`, Spring cannot determine the type of the value, and so cannot match
-by type without help. Consider the following class:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary",chomp="-packages"]
----
-	package examples;
-
-	public class ExampleBean {
-
-		// Number of years to calculate the Ultimate Answer
-		private final int years;
-
-		// The Answer to Life, the Universe, and Everything
-		private final String ultimateAnswer;
-
-		public ExampleBean(int years, String ultimateAnswer) {
-			this.years = years;
-			this.ultimateAnswer = ultimateAnswer;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary",chomp="-packages"]
----
-	package examples
-
-	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
-	)
----
-======
-
-.[[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,
-as the following example shows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="exampleBean" class="examples.ExampleBean">
-		<constructor-arg type="int" value="7500000"/>
-		<constructor-arg type="java.lang.String" value="42"/>
-	</bean>
----
--
-
-.[[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:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="exampleBean" class="examples.ExampleBean">
-		<constructor-arg index="0" value="7500000"/>
-		<constructor-arg index="1" value="42"/>
-	</bean>
----
-
-In addition to resolving the ambiguity of multiple simple values, specifying an index
-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
--
-You can also use the constructor parameter name for value disambiguation, as the following
-example shows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="exampleBean" class="examples.ExampleBean">
-		<constructor-arg name="years" value="7500000"/>
-		<constructor-arg name="ultimateAnswer" value="42"/>
-	</bean>
----
-
-Keep in mind that, to make this work out of the box, your code must be compiled with the
-debug flag enabled so that Spring can look up the parameter name from the constructor.
-If you cannot or do not want to compile your code with the debug flag, you can use the
-https://download.oracle.com/javase/8/docs/api/java/beans/ConstructorProperties.html[@ConstructorProperties]
-JDK annotation to explicitly name your constructor arguments. The sample class would
-then have to look as follows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary",chomp="-packages"]
----
-	package examples;
-
-	public class ExampleBean {
-
-		// Fields omitted
-
-		@ConstructorProperties({"years", "ultimateAnswer"})
-		public ExampleBean(int years, String ultimateAnswer) {
-			this.years = years;
-			this.ultimateAnswer = ultimateAnswer;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary",chomp="-packages"]
----
-	package examples
-
-	class ExampleBean
-	@ConstructorProperties("years", "ultimateAnswer")
-	constructor(val years: Int, val ultimateAnswer: String)
----
-======
--
-
-
-[[beans-setter-injection]]
-== Setter-based Dependency Injection
-
-Setter-based DI is accomplished by the container calling setter methods on your
-beans after invoking a no-argument constructor or a no-argument `static` factory method to
-instantiate your bean.
-
-The following example shows a class that can only be dependency-injected by using pure
-setter injection. This class is conventional Java. It is a POJO that has no dependencies
-on container specific interfaces, base classes, or annotations.
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class SimpleMovieLister {
-
-		// the SimpleMovieLister has a dependency on the MovieFinder
-		private MovieFinder movieFinder;
-
-		// a setter method so that the Spring container can inject a MovieFinder
-		public void setMovieFinder(MovieFinder movieFinder) {
-			this.movieFinder = movieFinder;
-		}
-
-		// business logic that actually uses the injected MovieFinder is omitted...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-class SimpleMovieLister {
-
-	// a late-initialized property so that the Spring container can inject a MovieFinder
-	lateinit var movieFinder: MovieFinder
-
-	// business logic that actually uses the injected MovieFinder is omitted...
-}
----
-======
-
-
-The `ApplicationContext` supports constructor-based and setter-based DI for the beans it
-manages. It also supports setter-based DI after some dependencies have already been
-injected through the constructor approach. You configure the dependencies in the form of
-a `BeanDefinition`, which you use in conjunction with `PropertyEditor` instances to
-convert properties from one format to another. However, most Spring users do not work
-with these classes directly (that is, programmatically) but rather with XML `bean`
-definitions, annotated components (that is, classes annotated with `@Component`,
-`@Controller`, and so forth), or `@Bean` methods in Java-based `@Configuration` classes.
-These sources are then converted internally into instances of `BeanDefinition` and used to
-load an entire Spring IoC container instance.
-
-[[beans-constructor-vs-setter-injection]]
-.Constructor-based or setter-based DI?
-****
-Since you can mix constructor-based and setter-based DI, it is a good rule of thumb to
-use constructors for mandatory dependencies and setter methods or configuration methods
-for optional dependencies. Note that use of the xref:core/beans/annotation-config/autowired.adoc[@Autowired]
-annotation on a setter method can be used to make the property be a required dependency;
-however, constructor injection with programmatic validation of arguments is preferable.
-
-The Spring team generally advocates constructor injection, as it lets you implement
-application components as immutable objects and ensures that required dependencies
-are not `null`. Furthermore, constructor-injected components are always returned to the client
-(calling) code in a fully initialized state. As a side note, a large number of constructor
-arguments is a bad code smell, implying that the class likely has too many
-responsibilities and should be refactored to better address proper separation of concerns.
-
-Setter injection should primarily only be used for optional dependencies that can be
-assigned reasonable default values within the class. Otherwise, not-null checks must be
-performed everywhere the code uses the dependency. One benefit of setter injection is that
-setter methods make objects of that class amenable to reconfiguration or re-injection
-later. Management through xref:integration/jmx.adoc[JMX MBeans] is therefore a compelling
-use case for setter injection.
-
-Use the DI style that makes the most sense for a particular class. Sometimes, when dealing
-with third-party classes for which you do not have the source, the choice is made for you.
-For example, if a third-party class does not expose any setter methods, then constructor
-injection may be the only available form of DI.
-****
-
-
-[[beans-dependency-resolution]]
-== Dependency Resolution Process
-
-The container performs bean dependency resolution as follows:
-
-* The `ApplicationContext` is created and initialized with configuration metadata that
-  describes all the beans. Configuration metadata can be specified by XML, Java code, or
-  annotations.
-* For each bean, its dependencies are expressed in the form of properties, constructor
-  arguments, or arguments to the static-factory method (if you use that instead of a
-  normal constructor). These dependencies are provided to the bean, when the bean is
-  actually created.
-* Each property or constructor argument is an actual definition of the value to set, or
-  a reference to another bean in the container.
-* Each property or constructor argument that is a value is converted from its specified
-  format to the actual type of that property or constructor argument. By default, Spring
-  can convert a value supplied in string format to all built-in types, such as `int`,
-  `long`, `String`, `boolean`, and so forth.
-
-The Spring container validates the configuration of each bean as the container is created.
-However, the bean properties themselves are not set until the bean is actually created.
-Beans that are singleton-scoped and set to be pre-instantiated (the default) are created
-when the container is created. Scopes are defined in xref:core/beans/factory-scopes.adoc[Bean Scopes]. Otherwise,
-the bean is created only when it is requested. Creation of a bean potentially causes a
-graph of beans to be created, as the bean's dependencies and its dependencies'
-dependencies (and so on) are created and assigned. Note that resolution mismatches among
-those dependencies may show up late -- that is, on first creation of the affected bean.
-
-.Circular dependencies
-****
-If you use predominantly constructor injection, it is possible to create an unresolvable
-circular dependency scenario.
-
-For example: Class A requires an instance of class B through constructor injection, and
-class B requires an instance of class A through constructor injection. If you configure
-beans for classes A and B to be injected into each other, the Spring IoC container
-detects this circular reference at runtime, and throws a
-`BeanCurrentlyInCreationException`.
-
-One possible solution is to edit the source code of some classes to be configured by
-setters rather than constructors. Alternatively, avoid constructor injection and use
-setter injection only. In other words, although it is not recommended, you can configure
-circular dependencies with setter injection.
-
-Unlike the typical case (with no circular dependencies), a circular dependency
-between bean A and bean B forces one of the beans to be injected into the other prior to
-being fully initialized itself (a classic chicken-and-egg scenario).
-****
-
-You can generally trust Spring to do the right thing. It detects configuration problems,
-such as references to non-existent beans and circular dependencies, at container
-load-time. Spring sets properties and resolves dependencies as late as possible, when
-the bean is actually created. This means that a Spring container that has loaded
-correctly can later generate an exception when you request an object if there is a
-problem creating that object or one of its dependencies -- for example, the bean throws an
-exception as a result of a missing or invalid property. This potentially delayed
-visibility of some configuration issues is why `ApplicationContext` implementations by
-default pre-instantiate singleton beans. At the cost of some upfront time and memory to
-create these beans before they are actually needed, you discover configuration issues
-when the `ApplicationContext` is created, not later. You can still override this default
-behavior so that singleton beans initialize lazily, rather than being eagerly
-pre-instantiated.
-
-If no circular dependencies exist, when one or more collaborating beans are being
-injected into a dependent bean, each collaborating bean is totally configured prior
-to being injected into the dependent bean. This means that, if bean A has a dependency on
-bean B, the Spring IoC container completely configures bean B prior to invoking the
-setter method on bean A. In other words, the bean is instantiated (if it is not a
-pre-instantiated singleton), its dependencies are set, and the relevant lifecycle
-methods (such as a xref:core/beans/factory-nature.adoc#beans-factory-lifecycle-initializingbean[configured init method]
-or the xref:core/beans/factory-nature.adoc#beans-factory-lifecycle-initializingbean[InitializingBean callback method])
-are invoked.
-
-
-[[beans-some-examples]]
-== Examples of Dependency Injection
-
-The following example uses XML-based configuration metadata for setter-based DI. A small
-part of a Spring XML configuration file specifies some bean definitions as follows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="exampleBean" class="examples.ExampleBean">
-		<!-- setter injection using the nested ref element -->
-		<property name="beanOne">
-			<ref bean="anotherExampleBean"/>
-		</property>
-
-		<!-- setter injection using the neater ref attribute -->
-		<property name="beanTwo" ref="yetAnotherBean"/>
-		<property name="integerProperty" value="1"/>
-	</bean>
-
-	<bean id="anotherExampleBean" class="examples.AnotherBean"/>
-	<bean id="yetAnotherBean" class="examples.YetAnotherBean"/>
----
-
-The following example shows the corresponding `ExampleBean` class:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class ExampleBean {
-
-		private AnotherBean beanOne;
-
-		private YetAnotherBean beanTwo;
-
-		private int i;
-
-		public void setBeanOne(AnotherBean beanOne) {
-			this.beanOne = beanOne;
-		}
-
-		public void setBeanTwo(YetAnotherBean beanTwo) {
-			this.beanTwo = beanTwo;
-		}
-
-		public void setIntegerProperty(int i) {
-			this.i = i;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-class ExampleBean {
-	lateinit var beanOne: AnotherBean
-	lateinit var beanTwo: YetAnotherBean
-	var i: Int = 0
-}
----
-======
-
-In the preceding example, setters are declared to match against the properties specified
-in the XML file. The following example uses constructor-based DI:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="exampleBean" class="examples.ExampleBean">
-		<!-- constructor injection using the nested ref element -->
-		<constructor-arg>
-			<ref bean="anotherExampleBean"/>
-		</constructor-arg>
-
-		<!-- constructor injection using the neater ref attribute -->
-		<constructor-arg ref="yetAnotherBean"/>
-
-		<constructor-arg type="int" value="1"/>
-	</bean>
-
-	<bean id="anotherExampleBean" class="examples.AnotherBean"/>
-	<bean id="yetAnotherBean" class="examples.YetAnotherBean"/>
----
-
-The following example shows the corresponding `ExampleBean` class:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class ExampleBean {
-
-		private AnotherBean beanOne;
-
-		private YetAnotherBean beanTwo;
-
-		private int i;
-
-		public ExampleBean(
-			AnotherBean anotherBean, YetAnotherBean yetAnotherBean, int i) {
-			this.beanOne = anotherBean;
-			this.beanTwo = yetAnotherBean;
-			this.i = i;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-class ExampleBean(
-		private val beanOne: AnotherBean,
-		private val beanTwo: YetAnotherBean,
-		private val i: Int)
----
-======
-
-The constructor arguments specified in the bean definition are used as arguments to
-the constructor of the `ExampleBean`.
-
-Now consider a variant of this example, where, instead of using a constructor, Spring is
-told to call a `static` factory method to return an instance of the object:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="exampleBean" class="examples.ExampleBean" factory-method="createInstance">
-		<constructor-arg ref="anotherExampleBean"/>
-		<constructor-arg ref="yetAnotherBean"/>
-		<constructor-arg value="1"/>
-	</bean>
-
-	<bean id="anotherExampleBean" class="examples.AnotherBean"/>
-	<bean id="yetAnotherBean" class="examples.YetAnotherBean"/>
----
-
-The following example shows the corresponding `ExampleBean` class:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class ExampleBean {
-
-		// a private constructor
-		private ExampleBean(...) {
-			...
-		}
-
-		// a static factory method; the arguments to this method can be
-		// considered the dependencies of the bean that is returned,
-		// regardless of how those arguments are actually used.
-		public static ExampleBean createInstance (
-			AnotherBean anotherBean, YetAnotherBean yetAnotherBean, int i) {
-
-			ExampleBean eb = new ExampleBean (...);
-			// some other operations...
-			return eb;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class ExampleBean private constructor() {
-		companion object {
-			// a static factory method; the arguments to this method can be
-			// considered the dependencies of the bean that is returned,
-			// regardless of how those arguments are actually used.
-			@JvmStatic
-			fun createInstance(anotherBean: AnotherBean, yetAnotherBean: YetAnotherBean, i: Int): ExampleBean {
-				val eb = ExampleBean (...)
-				// some other operations...
-				return eb
-			}
-		}
-	}
----
-======
-
-Arguments to the `static` factory method are supplied by `<constructor-arg/>` elements,
-exactly the same as if a constructor had actually been used. The type of the class being
-returned by the factory method does not have to be of the same type as the class that
-contains the `static` factory method (although, in this example, it is). An instance
-(non-static) factory method can be used in an essentially identical fashion (aside
-from the use of the `factory-bean` attribute instead of the `class` attribute), so we
-do not discuss those details here.
-
-
-
@@ -1,40 +0,0 @@
-[[beans-factory-dependson]]
-= Using `depends-on`
-
-If a bean is a dependency of another bean, that usually means that one bean is set as a
-property of another. Typically you accomplish this with the <<beans-ref-element, `<ref/>`
-element>> in XML-based configuration metadata. However, sometimes dependencies between
-beans are less direct. An example is when a static initializer in a class needs to be
-triggered, such as for database driver registration. The `depends-on` attribute can
-explicitly force one or more beans to be initialized before the bean using this element
-is initialized. The following example uses the `depends-on` attribute to express a
-dependency on a single bean:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="beanOne" class="ExampleBean" depends-on="manager"/>
-	<bean id="manager" class="ManagerBean" />
----
-
-To express a dependency on multiple beans, supply a list of bean names as the value of
-the `depends-on` attribute (commas, whitespace, and semicolons are valid
-delimiters):
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="beanOne" class="ExampleBean" depends-on="manager,accountDao">
-		<property name="manager" ref="manager" />
-	</bean>
-
-	<bean id="manager" class="ManagerBean" />
-	<bean id="accountDao" class="x.y.jdbc.JdbcAccountDao" />
----
-
-NOTE: The `depends-on` attribute can specify both an initialization-time dependency and,
-in the case of xref:core/beans/factory-scopes.adoc#beans-factory-scopes-singleton[singleton] beans only, a corresponding
-destruction-time dependency. Dependent beans that define a `depends-on` relationship
-with a given bean are destroyed first, prior to the given bean itself being destroyed.
-Thus, `depends-on` can also control shutdown order.
-
-
-
@@ -1,42 +0,0 @@
-[[beans-factory-lazy-init]]
-= Lazy-initialized Beans
-
-By default, `ApplicationContext` implementations eagerly create and configure all
-xref:core/beans/factory-scopes.adoc#beans-factory-scopes-singleton[singleton] beans as part of the initialization
-process. Generally, this pre-instantiation is desirable, because errors in the
-configuration or surrounding environment are discovered immediately, as opposed to hours
-or even days later. When this behavior is not desirable, you can prevent
-pre-instantiation of a singleton bean by marking the bean definition as being
-lazy-initialized. A lazy-initialized bean tells the IoC container to create a bean
-instance when it is first requested, rather than at startup.
-
-In XML, this behavior is controlled by the `lazy-init` attribute on the `<bean/>`
-element, as the following example shows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="lazy" class="com.something.ExpensiveToCreateBean" lazy-init="true"/>
-	<bean name="not.lazy" class="com.something.AnotherBean"/>
----
-
-When the preceding configuration is consumed by an `ApplicationContext`, the `lazy` bean
-is not eagerly pre-instantiated when the `ApplicationContext` starts,
-whereas the `not.lazy` bean is eagerly pre-instantiated.
-
-However, when a lazy-initialized bean is a dependency of a singleton bean that is
-not lazy-initialized, the `ApplicationContext` creates the lazy-initialized bean at
-startup, because it must satisfy the singleton's dependencies. The lazy-initialized bean
-is injected into a singleton bean elsewhere that is not lazy-initialized.
-
-You can also control lazy-initialization at the container level by using the
-`default-lazy-init` attribute on the `<beans/>` element, as the following example shows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<beans default-lazy-init="true">
-		<!-- no beans will be pre-instantiated... -->
-	</beans>
----
-
-
-
@@ -1,434 +0,0 @@
-[[beans-factory-method-injection]]
-= Method Injection
-
-In most application scenarios, most beans in the container are
-xref:core/beans/factory-scopes.adoc#beans-factory-scopes-singleton[singletons]. When a singleton bean needs to
-collaborate with another singleton bean or a non-singleton bean needs to collaborate
-with another non-singleton bean, you typically handle the dependency by defining one
-bean as a property of the other. A problem arises when the bean lifecycles are
-different. Suppose singleton bean A needs to use non-singleton (prototype) bean B,
-perhaps on each method invocation on A. The container creates the singleton bean A only
-once, and thus only gets one opportunity to set the properties. The container cannot
-provide bean A with a new instance of bean B every time one is needed.
-
-A solution is to forego some inversion of control. You can xref:core/beans/factory-nature.adoc#beans-factory-aware[make bean A aware of the container]
- by implementing the `ApplicationContextAware` interface,
-and by xref:core/beans/basics.adoc#beans-factory-client[making a `getBean("B")` call to the container] ask for (a
-typically new) bean B instance every time bean A needs it. The following example
-shows this approach:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary",chomp="-packages",fold="none"]
----
-	package fiona.apple;
-
-	// Spring-API imports
-	import org.springframework.beans.BeansException;
-	import org.springframework.context.ApplicationContext;
-	import org.springframework.context.ApplicationContextAware;
-
-	/**
-	 * A class that uses a stateful Command-style class to perform
-	 * some processing.
-	 */
-	public class CommandManager implements ApplicationContextAware {
-
-		private ApplicationContext applicationContext;
-
-		public Object process(Map commandState) {
-			// grab a new instance of the appropriate Command
-			Command command = createCommand();
-			// set the state on the (hopefully brand new) Command instance
-			command.setState(commandState);
-			return command.execute();
-		}
-
-		protected Command createCommand() {
-			// notice the Spring API dependency!
-			return this.applicationContext.getBean("command", Command.class);
-		}
-
-		public void setApplicationContext(
-				ApplicationContext applicationContext) throws BeansException {
-			this.applicationContext = applicationContext;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary",chomp="-packages",fold="none"]
----
-	package fiona.apple
-
-	// Spring-API imports
-	import org.springframework.context.ApplicationContext
-	import org.springframework.context.ApplicationContextAware
-
-	// A class that uses a stateful Command-style class to perform
-	// some processing.
-	class CommandManager : ApplicationContextAware {
-
-		private lateinit var applicationContext: ApplicationContext
-
-		fun process(commandState: Map<*, *>): Any {
-			// grab a new instance of the appropriate Command
-			val command = createCommand()
-			// set the state on the (hopefully brand new) Command instance
-			command.state = commandState
-			return command.execute()
-		}
-
-		// notice the Spring API dependency!
-		protected fun createCommand() =
-				applicationContext.getBean("command", Command::class.java)
-
-		override fun setApplicationContext(applicationContext: ApplicationContext) {
-			this.applicationContext = applicationContext
-		}
-	}
----
-======
-
-The preceding is not desirable, because the business code is aware of and coupled to the
-Spring Framework. Method Injection, a somewhat advanced feature of the Spring IoC
-container, lets you handle this use case cleanly.
-
-****
-You can read more about the motivation for Method Injection in
-{spring-site-blog}/2004/08/06/method-injection/[this blog entry].
-****
-
-
-
-[[beans-factory-lookup-method-injection]]
-== Lookup Method Injection
-
-Lookup method injection is the ability of the container to override methods on
-container-managed beans and return the lookup result for another named bean in the
-container. The lookup typically involves a prototype bean, as in the scenario described
-in xref:core/beans/dependencies/factory-method-injection.adoc[the preceding section]. The Spring Framework
-implements this method injection by using bytecode generation from the CGLIB library to
-dynamically generate a subclass that overrides the method.
-
-[NOTE]
-====
-* For this dynamic subclassing to work, the class that the Spring bean container
-  subclasses cannot be `final`, and the method to be overridden cannot be `final`, either.
-* Unit-testing a class that has an `abstract` method requires you to subclass the class
-  yourself and to supply a stub implementation of the `abstract` method.
-* Concrete methods are also necessary for component scanning, which requires concrete
-  classes to pick up.
-* A further key limitation is that lookup methods do not work with factory methods and
-  in particular not with `@Bean` methods in configuration classes, since, in that case,
-  the container is not in charge of creating the instance and therefore cannot create
-  a runtime-generated subclass on the fly.
-====
-
-In the case of the `CommandManager` class in the previous code snippet, the
-Spring container dynamically overrides the implementation of the `createCommand()`
-method. The `CommandManager` class does not have any Spring dependencies, as
-the reworked example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary",chomp="-packages",fold="none"]
----
-	package fiona.apple;
-
-	// no more Spring imports!
-
-	public abstract class CommandManager {
-
-		public Object process(Object commandState) {
-			// grab a new instance of the appropriate Command interface
-			Command command = createCommand();
-			// set the state on the (hopefully brand new) Command instance
-			command.setState(commandState);
-			return command.execute();
-		}
-
-		// okay... but where is the implementation of this method?
-		protected abstract Command createCommand();
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary",chomp="-packages",fold="none"]
----
-	package fiona.apple
-
-	// no more Spring imports!
-
-	abstract class CommandManager {
-
-		fun process(commandState: Any): Any {
-			// grab a new instance of the appropriate Command interface
-			val command = createCommand()
-			// set the state on the (hopefully brand new) Command instance
-			command.state = commandState
-			return command.execute()
-		}
-
-		// okay... but where is the implementation of this method?
-		protected abstract fun createCommand(): Command
-	}
----
-======
-
-In the client class that contains the method to be injected (the `CommandManager` in this
-case), the method to be injected requires a signature of the following form:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<public|protected> [abstract] <return-type> theMethodName(no-arguments);
----
-
-If the method is `abstract`, the dynamically-generated subclass implements the method.
-Otherwise, the dynamically-generated subclass overrides the concrete method defined in
-the original class. Consider the following example:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- a stateful bean deployed as a prototype (non-singleton) -->
-	<bean id="myCommand" class="fiona.apple.AsyncCommand" scope="prototype">
-		<!-- inject dependencies here as required -->
-	</bean>
-
-	<!-- commandProcessor uses statefulCommandHelper -->
-	<bean id="commandManager" class="fiona.apple.CommandManager">
-		<lookup-method name="createCommand" bean="myCommand"/>
-	</bean>
----
-
-The bean identified as `commandManager` calls its own `createCommand()` method
-whenever it needs a new instance of the `myCommand` bean. You must be careful to deploy
-the `myCommand` bean as a prototype if that is actually what is needed. If it is
-a xref:core/beans/factory-scopes.adoc#beans-factory-scopes-singleton[singleton], the same instance of the `myCommand`
-bean is returned each time.
-
-Alternatively, within the annotation-based component model, you can declare a lookup
-method through the `@Lookup` annotation, as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public abstract class CommandManager {
-
-		public Object process(Object commandState) {
-			Command command = createCommand();
-			command.setState(commandState);
-			return command.execute();
-		}
-
-		@Lookup("myCommand")
-		protected abstract Command createCommand();
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	abstract class CommandManager {
-
-		fun process(commandState: Any): Any {
-			val command = createCommand()
-			command.state = commandState
-			return command.execute()
-		}
-
-		@Lookup("myCommand")
-		protected abstract fun createCommand(): Command
-	}
----
-======
-
-Or, more idiomatically, you can rely on the target bean getting resolved against the
-declared return type of the lookup method:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public abstract class CommandManager {
-
-		public Object process(Object commandState) {
-			Command command = createCommand();
-			command.setState(commandState);
-			return command.execute();
-		}
-
-		@Lookup
-		protected abstract Command createCommand();
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	abstract class CommandManager {
-
-		fun process(commandState: Any): Any {
-			val command = createCommand()
-			command.state = commandState
-			return command.execute()
-		}
-
-		@Lookup
-		protected abstract fun createCommand(): Command
-	}
----
-======
-
-Note that you should typically declare such annotated lookup methods with a concrete
-stub implementation, in order for them to be compatible with Spring's component
-scanning rules where abstract classes get ignored by default. This limitation does not
-apply to explicitly registered or explicitly imported bean classes.
-
-[TIP]
-====
-Another way of accessing differently scoped target beans is an `ObjectFactory`/
-`Provider` injection point. See xref:core/beans/factory-scopes.adoc#beans-factory-scopes-other-injection[Scoped Beans as Dependencies].
-
-You may also find the `ServiceLocatorFactoryBean` (in the
-`org.springframework.beans.factory.config` package) to be useful.
-====
-
-
-
-[[beans-factory-arbitrary-method-replacement]]
-== Arbitrary Method Replacement
-
-A less useful form of method injection than lookup method injection is the ability to
-replace arbitrary methods in a managed bean with another method implementation. You
-can safely skip the rest of this section until you actually need this functionality.
-
-With XML-based configuration metadata, you can use the `replaced-method` element to
-replace an existing method implementation with another, for a deployed bean. Consider
-the following class, which has a method called `computeValue` that we want to override:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class MyValueCalculator {
-
-		public String computeValue(String input) {
-			// some real code...
-		}
-
-		// some other methods...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class MyValueCalculator {
-
-		fun computeValue(input: String): String {
-			// some real code...
-		}
-
-		// some other methods...
-	}
----
-======
-
-A class that implements the `org.springframework.beans.factory.support.MethodReplacer`
-interface provides the new method definition, as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	/**
-	 * meant to be used to override the existing computeValue(String)
-	 * implementation in MyValueCalculator
-	 */
-	public class ReplacementComputeValue implements MethodReplacer {
-
-		public Object reimplement(Object o, Method m, Object[] args) throws Throwable {
-			// get the input value, work with it, and return a computed result
-			String input = (String) args[0];
-			...
-			return ...;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	/**
-	 * 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 {
-			// get the input value, work with it, and return a computed result
-			val input = args[0] as String;
-			...
-			return ...;
-		}
-	}
----
-======
-
-
-
-The bean definition to deploy the original class and specify the method override would
-resemble the following example:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="myValueCalculator" class="x.y.z.MyValueCalculator">
-		<!-- arbitrary method replacement -->
-		<replaced-method name="computeValue" replacer="replacementComputeValue">
-			<arg-type>String</arg-type>
-		</replaced-method>
-	</bean>
-
-	<bean id="replacementComputeValue" class="a.b.c.ReplacementComputeValue"/>
----
-
-You can use one or more `<arg-type/>` elements within the `<replaced-method/>`
-element to indicate the method signature of the method being overridden. The signature
-for the arguments is necessary only if the method is overloaded and multiple variants
-exist within the class. For convenience, the type string for an argument may be a
-substring of the fully qualified type name. For example, the following all match
-`java.lang.String`:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	java.lang.String
-	String
-	Str
----
-
-Because the number of arguments is often enough to distinguish between each possible
-choice, this shortcut can save a lot of typing, by letting you type only the
-shortest string that matches an argument type.
-
-
-
@@ -1,626 +0,0 @@
-[[beans-factory-properties-detailed]]
-= Dependencies and Configuration in Detail
-
-As mentioned in the xref:core/beans/dependencies/factory-collaborators.adoc[previous section], you can define bean
-properties and constructor arguments as references to other managed beans (collaborators)
-or as values defined inline. Spring's XML-based configuration metadata supports
-sub-element types within its `<property/>` and `<constructor-arg/>` elements for this
-purpose.
-
-
-[[beans-value-element]]
-== Straight Values (Primitives, Strings, and so on)
-
-The `value` attribute of the `<property/>` element specifies a property or constructor
-argument as a human-readable string representation. Spring's
-xref:core/validation/convert.adoc#core-convert-ConversionService-API[conversion service] is used to convert these
-values from a `String` to the actual type of the property or argument.
-The following example shows various values being set:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
-		<!-- results in a setDriverClassName(String) call -->
-		<property name="driverClassName" value="com.mysql.jdbc.Driver"/>
-		<property name="url" value="jdbc:mysql://localhost:3306/mydb"/>
-		<property name="username" value="root"/>
-		<property name="password" value="misterkaoli"/>
-	</bean>
----
-
-The following example uses the xref:core/beans/dependencies/factory-properties-detailed.adoc#beans-p-namespace[p-namespace] for even more succinct
-XML configuration:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:p="http://www.springframework.org/schema/p"
-		xsi:schemaLocation="http://www.springframework.org/schema/beans
-		https://www.springframework.org/schema/beans/spring-beans.xsd">
-
-		<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource"
-			destroy-method="close"
-			p:driverClassName="com.mysql.jdbc.Driver"
-			p:url="jdbc:mysql://localhost:3306/mydb"
-			p:username="root"
-			p:password="misterkaoli"/>
-
-	</beans>
----
-
-The preceding XML is more succinct. However, typos are discovered at runtime rather than
-design time, unless you use an IDE (such as https://www.jetbrains.com/idea/[IntelliJ
-IDEA] or the {spring-site-tools}[Spring Tools for Eclipse])
-that supports automatic property completion when you create bean definitions. Such IDE
-assistance is highly recommended.
-
-You can also configure a `java.util.Properties` instance, as follows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="mappings"
-		class="org.springframework.context.support.PropertySourcesPlaceholderConfigurer">
-
-		<!-- typed as a java.util.Properties -->
-		<property name="properties">
-			<value>
-				jdbc.driver.className=com.mysql.jdbc.Driver
-				jdbc.url=jdbc:mysql://localhost:3306/mydb
-			</value>
-		</property>
-	</bean>
----
-
-The Spring container converts the text inside the `<value/>` element into a
-`java.util.Properties` instance by using the JavaBeans `PropertyEditor` mechanism. This
-is a nice shortcut, and is one of a few places where the Spring team do favor the use of
-the nested `<value/>` element over the `value` attribute style.
-
-[[beans-idref-element]]
-=== The `idref` element
-
-The `idref` element is simply an error-proof way to pass the `id` (a string value - not
-a reference) of another bean in the container to a `<constructor-arg/>` or `<property/>`
-element. The following example shows how to use it:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="theTargetBean" class="..."/>
-
-	<bean id="theClientBean" class="...">
-		<property name="targetName">
-			<idref bean="theTargetBean"/>
-		</property>
-	</bean>
----
-
-The preceding bean definition snippet is exactly equivalent (at runtime) to the
-following snippet:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="theTargetBean" class="..." />
-
-	<bean id="client" class="...">
-		<property name="targetName" value="theTargetBean"/>
-	</bean>
----
-
-The first form is preferable to the second, because using the `idref` tag lets the
-container validate at deployment time that the referenced, named bean actually
-exists. In the second variation, no validation is performed on the value that is passed
-to the `targetName` property of the `client` bean. Typos are only discovered (with most
-likely fatal results) when the `client` bean is actually instantiated. If the `client`
-bean is a xref:core/beans/factory-scopes.adoc[prototype] bean, this typo and the resulting exception
-may only be discovered long after the container is deployed.
-
-NOTE: The `local` attribute on the `idref` element is no longer supported in the 4.0 beans
-XSD, since it does not provide value over a regular `bean` reference any more. Change
-your existing `idref local` references to `idref bean` when upgrading to the 4.0 schema.
-
-A common place (at least in versions earlier than Spring 2.0) where the `<idref/>` element
-brings value is in the configuration of xref:core/aop-api/pfb.adoc#aop-pfb-1[AOP interceptors] in a
-`ProxyFactoryBean` bean definition. Using `<idref/>` elements when you specify the
-interceptor names prevents you from misspelling an interceptor ID.
-
-
-[[beans-ref-element]]
-== References to Other Beans (Collaborators)
-
-The `ref` element is the final element inside a `<constructor-arg/>` or `<property/>`
-definition element. Here, you set the value of the specified property of a bean to be a
-reference to another bean (a collaborator) managed by the container. The referenced bean
-is a dependency of the bean whose property is to be set, and it is initialized on demand
-as needed before the property is set. (If the collaborator is a singleton bean, it may
-already be initialized by the container.) All references are ultimately a reference to
-another object. Scoping and validation depend on whether you specify the ID or name of the
-other object through the `bean` or `parent` attribute.
-
-Specifying the target bean through the `bean` attribute of the `<ref/>` tag is the most
-general form and allows creation of a reference to any bean in the same container or
-parent container, regardless of whether it is in the same XML file. The value of the
-`bean` attribute may be the same as the `id` attribute of the target bean or be the same
-as one of the values in the `name` attribute of the target bean. The following example
-shows how to use a `ref` element:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<ref bean="someBean"/>
----
-
-Specifying the target bean through the `parent` attribute creates a reference to a bean
-that is in a parent container of the current container. The value of the `parent`
-attribute may be the same as either the `id` attribute of the target bean or one of the
-values in the `name` attribute of the target bean. The target bean must be in a
-parent container of the current one. You should use this bean reference variant mainly
-when you have a hierarchy of containers and you want to wrap an existing bean in a parent
-container with a proxy that has the same name as the parent bean. The following pair of
-listings shows how to use the `parent` attribute:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- in the parent context -->
-	<bean id="accountService" class="com.something.SimpleAccountService">
-		<!-- insert dependencies as required here -->
-	</bean>
----
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- in the child (descendant) context -->
-	<bean id="accountService" <!-- bean name is the same as the parent bean -->
-		class="org.springframework.aop.framework.ProxyFactoryBean">
-		<property name="target">
-			<ref parent="accountService"/> <!-- notice how we refer to the parent bean -->
-		</property>
-		<!-- insert other configuration and dependencies as required here -->
-	</bean>
----
-
-NOTE: The `local` attribute on the `ref` element is no longer supported in the 4.0 beans
-XSD, since it does not provide value over a regular `bean` reference any more. Change
-your existing `ref local` references to `ref bean` when upgrading to the 4.0 schema.
-
-
-[[beans-inner-beans]]
-== Inner Beans
-
-A `<bean/>` element inside the `<property/>` or `<constructor-arg/>` elements defines an
-inner bean, as the following example shows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="outer" class="...">
-		<!-- instead of using a reference to a target bean, simply define the target bean inline -->
-		<property name="target">
-			<bean class="com.example.Person"> <!-- this is the inner bean -->
-				<property name="name" value="Fiona Apple"/>
-				<property name="age" value="25"/>
-			</bean>
-		</property>
-	</bean>
----
-
-An inner bean definition does not require a defined ID or name. If specified, the container
-does not use such a value as an identifier. The container also ignores the `scope` flag on
-creation, because inner beans are always anonymous and are always created with the outer
-bean. It is not possible to access inner beans independently or to inject them into
-collaborating beans other than into the enclosing bean.
-
-As a corner case, it is possible to receive destruction callbacks from a custom scope --
-for example, for a request-scoped inner bean contained within a singleton bean. The creation
-of the inner bean instance is tied to its containing bean, but destruction callbacks let it
-participate in the request scope's lifecycle. This is not a common scenario. Inner beans
-typically simply share their containing bean's scope.
-
-
-[[beans-collection-elements]]
-== Collections
-
-The `<list/>`, `<set/>`, `<map/>`, and `<props/>` elements set the properties
-and arguments of the Java `Collection` types `List`, `Set`, `Map`, and `Properties`,
-respectively. The following example shows how to use them:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="moreComplexObject" class="example.ComplexObject">
-		<!-- results in a setAdminEmails(java.util.Properties) call -->
-		<property name="adminEmails">
-			<props>
-				<prop key="administrator">administrator@example.org</prop>
-				<prop key="support">support@example.org</prop>
-				<prop key="development">development@example.org</prop>
-			</props>
-		</property>
-		<!-- results in a setSomeList(java.util.List) call -->
-		<property name="someList">
-			<list>
-				<value>a list element followed by a reference</value>
-				<ref bean="myDataSource" />
-			</list>
-		</property>
-		<!-- results in a setSomeMap(java.util.Map) call -->
-		<property name="someMap">
-			<map>
-				<entry key="an entry" value="just some string"/>
-				<entry key="a ref" value-ref="myDataSource"/>
-			</map>
-		</property>
-		<!-- results in a setSomeSet(java.util.Set) call -->
-		<property name="someSet">
-			<set>
-				<value>just some string</value>
-				<ref bean="myDataSource" />
-			</set>
-		</property>
-	</bean>
----
-
-The value of a map key or value, or a set value, can also be any of the
-following elements:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	bean | ref | idref | list | set | map | props | value | null
----
-
-[[beans-collection-elements-merging]]
-=== Collection Merging
-
-The Spring container also supports merging collections. An application
-developer can define a parent `<list/>`, `<map/>`, `<set/>` or `<props/>` element
-and have child `<list/>`, `<map/>`, `<set/>` or `<props/>` elements inherit and
-override values from the parent collection. That is, the child collection's values are
-the result of merging the elements of the parent and child collections, with the child's
-collection elements overriding values specified in the parent collection.
-
-This section on merging discusses the parent-child bean mechanism. Readers unfamiliar
-with parent and child bean definitions may wish to read the
-xref:core/beans/child-bean-definitions.adoc[relevant section] before continuing.
-
-The following example demonstrates collection merging:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<beans>
-		<bean id="parent" abstract="true" class="example.ComplexObject">
-			<property name="adminEmails">
-				<props>
-					<prop key="administrator">administrator@example.com</prop>
-					<prop key="support">support@example.com</prop>
-				</props>
-			</property>
-		</bean>
-		<bean id="child" parent="parent">
-			<property name="adminEmails">
-				<!-- the merge is specified on the child collection definition -->
-				<props merge="true">
-					<prop key="sales">sales@example.com</prop>
-					<prop key="support">support@example.co.uk</prop>
-				</props>
-			</property>
-		</bean>
-	<beans>
----
-
-Notice the use of the `merge=true` attribute on the `<props/>` element of the
-`adminEmails` property of the `child` bean definition. When the `child` bean is resolved
-and instantiated by the container, the resulting instance has an `adminEmails`
-`Properties` collection that contains the result of merging the child's
-`adminEmails` collection with the parent's `adminEmails` collection. The following listing
-shows the result:
-
-[literal,subs="verbatim,quotes"]
----
-administrator=administrator@example.com
-sales=sales@example.com
-support=support@example.co.uk
----
-
-The child `Properties` collection's value set inherits all property elements from the
-parent `<props/>`, and the child's value for the `support` value overrides the value in
-the parent collection.
-
-This merging behavior applies similarly to the `<list/>`, `<map/>`, and `<set/>`
-collection types. In the specific case of the `<list/>` element, the semantics
-associated with the `List` collection type (that is, the notion of an `ordered`
-collection of values) is maintained. The parent's values precede all of the child list's
-values. In the case of the `Map`, `Set`, and `Properties` collection types, no ordering
-exists. Hence, no ordering semantics are in effect for the collection types that underlie
-the associated `Map`, `Set`, and `Properties` implementation types that the container
-uses internally.
-
-[[beans-collection-merge-limitations]]
-=== Limitations of Collection Merging
-
-You cannot merge different collection types (such as a `Map` and a `List`). If you
-do attempt to do so, an appropriate `Exception` is thrown. The `merge` attribute must be
-specified on the lower, inherited, child definition. Specifying the `merge` attribute on
-a parent collection definition is redundant and does not result in the desired merging.
-
-[[beans-collection-elements-strongly-typed]]
-=== Strongly-typed collection
-
-Thanks to Java's support for generic types, you can use strongly typed collections.
-That is, it is possible to declare a `Collection` type such that it can only contain
-(for example) `String` elements. If you use Spring to dependency-inject a
-strongly-typed `Collection` into a bean, you can take advantage of Spring's
-type-conversion support such that the elements of your strongly-typed `Collection`
-instances are converted to the appropriate type prior to being added to the `Collection`.
-The following Java class and bean definition show how to do so:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class SomeClass {
-
-		private Map<String, Float> accounts;
-
-		public void setAccounts(Map<String, Float> accounts) {
-			this.accounts = accounts;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-class SomeClass {
-	lateinit var accounts: Map<String, Float>
-}
----
-======
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<beans>
-		<bean id="something" class="x.y.SomeClass">
-			<property name="accounts">
-				<map>
-					<entry key="one" value="9.99"/>
-					<entry key="two" value="2.75"/>
-					<entry key="six" value="3.99"/>
-				</map>
-			</property>
-		</bean>
-	</beans>
----
-
-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
-`3.99`) are converted into an actual `Float` type.
-
-
-[[beans-null-element]]
-== Null and Empty String Values
-
-Spring treats empty arguments for properties and the like as empty `Strings`. The
-following XML-based configuration metadata snippet sets the `email` property to the empty
-`String` value ("").
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean class="ExampleBean">
-		<property name="email" value=""/>
-	</bean>
----
-
-The preceding example is equivalent to the following Java code:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	exampleBean.setEmail("");
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	exampleBean.email = ""
----
-======
-
-
-The `<null/>` element handles `null` values. The following listing shows an example:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean class="ExampleBean">
-		<property name="email">
-			<null/>
-		</property>
-	</bean>
----
-
-The preceding configuration is equivalent to the following Java code:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	exampleBean.setEmail(null);
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	exampleBean.email = null
----
-======
-
-
-[[beans-p-namespace]]
-== XML Shortcut with the p-namespace
-
-The p-namespace lets you use the `bean` element's attributes (instead of nested
-`<property/>` elements) to describe your property values collaborating beans, or both.
-
-Spring supports extensible configuration formats xref:core/appendix/xsd-schemas.adoc[with namespaces],
-which are based on an XML Schema definition. The `beans` configuration format discussed in
-this chapter is defined in an XML Schema document. However, the p-namespace is not defined
-in an XSD file and exists only in the core of Spring.
-
-The following example shows two XML snippets (the first uses
-standard XML format and the second uses the p-namespace) that resolve to the same result:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:p="http://www.springframework.org/schema/p"
-		xsi:schemaLocation="http://www.springframework.org/schema/beans
-			https://www.springframework.org/schema/beans/spring-beans.xsd">
-
-		<bean name="classic" class="com.example.ExampleBean">
-			<property name="email" value="someone@somewhere.com"/>
-		</bean>
-
-		<bean name="p-namespace" class="com.example.ExampleBean"
-			p:email="someone@somewhere.com"/>
-	</beans>
----
-
-The example shows an attribute in the p-namespace called `email` in the bean definition.
-This tells Spring to include a property declaration. As previously mentioned, the
-p-namespace does not have a schema definition, so you can set the name of the attribute
-to the property name.
-
-This next example includes two more bean definitions that both have a reference to
-another bean:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:p="http://www.springframework.org/schema/p"
-		xsi:schemaLocation="http://www.springframework.org/schema/beans
-			https://www.springframework.org/schema/beans/spring-beans.xsd">
-
-		<bean name="john-classic" class="com.example.Person">
-			<property name="name" value="John Doe"/>
-			<property name="spouse" ref="jane"/>
-		</bean>
-
-		<bean name="john-modern"
-			class="com.example.Person"
-			p:name="John Doe"
-			p:spouse-ref="jane"/>
-
-		<bean name="jane" class="com.example.Person">
-			<property name="name" value="Jane Doe"/>
-		</bean>
-	</beans>
----
-
-This example includes not only a property value using the p-namespace
-but also uses a special format to declare property references. Whereas the first bean
-definition uses `<property name="spouse" ref="jane"/>` to create a reference from bean
-`john` to bean `jane`, the second bean definition uses `p:spouse-ref="jane"` as an
-attribute to do the exact same thing. In this case, `spouse` is the property name,
-whereas the `-ref` part indicates that this is not a straight value but rather a
-reference to another bean.
-
-NOTE: The p-namespace is not as flexible as the standard XML format. For example, the format
-for declaring property references clashes with properties that end in `Ref`, whereas the
-standard XML format does not. We recommend that you choose your approach carefully and
-communicate this to your team members to avoid producing XML documents that use all
-three approaches at the same time.
-
-
-[[beans-c-namespace]]
-== XML Shortcut with the c-namespace
-
-Similar to the xref:core/beans/dependencies/factory-properties-detailed.adoc#beans-p-namespace[XML Shortcut with the p-namespace], the c-namespace, introduced in Spring
-3.1, allows inlined attributes for configuring the constructor arguments rather
-then nested `constructor-arg` elements.
-
-The following example uses the `c:` namespace to do the same thing as the from
-xref:core/beans/dependencies/factory-collaborators.adoc#beans-constructor-injection[Constructor-based Dependency Injection]:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:c="http://www.springframework.org/schema/c"
-		xsi:schemaLocation="http://www.springframework.org/schema/beans
-			https://www.springframework.org/schema/beans/spring-beans.xsd">
-
-		<bean id="beanTwo" class="x.y.ThingTwo"/>
-		<bean id="beanThree" class="x.y.ThingThree"/>
-
-		<!-- traditional declaration with optional argument names -->
-		<bean id="beanOne" class="x.y.ThingOne">
-			<constructor-arg name="thingTwo" ref="beanTwo"/>
-			<constructor-arg name="thingThree" ref="beanThree"/>
-			<constructor-arg name="email" value="something@somewhere.com"/>
-		</bean>
-
-		<!-- c-namespace declaration with argument names -->
-		<bean id="beanOne" class="x.y.ThingOne" c:thingTwo-ref="beanTwo"
-			c:thingThree-ref="beanThree" c:email="something@somewhere.com"/>
-
-	</beans>
----
-
-The `c:` namespace uses the same conventions as the `p:` one (a trailing `-ref` for
-bean references) for setting the constructor arguments by their names. Similarly,
-it needs to be declared in the XML file even though it is not defined in an XSD schema
-(it exists inside the Spring core).
-
-For the rare cases where the constructor argument names are not available (usually if
-the bytecode was compiled without debugging information), you can use fallback to the
-argument indexes, as follows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- c-namespace index declaration -->
-	<bean id="beanOne" class="x.y.ThingOne" c:_0-ref="beanTwo" c:_1-ref="beanThree"
-		c:_2="something@somewhere.com"/>
----
-
-NOTE: Due to the XML grammar, the index notation requires the presence of the leading `_`,
-as XML attribute names cannot start with a number (even though some IDEs allow it).
-A corresponding index notation is also available for `<constructor-arg>` elements but
-not commonly used since the plain order of declaration is usually sufficient there.
-
-In practice, the constructor resolution
-xref:core/beans/dependencies/factory-collaborators.adoc#beans-factory-ctor-arguments-resolution[mechanism] is quite efficient in matching
-arguments, so unless you really need to, we recommend using the name notation
-throughout your configuration.
-
-
-[[beans-compound-property-names]]
-== Compound Property Names
-
-You can use compound or nested property names when you set bean properties, as long as
-all components of the path except the final property name are not `null`. Consider the
-following bean definition:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="something" class="things.ThingOne">
-		<property name="fred.bob.sammy" value="123" />
-	</bean>
----
-
-The `something` bean has a `fred` property, which has a `bob` property, which has a `sammy`
-property, and that final `sammy` property is being set to a value of `123`. In order for
-this to work, the `fred` property of `something` and the `bob` property of `fred` must not
-be `null` after the bean is constructed. Otherwise, a `NullPointerException` is thrown.
-
-
-
@@ -1,804 +0,0 @@
-[[beans-environment]]
-= Environment Abstraction
-
-The {spring-framework-api}/core/env/Environment.html[`Environment`] interface
-is an abstraction integrated in the container that models two key
-aspects of the application environment: xref:core/beans/environment.adoc#beans-definition-profiles[profiles]
-and xref:core/beans/environment.adoc#beans-property-source-abstraction[properties].
-
-A profile is a named, logical group of bean definitions to be registered with the
-container only if the given profile is active. Beans may be assigned to a profile
-whether defined in XML or with annotations. The role of the `Environment` object with
-relation to profiles is in determining which profiles (if any) are currently active,
-and which profiles (if any) should be active by default.
-
-Properties play an important role in almost all applications and may originate from
-a variety of sources: properties files, JVM system properties, system environment
-variables, JNDI, servlet context parameters, ad-hoc `Properties` objects, `Map` objects, and so
-on. The role of the `Environment` object with relation to properties is to provide the
-user with a convenient service interface for configuring property sources and resolving
-properties from them.
-
-
-
-[[beans-definition-profiles]]
-== Bean Definition Profiles
-
-Bean definition profiles provide a mechanism in the core container that allows for
-registration of different beans in different environments. The word, "`environment,`"
-can mean different things to different users, and this feature can help with many
-use cases, including:
-
-* Working against an in-memory datasource in development versus looking up that same
-datasource from JNDI when in QA or production.
-* Registering monitoring infrastructure only when deploying an application into a
-performance environment.
-* Registering customized implementations of beans for customer A versus customer
-B deployments.
-
-Consider the first use case in a practical application that requires a
-`DataSource`. In a test environment, the configuration might resemble the following:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	@Bean
-	public DataSource dataSource() {
-		return new EmbeddedDatabaseBuilder()
-			.setType(EmbeddedDatabaseType.HSQL)
-			.addScript("my-schema.sql")
-			.addScript("my-test-data.sql")
-			.build();
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Bean
-	fun dataSource(): DataSource {
-		return EmbeddedDatabaseBuilder()
-				.setType(EmbeddedDatabaseType.HSQL)
-				.addScript("my-schema.sql")
-				.addScript("my-test-data.sql")
-				.build()
-	}
----
-======
-
-Now consider how this application can be deployed into a QA or production
-environment, assuming that the datasource for the application is registered
-with the production application server's JNDI directory. Our `dataSource` bean
-now looks like the following listing:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	@Bean(destroyMethod = "")
-	public DataSource dataSource() throws Exception {
-		Context ctx = new InitialContext();
-		return (DataSource) ctx.lookup("java:comp/env/jdbc/datasource");
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Bean(destroyMethod = "")
-	fun dataSource(): DataSource {
-		val ctx = InitialContext()
-		return ctx.lookup("java:comp/env/jdbc/datasource") as DataSource
-	}
----
-======
-
-The problem is how to switch between using these two variations based on the
-current environment. Over time, Spring users have devised a number of ways to
-get this done, usually relying on a combination of system environment variables
-and XML `<import/>` statements containing pass:q[`${placeholder}`] tokens that resolve
-to the correct configuration file path depending on the value of an environment
-variable. Bean definition profiles is a core container feature that provides a
-solution to this problem.
-
-If we generalize the use case shown in the preceding example of environment-specific bean
-definitions, we end up with the need to register certain bean definitions in
-certain contexts but not in others. You could say that you want to register a
-certain profile of bean definitions in situation A and a different profile in
-situation B. We start by updating our configuration to reflect this need.
-
-
-[[beans-definition-profiles-java]]
-=== Using `@Profile`
-
-The {spring-framework-api}/context/annotation/Profile.html[`@Profile`]
-annotation lets you indicate that a component is eligible for registration
-when one or more specified profiles are active. Using our preceding example, we
-can rewrite the `dataSource` configuration as follows:
-
--
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	@Configuration
-	@Profile("development")
-	public class StandaloneDataConfig {
-
-		@Bean
-		public DataSource dataSource() {
-			return new EmbeddedDatabaseBuilder()
-				.setType(EmbeddedDatabaseType.HSQL)
-				.addScript("classpath:com/bank/config/sql/schema.sql")
-				.addScript("classpath:com/bank/config/sql/test-data.sql")
-				.build();
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Configuration
-	@Profile("development")
-	class StandaloneDataConfig {
-
-		@Bean
-		fun dataSource(): DataSource {
-			return EmbeddedDatabaseBuilder()
-					.setType(EmbeddedDatabaseType.HSQL)
-					.addScript("classpath:com/bank/config/sql/schema.sql")
-					.addScript("classpath:com/bank/config/sql/test-data.sql")
-					.build()
-		}
-	}
----
-======
--
-
--
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	@Configuration
-	@Profile("production")
-	public class JndiDataConfig {
-
-		@Bean(destroyMethod = "") // <1>
-		public DataSource dataSource() throws Exception {
-			Context ctx = new InitialContext();
-			return (DataSource) ctx.lookup("java:comp/env/jdbc/datasource");
-		}
-	}
----
-<1> `@Bean(destroyMethod = "")` disables default destroy method inference.
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Configuration
-	@Profile("production")
-	class JndiDataConfig {
-
-		@Bean(destroyMethod = "") // <1>
-		fun dataSource(): DataSource {
-			val ctx = InitialContext()
-			return ctx.lookup("java:comp/env/jdbc/datasource") as DataSource
-		}
-	}
----
-<1> `@Bean(destroyMethod = "")` disables default destroy method inference.
-======
--
-
-NOTE: As mentioned earlier, with `@Bean` methods, you typically choose to use programmatic
-JNDI lookups, by using either Spring's `JndiTemplate`/`JndiLocatorDelegate` helpers or the
-straight JNDI `InitialContext` usage shown earlier but not the `JndiObjectFactoryBean`
-variant, which would force you to declare the return type as the `FactoryBean` type.
-
-The profile string may contain a simple profile name (for example, `production`) or a
-profile expression. A profile expression allows for more complicated profile logic to be
-expressed (for example, `production & us-east`). The following operators are supported in
-profile expressions:
-
-* `!`: A logical `NOT` of the profile
-* `&`: A logical `AND` of the profiles
-* `|`: A logical `OR` of the profiles
-
-NOTE: You cannot mix the `&` and `|` operators without using parentheses. For example,
-`production & us-east | eu-central` is not a valid expression. It must be expressed as
-`production & (us-east | eu-central)`.
-
-You can use `@Profile` as a xref:core/beans/classpath-scanning.adoc#beans-meta-annotations[meta-annotation] for the purpose
-of creating a custom composed annotation. The following example defines a custom
-`@Production` annotation that you can use as a drop-in replacement for
-`@Profile("production")`:
-
--
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	@Target(ElementType.TYPE)
-	@Retention(RetentionPolicy.RUNTIME)
-	@Profile("production")
-	public @interface Production {
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Target(AnnotationTarget.CLASS)
-	@Retention(AnnotationRetention.RUNTIME)
-	@Profile("production")
-	annotation class Production
----
-======
--
-
-TIP: If a `@Configuration` class is marked with `@Profile`, all of the `@Bean` methods and
-`@Import` annotations associated with that class are bypassed unless one or more of
-the specified profiles are active. If a `@Component` or `@Configuration` class is marked
-with `@Profile({"p1", "p2"})`, that class is not registered or processed unless
-profiles 'p1' or 'p2' have been activated. If a given profile is prefixed with the
-NOT operator (`!`), the annotated element is registered only if the profile is not
-active. For example, given `@Profile({"p1", "!p2"})`, registration will occur if profile
-'p1' is active or if profile 'p2' is not active.
-
-`@Profile` can also be declared at the method level to include only one particular bean
-of a configuration class (for example, for alternative variants of a particular bean), as
-the following example shows:
-
--
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	@Configuration
-	public class AppConfig {
-
-		@Bean("dataSource")
-		@Profile("development") // <1>
-		public DataSource standaloneDataSource() {
-			return new EmbeddedDatabaseBuilder()
-				.setType(EmbeddedDatabaseType.HSQL)
-				.addScript("classpath:com/bank/config/sql/schema.sql")
-				.addScript("classpath:com/bank/config/sql/test-data.sql")
-				.build();
-		}
-
-		@Bean("dataSource")
-		@Profile("production") // <2>
-		public DataSource jndiDataSource() throws Exception {
-			Context ctx = new InitialContext();
-			return (DataSource) ctx.lookup("java:comp/env/jdbc/datasource");
-		}
-	}
----
-<1> The `standaloneDataSource` method is available only in the `development` profile.
-<2> The `jndiDataSource` method is available only in the `production` profile.
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Configuration
-	class AppConfig {
-
-		@Bean("dataSource")
-		@Profile("development") // <1>
-		fun standaloneDataSource(): DataSource {
-			return EmbeddedDatabaseBuilder()
-					.setType(EmbeddedDatabaseType.HSQL)
-					.addScript("classpath:com/bank/config/sql/schema.sql")
-					.addScript("classpath:com/bank/config/sql/test-data.sql")
-					.build()
-		}
-
-		@Bean("dataSource")
-		@Profile("production") // <2>
-		fun jndiDataSource() =
-			InitialContext().lookup("java:comp/env/jdbc/datasource") as DataSource
-	}
----
-<1> The `standaloneDataSource` method is available only in the `development` profile.
-<2> The `jndiDataSource` method is available only in the `production` profile.
-======
--
-
-[NOTE]
-====
-With `@Profile` on `@Bean` methods, a special scenario may apply: In the case of
-overloaded `@Bean` methods of the same Java method name (analogous to constructor
-overloading), a `@Profile` condition needs to be consistently declared on all
-overloaded methods. If the conditions are inconsistent, only the condition on the
-first declaration among the overloaded methods matters. Therefore, `@Profile` can
-not be used to select an overloaded method with a particular argument signature over
-another. Resolution between all factory methods for the same bean follows Spring's
-constructor resolution algorithm at creation time.
-
-If you want to define alternative beans with different profile conditions,
-use distinct Java method names that point to the same bean name by using the `@Bean` name
-attribute, as shown in the preceding example. If the argument signatures are all
-the same (for example, all of the variants have no-arg factory methods), this is the only
-way to represent such an arrangement in a valid Java class in the first place
-(since there can only be one method of a particular name and argument signature).
-====
-
-
-[[beans-definition-profiles-xml]]
-=== XML Bean Definition Profiles
-
-The XML counterpart is the `profile` attribute of the `<beans>` element. Our preceding sample
-configuration can be rewritten in two XML files, as follows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<beans profile="development"
-		xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:jdbc="http://www.springframework.org/schema/jdbc"
-		xsi:schemaLocation="...">
-
-		<jdbc:embedded-database id="dataSource">
-			<jdbc:script location="classpath:com/bank/config/sql/schema.sql"/>
-			<jdbc:script location="classpath:com/bank/config/sql/test-data.sql"/>
-		</jdbc:embedded-database>
-	</beans>
----
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<beans profile="production"
-		xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:jee="http://www.springframework.org/schema/jee"
-		xsi:schemaLocation="...">
-
-		<jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/>
-	</beans>
----
-
-It is also possible to avoid that split and nest `<beans/>` elements within the same file,
-as the following example shows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:jdbc="http://www.springframework.org/schema/jdbc"
-		xmlns:jee="http://www.springframework.org/schema/jee"
-		xsi:schemaLocation="...">
-
-		<!-- other bean definitions -->
-
-		<beans profile="development">
-			<jdbc:embedded-database id="dataSource">
-				<jdbc:script location="classpath:com/bank/config/sql/schema.sql"/>
-				<jdbc:script location="classpath:com/bank/config/sql/test-data.sql"/>
-			</jdbc:embedded-database>
-		</beans>
-
-		<beans profile="production">
-			<jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/>
-		</beans>
-	</beans>
----
-
-The `spring-bean.xsd` has been constrained to allow such elements only as the
-last ones in the file. This should help provide flexibility without incurring
-clutter in the XML files.
-
-[NOTE]
-=====
-The XML counterpart does not support the profile expressions described earlier. It is possible,
-however, to negate a profile by using the `!` operator. It is also possible to apply a logical
-"`and`" by nesting the profiles, as the following example shows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:jdbc="http://www.springframework.org/schema/jdbc"
-		xmlns:jee="http://www.springframework.org/schema/jee"
-		xsi:schemaLocation="...">
-
-		<!-- other bean definitions -->
-
-		<beans profile="production">
-			<beans profile="us-east">
-				<jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/>
-			</beans>
-		</beans>
-	</beans>
----
-
-In the preceding example, the `dataSource` bean is exposed if both the `production` and
-`us-east` profiles are active.
-=====
-
-
-[[beans-definition-profiles-enable]]
-=== Activating a Profile
-
-Now that we have updated our configuration, we still need to instruct Spring which
-profile is active. If we started our sample application right now, we would see
-a `NoSuchBeanDefinitionException` thrown, because the container could not find
-the Spring bean named `dataSource`.
-
-Activating a profile can be done in several ways, but the most straightforward is to do
-it programmatically against the `Environment` API which is available through an
-`ApplicationContext`. The following example shows how to do so:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
-	ctx.getEnvironment().setActiveProfiles("development");
-	ctx.register(SomeConfig.class, StandaloneDataConfig.class, JndiDataConfig.class);
-	ctx.refresh();
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	val ctx = AnnotationConfigApplicationContext().apply {
-		environment.setActiveProfiles("development")
-		register(SomeConfig::class.java, StandaloneDataConfig::class.java, JndiDataConfig::class.java)
-		refresh()
-	}
----
-======
-
-In addition, you can also declaratively activate profiles through the
-`spring.profiles.active` property, which may be specified through system environment
-variables, JVM system properties, servlet context parameters in `web.xml`, or even as an
-entry in JNDI (see xref:core/beans/environment.adoc#beans-property-source-abstraction[`PropertySource` Abstraction]). In integration tests, active
-profiles can be declared by using the `@ActiveProfiles` annotation in the `spring-test`
-module (see xref:testing/testcontext-framework/ctx-management/env-profiles.adoc[context configuration with environment profiles]
-).
-
-Note that profiles are not an "`either-or`" proposition. You can activate multiple
-profiles at once. Programmatically, you can provide multiple profile names to the
-`setActiveProfiles()` method, which accepts `String...` varargs. The following example
-activates multiple profiles:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	ctx.getEnvironment().setActiveProfiles("profile1", "profile2");
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	ctx.getEnvironment().setActiveProfiles("profile1", "profile2")
----
-======
-
-Declaratively, `spring.profiles.active` may accept a comma-separated list of profile names,
-as the following example shows:
-
-[literal,indent=0,subs="verbatim,quotes"]
----
-	-Dspring.profiles.active="profile1,profile2"
----
-
-
-[[beans-definition-profiles-default]]
-=== Default Profile
-
-The default profile represents the profile that is enabled if no profile is active. Consider
-the following example:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	@Configuration
-	@Profile("default")
-	public class DefaultDataConfig {
-
-		@Bean
-		public DataSource dataSource() {
-			return new EmbeddedDatabaseBuilder()
-				.setType(EmbeddedDatabaseType.HSQL)
-				.addScript("classpath:com/bank/config/sql/schema.sql")
-				.build();
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Configuration
-	@Profile("default")
-	class DefaultDataConfig {
-
-		@Bean
-		fun dataSource(): DataSource {
-			return EmbeddedDatabaseBuilder()
-					.setType(EmbeddedDatabaseType.HSQL)
-					.addScript("classpath:com/bank/config/sql/schema.sql")
-					.build()
-		}
-	}
----
-======
-
-If xref:#beans-definition-profiles-enable[no profile is active], the `dataSource` is
-created. You can see this as a way to provide a default definition for one or more
-beans. If any profile is enabled, the default profile does not apply.
-
-The name of the default profile is `default`. You can change the name of
-the default profile by using `setDefaultProfiles()` on the `Environment` or,
-declaratively, by using the `spring.profiles.default` property.
-
-
-
-[[beans-property-source-abstraction]]
-== `PropertySource` Abstraction
-
-Spring's `Environment` abstraction provides search operations over a configurable
-hierarchy of property sources. Consider the following listing:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	ApplicationContext ctx = new GenericApplicationContext();
-	Environment env = ctx.getEnvironment();
-	boolean containsMyProperty = env.containsProperty("my-property");
-	System.out.println("Does my environment contain the 'my-property' property? " + containsMyProperty);
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	val ctx = GenericApplicationContext()
-	val env = ctx.environment
-	val containsMyProperty = env.containsProperty("my-property")
-	println("Does my environment contain the 'my-property' property? $containsMyProperty")
----
-======
-
-In the preceding snippet, we see a high-level way of asking Spring whether the `my-property` property is
-defined for the current environment. To answer this question, the `Environment` object performs
-a search over a set of {spring-framework-api}/core/env/PropertySource.html[`PropertySource`]
-objects. A `PropertySource` is a simple abstraction over any source of key-value pairs, and
-Spring's {spring-framework-api}/core/env/StandardEnvironment.html[`StandardEnvironment`]
-is configured with two PropertySource objects -- one representing the set of JVM system properties
-(`System.getProperties()`) and one representing the set of system environment variables
-(`System.getenv()`).
-
-NOTE: These default property sources are present for `StandardEnvironment`, for use in standalone
-applications. {spring-framework-api}/web/context/support/StandardServletEnvironment.html[`StandardServletEnvironment`]
-is populated with additional default property sources including servlet config, servlet
-context parameters, and a {spring-framework-api}/jndi/JndiPropertySource.html[`JndiPropertySource`]
-if JNDI is available.
-
-Concretely, when you use the `StandardEnvironment`, the call to `env.containsProperty("my-property")`
-returns true if a `my-property` system property or `my-property` environment variable is present at
-runtime.
-
-[TIP]
-====
-The search performed is hierarchical. By default, system properties have precedence over
-environment variables. So, if the `my-property` property happens to be set in both places during
-a call to `env.getProperty("my-property")`, the system property value "`wins`" and is returned.
-Note that property values are not merged
-but rather completely overridden by a preceding entry.
-
-For a common `StandardServletEnvironment`, the full hierarchy is as follows, with the
-highest-precedence entries at the top:
-
-. ServletConfig parameters (if applicable -- for example, in case of a `DispatcherServlet` context)
-. ServletContext parameters (web.xml context-param entries)
-. JNDI environment variables (`java:comp/env/` entries)
-. JVM system properties (`-D` command-line arguments)
-. JVM system environment (operating system environment variables)
-====
-
-Most importantly, the entire mechanism is configurable. Perhaps you have a custom source
-of properties that you want to integrate into this search. To do so, implement
-and instantiate your own `PropertySource` and add it to the set of `PropertySources` for the
-current `Environment`. The following example shows how to do so:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-ConfigurableApplicationContext ctx = new GenericApplicationContext();
-MutablePropertySources sources = ctx.getEnvironment().getPropertySources();
-sources.addFirst(new MyPropertySource());
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	val ctx = GenericApplicationContext()
-	val sources = ctx.environment.propertySources
-	sources.addFirst(MyPropertySource())
----
-======
-
-In the preceding code, `MyPropertySource` has been added with highest precedence in the
-search. If it contains a  `my-property` property, the property is detected and returned, in favor of
-any `my-property` property in any other `PropertySource`. The
-{spring-framework-api}/core/env/MutablePropertySources.html[`MutablePropertySources`]
-API exposes a number of methods that allow for precise manipulation of the set of
-property sources.
-
-
-
-[[beans-using-propertysource]]
-== Using `@PropertySource`
-
-The {spring-framework-api}/context/annotation/PropertySource.html[`@PropertySource`]
-annotation provides a convenient and declarative mechanism for adding a `PropertySource`
-to Spring's `Environment`.
-
-Given a file called `app.properties` that contains the key-value pair `testbean.name=myTestBean`,
-the following `@Configuration` class uses `@PropertySource` in such a way that
-a call to `testBean.getName()` returns `myTestBean`:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-   @Configuration
-   @PropertySource("classpath:/com/myco/app.properties")
-   public class AppConfig {
-
-	   @Autowired
-	   Environment env;
-
-	   @Bean
-	   public TestBean testBean() {
-		   TestBean testBean = new TestBean();
-		   testBean.setName(env.getProperty("testbean.name"));
-		   return testBean;
-	   }
-   }
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Configuration
-	@PropertySource("classpath:/com/myco/app.properties")
-	class AppConfig {
-
-		@Autowired
-		private lateinit var env: Environment
-
-		@Bean
-		fun testBean() = TestBean().apply {
-			name = env.getProperty("testbean.name")!!
-		}
-	}
----
-======
-
-Any `${...}` placeholders present in a `@PropertySource` resource location are
-resolved against the set of property sources already registered against the
-environment, as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-   @Configuration
-   @PropertySource("classpath:/com/${my.placeholder:default/path}/app.properties")
-   public class AppConfig {
-
-	   @Autowired
-	   Environment env;
-
-	   @Bean
-	   public TestBean testBean() {
-		   TestBean testBean = new TestBean();
-		   testBean.setName(env.getProperty("testbean.name"));
-		   return testBean;
-	   }
-   }
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@Configuration
-	@PropertySource("classpath:/com/\${my.placeholder:default/path}/app.properties")
-	class AppConfig {
-
-		@Autowired
-		private lateinit var env: Environment
-
-		@Bean
-		fun testBean() = TestBean().apply {
-			name = env.getProperty("testbean.name")!!
-		}
-	}
----
-======
-
-Assuming that `my.placeholder` is present in one of the property sources already
-registered (for example, system properties or environment variables), the placeholder is
-resolved to the corresponding value. If not, then `default/path` is used
-as a default. If no default is specified and a property cannot be resolved, an
-`IllegalArgumentException` is thrown.
-
-NOTE: `@PropertySource` can be used as a repeatable annotation. `@PropertySource`
-may also be used as a meta-annotation to create custom composed annotations with
-attribute overrides.
-
-
-
-[[beans-placeholder-resolution-in-statements]]
-== Placeholder Resolution in Statements
-
-Historically, the value of placeholders in elements could be resolved only against
-JVM system properties or environment variables. This is no longer the case. Because
-the `Environment` abstraction is integrated throughout the container, it is easy to
-route resolution of placeholders through it. This means that you may configure the
-resolution process in any way you like. You can change the precedence of searching through
-system properties and environment variables or remove them entirely. You can also add your
-own property sources to the mix, as appropriate.
-
-Concretely, the following statement works regardless of where the `customer`
-property is defined, as long as it is available in the `Environment`:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<beans>
-		<import resource="com/bank/service/${customer}-config.xml"/>
-	</beans>
----
-
-
-
-
@@ -1,503 +0,0 @@
-[[beans-factory-extension]]
-= Container Extension Points
-
-Typically, an application developer does not need to subclass `ApplicationContext`
-implementation classes. Instead, the Spring IoC container can be extended by plugging in
-implementations of special integration interfaces. The next few sections describe these
-integration interfaces.
-
-
-
-[[beans-factory-extension-bpp]]
-== Customizing Beans by Using a `BeanPostProcessor`
-
-The `BeanPostProcessor` interface defines callback methods that you can implement to
-provide your own (or override the container's default) instantiation logic, dependency
-resolution logic, and so forth. If you want to implement some custom logic after the
-Spring container finishes instantiating, configuring, and initializing a bean, you can
-plug in one or more custom `BeanPostProcessor` implementations.
-
-You can configure multiple `BeanPostProcessor` instances, and you can control the order
-in which these `BeanPostProcessor` instances run by setting the `order` property.
-You can set this property only if the `BeanPostProcessor` implements the `Ordered`
-interface. If you write your own `BeanPostProcessor`, you should consider implementing
-the `Ordered` interface, too. For further details, see the javadoc of the
-{spring-framework-api}/beans/factory/config/BeanPostProcessor.html[`BeanPostProcessor`]
-and {spring-framework-api}/core/Ordered.html[`Ordered`] interfaces. See also the note on
-xref:core/beans/factory-extension.adoc#beans-factory-programmatically-registering-beanpostprocessors[programmatic registration of `BeanPostProcessor` instances].
-
-[NOTE]
-====
-`BeanPostProcessor` instances operate on bean (or object) instances. That is,
-the Spring IoC container instantiates a bean instance and then `BeanPostProcessor`
-instances do their work.
-
-`BeanPostProcessor` instances are scoped per-container. This is relevant only if you
-use container hierarchies. If you define a `BeanPostProcessor` in one container,
-it post-processes only the beans in that container. In other words, beans that are
-defined in one container are not post-processed by a `BeanPostProcessor` defined in
-another container, even if both containers are part of the same hierarchy.
-
-To change the actual bean definition (that is, the blueprint that defines the bean),
-you instead need to use a `BeanFactoryPostProcessor`, as described in
-xref:core/beans/factory-extension.adoc#beans-factory-extension-factory-postprocessors[Customizing Configuration Metadata with a `BeanFactoryPostProcessor`].
-====
-
-The `org.springframework.beans.factory.config.BeanPostProcessor` interface consists of
-exactly two callback methods. When such a class is registered as a post-processor with
-the container, for each bean instance that is created by the container, the
-post-processor gets a callback from the container both before container
-initialization methods (such as `InitializingBean.afterPropertiesSet()` or any
-declared `init` method) are called, and after any bean initialization callbacks.
-The post-processor can take any action with the bean instance, including ignoring the
-callback completely. A bean post-processor typically checks for callback interfaces,
-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 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.
-
-Note that, when declaring a `BeanPostProcessor` by using an `@Bean` factory method on a
-configuration class, the return type of the factory method should be the implementation
-class itself or at least the `org.springframework.beans.factory.config.BeanPostProcessor`
-interface, clearly indicating the post-processor nature of that bean. Otherwise, the
-`ApplicationContext` cannot autodetect it by type before fully creating it.
-Since a `BeanPostProcessor` needs to be instantiated early in order to apply to the
-initialization of other beans in the context, this early type detection is critical.
-
-[[beans-factory-programmatically-registering-beanpostprocessors]]
-.Programmatically registering `BeanPostProcessor` instances
-NOTE: While the recommended approach for `BeanPostProcessor` registration is through
-`ApplicationContext` auto-detection (as described earlier), you can register them
-programmatically against a `ConfigurableBeanFactory` by using the `addBeanPostProcessor`
-method. This can be useful when you need to evaluate conditional logic before
-registration or even for copying bean post processors across contexts in a hierarchy.
-Note, however, that `BeanPostProcessor` instances added programmatically do not respect
-the `Ordered` interface. Here, it is the order of registration that dictates the order
-of execution. Note also that `BeanPostProcessor` instances registered programmatically
-are always processed before those registered through auto-detection, regardless of any
-explicit ordering.
-
-.`BeanPostProcessor` instances and AOP auto-proxying
-[NOTE]
-====
-Classes that implement the `BeanPostProcessor` interface are special and are treated
-differently by the container. All `BeanPostProcessor` instances and beans that they
-directly reference are instantiated on startup, as part of the special startup phase
-of the `ApplicationContext`. Next, all `BeanPostProcessor` instances are registered
-in a sorted fashion and applied to all further beans in the container. Because AOP
-auto-proxying is implemented as a `BeanPostProcessor` itself, neither `BeanPostProcessor`
-instances nor the beans they directly reference are eligible for auto-proxying and,
-thus, do not have aspects woven into them.
-
-For any such bean, you should see an informational log message: `Bean someBean is not
-eligible for getting processed by all BeanPostProcessor interfaces (for example: not
-eligible for auto-proxying)`.
-
-If you have beans wired into your `BeanPostProcessor` by using autowiring or
-`@Resource` (which may fall back to autowiring), Spring might access unexpected beans
-when searching for type-matching dependency candidates and, therefore, make them
-ineligible for auto-proxying or other kinds of bean post-processing. For example, if you
-have a dependency annotated with `@Resource` where the field or setter name does not
-directly correspond to the declared name of a bean and no name attribute is used,
-Spring accesses other beans for matching them by type.
-====
-
-The following examples show how to write, register, and use `BeanPostProcessor` instances
-in an `ApplicationContext`.
-
-
-[[beans-factory-extension-bpp-examples-hw]]
-=== Example: Hello World, `BeanPostProcessor`-style
-
-This first example illustrates basic usage. The example shows a custom
-`BeanPostProcessor` implementation that invokes the `toString()` method of each bean as
-it is created by the container and prints the resulting string to the system console.
-
-The following listing shows the custom `BeanPostProcessor` implementation class definition:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary",chomp="-packages"]
----
-	package scripting;
-
-	import org.springframework.beans.factory.config.BeanPostProcessor;
-
-	public class InstantiationTracingBeanPostProcessor implements BeanPostProcessor {
-
-		// simply return the instantiated bean as-is
-		public Object postProcessBeforeInitialization(Object bean, String beanName) {
-			return bean; // we could potentially return any object reference here...
-		}
-
-		public Object postProcessAfterInitialization(Object bean, String beanName) {
-			System.out.println("Bean '" + beanName + "' created : " + bean.toString());
-			return bean;
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary",chomp="-packages"]
----
-	package scripting
-
-	import org.springframework.beans.factory.config.BeanPostProcessor
-
-	class InstantiationTracingBeanPostProcessor : BeanPostProcessor {
-
-		// simply return the instantiated bean as-is
-		override fun postProcessBeforeInitialization(bean: Any, beanName: String): Any? {
-			return bean // we could potentially return any object reference here...
-		}
-
-		override fun postProcessAfterInitialization(bean: Any, beanName: String): Any? {
-			println("Bean '$beanName' created : $bean")
-			return bean
-		}
-	}
----
-======
-
-The following `beans` element uses the `InstantiationTracingBeanPostProcessor`:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<?xml version="1.0" encoding="UTF-8"?>
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:lang="http://www.springframework.org/schema/lang"
-		xsi:schemaLocation="http://www.springframework.org/schema/beans
-			https://www.springframework.org/schema/beans/spring-beans.xsd
-			http://www.springframework.org/schema/lang
-			https://www.springframework.org/schema/lang/spring-lang.xsd">
-
-		<lang:groovy id="messenger"
-				script-source="classpath:org/springframework/scripting/groovy/Messenger.groovy">
-			<lang:property name="message" value="Fiona Apple Is Just So Dreamy."/>
-		</lang:groovy>
-
-		<!--
-		when the above bean (messenger) is instantiated, this custom
-		BeanPostProcessor implementation will output the fact to the system console
-		-->
-		<bean class="scripting.InstantiationTracingBeanPostProcessor"/>
-
-	</beans>
----
-
-Notice how the `InstantiationTracingBeanPostProcessor` is merely defined. It does not
-even have a name, and, because it is a bean, it can be dependency-injected as you would any
-other bean. (The preceding configuration also defines a bean that is backed by a Groovy
-script. The Spring dynamic language support is detailed in the chapter entitled
-xref:languages/dynamic.adoc[Dynamic Language Support].)
-
-The following Java application runs the preceding code and configuration:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	import org.springframework.context.ApplicationContext;
-	import org.springframework.context.support.ClassPathXmlApplicationContext;
-	import org.springframework.scripting.Messenger;
-
-	public final class Boot {
-
-		public static void main(final String[] args) throws Exception {
-			ApplicationContext ctx = new ClassPathXmlApplicationContext("scripting/beans.xml");
-			Messenger messenger = ctx.getBean("messenger", Messenger.class);
-			System.out.println(messenger);
-		}
-
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-    import org.springframework.beans.factory.getBean
-
-	fun main() {
-		val ctx = ClassPathXmlApplicationContext("scripting/beans.xml")
-		val messenger = ctx.getBean<Messenger>("messenger")
-		println(messenger)
-	}
----
-======
-
-The output of the preceding application resembles the following:
-
-[literal,subs="verbatim,quotes"]
----
-Bean 'messenger' created : org.springframework.scripting.groovy.GroovyMessenger@272961
-org.springframework.scripting.groovy.GroovyMessenger@272961
----
-
-
-[[beans-factory-extension-bpp-examples-aabpp]]
-=== Example: The `AutowiredAnnotationBeanPostProcessor`
-
-Using callback interfaces or annotations in conjunction with a custom `BeanPostProcessor`
-implementation is a common means of extending the Spring IoC container. An example is
-Spring's `AutowiredAnnotationBeanPostProcessor` -- a `BeanPostProcessor` implementation
-that ships with the Spring distribution and autowires annotated fields, setter methods,
-and arbitrary config methods.
-
-
-
-[[beans-factory-extension-factory-postprocessors]]
-== Customizing Configuration Metadata with a `BeanFactoryPostProcessor`
-
-The next extension point that we look at is the
-`org.springframework.beans.factory.config.BeanFactoryPostProcessor`. The semantics of
-this interface are similar to those of the `BeanPostProcessor`, with one major
-difference: `BeanFactoryPostProcessor` operates on the bean configuration metadata.
-That is, the Spring IoC container lets a `BeanFactoryPostProcessor` read the
-configuration metadata and potentially change it _before_ the container instantiates
-any beans other than `BeanFactoryPostProcessor` instances.
-
-You can configure multiple `BeanFactoryPostProcessor` instances, and you can control the order in
-which these `BeanFactoryPostProcessor` instances run by setting the `order` property.
-However, you can only set this property if the `BeanFactoryPostProcessor` implements the
-`Ordered` interface. If you write your own `BeanFactoryPostProcessor`, you should
-consider implementing the `Ordered` interface, too. See the javadoc of the
-{spring-framework-api}/beans/factory/config/BeanFactoryPostProcessor.html[`BeanFactoryPostProcessor`]
-and {spring-framework-api}/core/Ordered.html[`Ordered`] interfaces for more details.
-
-[NOTE]
-====
-If you want to change the actual bean instances (that is, the objects that are created
-from the configuration metadata), then you instead need to use a `BeanPostProcessor`
-(described earlier in
-xref:core/beans/factory-extension.adoc#beans-factory-extension-bpp[Customizing Beans by Using a `BeanPostProcessor`]).
-While it is technically possible to work with bean instances within a `BeanFactoryPostProcessor`
-(for example, by using `BeanFactory.getBean()`), doing so causes premature bean instantiation,
-violating the standard container lifecycle. This may cause negative side effects, such as
-bypassing bean post processing.
-
-Also, `BeanFactoryPostProcessor` instances are scoped per-container. This is only relevant
-if you use container hierarchies. If you define a `BeanFactoryPostProcessor` in one
-container, it is applied only to the bean definitions in that container. Bean definitions
-in one container are not post-processed by `BeanFactoryPostProcessor` instances in another
-container, even if both containers are part of the same hierarchy.
-====
-
-A bean factory post-processor is automatically run when it is declared inside an
-`ApplicationContext`, in order to apply changes to the configuration metadata that
-define the container. Spring includes a number of predefined bean factory
-post-processors, such as `PropertyOverrideConfigurer` and
-`PropertySourcesPlaceholderConfigurer`. You can also use a custom `BeanFactoryPostProcessor`
-- for example, to register custom property editors.
-
-An `ApplicationContext` automatically detects any beans that are deployed into it that
-implement the `BeanFactoryPostProcessor` interface. It uses these beans as bean factory
-post-processors, at the appropriate time. You can deploy these post-processor beans as
-you would any other bean.
-
-NOTE: As with ``BeanPostProcessor``s , you typically do not want to configure
-``BeanFactoryPostProcessor``s for lazy initialization. If no other bean references a
-`Bean(Factory)PostProcessor`, that post-processor will not get instantiated at all.
-Thus, marking it for lazy initialization will be ignored, and the
-`Bean(Factory)PostProcessor` will be instantiated eagerly even if you set the
-`default-lazy-init` attribute to `true` on the declaration of your `<beans />` element.
-
-
-[[beans-factory-placeholderconfigurer]]
-=== Example: The Class Name Substitution `PropertySourcesPlaceholderConfigurer`
-
-You can use the `PropertySourcesPlaceholderConfigurer` to externalize property values
-from a bean definition in a separate file by using the standard Java `Properties` format.
-Doing so enables the person deploying an application to customize environment-specific
-properties, such as database URLs and passwords, without the complexity or risk of
-modifying the main XML definition file or files for the container.
-
-Consider the following XML-based configuration metadata fragment, where a `DataSource`
-with placeholder values is defined:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean class="org.springframework.context.support.PropertySourcesPlaceholderConfigurer">
-		<property name="locations" value="classpath:com/something/jdbc.properties"/>
-	</bean>
-
-	<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
-		<property name="driverClassName" value="${jdbc.driverClassName}"/>
-		<property name="url" value="${jdbc.url}"/>
-		<property name="username" value="${jdbc.username}"/>
-		<property name="password" value="${jdbc.password}"/>
-	</bean>
----
-
-The example shows properties configured from an external `Properties` file. At runtime,
-a `PropertySourcesPlaceholderConfigurer` is applied to the metadata that replaces some
-properties of the DataSource. The values to replace are specified as placeholders of the
-form pass:q[`${property-name}`], which follows the Ant and log4j and JSP EL style.
-
-The actual values come from another file in the standard Java `Properties` format:
-
-[literal,subs="verbatim,quotes"]
----
-jdbc.driverClassName=org.hsqldb.jdbcDriver
-jdbc.url=jdbc:hsqldb:hsql://production:9002
-jdbc.username=sa
-jdbc.password=root
----
-
-Therefore, the `${jdbc.username}` string is replaced at runtime with the value, 'sa', and
-the same applies for other placeholder values that match keys in the properties file.
-The `PropertySourcesPlaceholderConfigurer` checks for placeholders in most properties and
-attributes of a bean definition. Furthermore, you can customize the placeholder prefix and suffix.
-
-With the `context` namespace introduced in Spring 2.5, you can configure property placeholders
-with a dedicated configuration element. You can provide one or more locations as a
-comma-separated list in the `location` attribute, as the following example shows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<context:property-placeholder location="classpath:com/something/jdbc.properties"/>
----
-
-The `PropertySourcesPlaceholderConfigurer` not only looks for properties in the `Properties`
-file you specify. By default, if it cannot find a property in the specified properties files,
-it checks against Spring `Environment` properties and regular Java `System` properties.
-
-[WARNING]
-=====
-Only one such element should be defined for a given application with the properties
-that it needs. Several property placeholders can be configured as long as they have distinct
-placeholder syntax (`${...}`).
-
-If you need to modularize the source of properties used for the replacement, you should
-not create multiple properties placeholders. Rather, you should create your own
-`PropertySourcesPlaceholderConfigurer` bean that gathers the properties to use.
-=====
-
-[TIP]
-=====
-You can use the `PropertySourcesPlaceholderConfigurer` to substitute class names, which
-is sometimes useful when you have to pick a particular implementation class at runtime.
-The following example shows how to do so:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean class="org.springframework.beans.factory.config.PropertySourcesPlaceholderConfigurer">
-		<property name="locations">
-			<value>classpath:com/something/strategy.properties</value>
-		</property>
-		<property name="properties">
-			<value>custom.strategy.class=com.something.DefaultStrategy</value>
-		</property>
-	</bean>
-
-	<bean id="serviceStrategy" class="${custom.strategy.class}"/>
----
-
-If the class cannot be resolved at runtime to a valid class, resolution of the bean
-fails when it is about to be created, which is during the `preInstantiateSingletons()`
-phase of an `ApplicationContext` for a non-lazy-init bean.
-=====
-
-
-[[beans-factory-overrideconfigurer]]
-=== Example: The `PropertyOverrideConfigurer`
-
-The `PropertyOverrideConfigurer`, another bean factory post-processor, resembles the
-`PropertySourcesPlaceholderConfigurer`, but unlike the latter, the original definitions
-can have default values or no values at all for bean properties. If an overriding
-`Properties` file does not have an entry for a certain bean property, the default
-context definition is used.
-
-Note that the bean definition is not aware of being overridden, so it is not
-immediately obvious from the XML definition file that the override configurer is being
-used. In case of multiple `PropertyOverrideConfigurer` instances that define different
-values for the same bean property, the last one wins, due to the overriding mechanism.
-
-Properties file configuration lines take the following format:
-
-[literal,subs="verbatim,quotes"]
----
-beanName.property=value
----
-
-The following listing shows an example of the format:
-
-[literal,subs="verbatim,quotes"]
----
-dataSource.driverClassName=com.mysql.jdbc.Driver
-dataSource.url=jdbc:mysql:mydb
----
-
-This example file can be used with a container definition that contains a bean called
-`dataSource` that has `driver` and `url` properties.
-
-Compound property names are also supported, as long as every component of the path
-except the final property being overridden is already non-null (presumably initialized
-by the constructors). In the following example, the `sammy` property of the `bob`
-property of the `fred` property of the `tom` bean is set to the scalar value `123`:
-
-[literal,subs="verbatim,quotes"]
----
-tom.fred.bob.sammy=123
----
-
-
-NOTE: Specified override values are always literal values. They are not translated into
-bean references. This convention also applies when the original value in the XML bean
-definition specifies a bean reference.
-
-With the `context` namespace introduced in Spring 2.5, it is possible to configure
-property overriding with a dedicated configuration element, as the following example shows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<context:property-override location="classpath:override.properties"/>
----
-
-
-
-[[beans-factory-extension-factorybean]]
-== Customizing Instantiation Logic with a `FactoryBean`
-
-You can implement the `org.springframework.beans.factory.FactoryBean` interface for objects that
-are themselves factories.
-
-The `FactoryBean` interface is a point of pluggability into the Spring IoC container's
-instantiation logic. If you have complex initialization code that is better expressed in
-Java as opposed to a (potentially) verbose amount of XML, you can create your own
-`FactoryBean`, write the complex initialization inside that class, and then plug your
-custom `FactoryBean` into the container.
-
-The `FactoryBean<T>` interface provides three methods:
-
-* `T getObject()`: Returns an instance of the object this factory creates. The
-  instance can possibly be shared, depending on whether this factory returns singletons
-  or prototypes.
-* `boolean isSingleton()`: Returns `true` if this `FactoryBean` returns singletons or
-  `false` otherwise. The default implementation of this method returns `true`.
-* `Class<?> getObjectType()`: Returns the object type returned by the `getObject()` method
-  or `null` if the type is not known in advance.
-
-The `FactoryBean` concept and interface are used in a number of places within the Spring
-Framework. More than 50 implementations of the `FactoryBean` interface ship with Spring
-itself.
-
-When you need to ask a container for an actual `FactoryBean` instance itself instead of
-the bean it produces, prefix the bean's `id` with the ampersand symbol (`&`) when
-calling the `getBean()` method of the `ApplicationContext`. So, for a given `FactoryBean`
-with an `id` of `myBean`, invoking `getBean("myBean")` on the container returns the
-product of the `FactoryBean`, whereas invoking `getBean("&myBean")` returns the
-`FactoryBean` instance itself.
-
-
-
@@ -1,752 +0,0 @@
-[[beans-factory-nature]]
-= Customizing the Nature of a Bean
-
-The Spring Framework provides a number of interfaces you can use to customize the nature
-of a bean. This section groups them as follows:
-
-* xref:core/beans/factory-nature.adoc#beans-factory-lifecycle[Lifecycle Callbacks]
-* xref:core/beans/factory-nature.adoc#beans-factory-aware[`ApplicationContextAware` and `BeanNameAware`]
-* xref:core/beans/factory-nature.adoc#aware-list[Other `Aware` Interfaces]
-
-
-
-[[beans-factory-lifecycle]]
-== Lifecycle Callbacks
-
-To interact with the container's management of the bean lifecycle, you can implement
-the Spring `InitializingBean` and `DisposableBean` interfaces. The container calls
-`afterPropertiesSet()` for the former and `destroy()` for the latter to let the bean
-perform certain actions upon initialization and destruction of your beans.
-
-[TIP]
-====
-The JSR-250 `@PostConstruct` and `@PreDestroy` annotations are generally considered best
-practice for receiving lifecycle callbacks in a modern Spring application. Using these
-annotations means that your beans are not coupled to Spring-specific interfaces.
-For details, see xref:core/beans/annotation-config/postconstruct-and-predestroy-annotations.adoc[Using `@PostConstruct` and `@PreDestroy`].
-
-If you do not want to use the JSR-250 annotations but you still want to remove
-coupling, consider `init-method` and `destroy-method` bean definition metadata.
-====
-
-Internally, the Spring Framework uses `BeanPostProcessor` implementations to process any
-callback interfaces it can find and call the appropriate methods. If you need custom
-features or other lifecycle behavior Spring does not by default offer, you can
-implement a `BeanPostProcessor` yourself. For more information, see
-xref:core/beans/factory-extension.adoc[Container Extension Points].
-
-In addition to the initialization and destruction callbacks, Spring-managed objects may
-also implement the `Lifecycle` interface so that those objects can participate in the
-startup and shutdown process, as driven by the container's own lifecycle.
-
-The lifecycle callback interfaces are described in this section.
-
-
-
-[[beans-factory-lifecycle-initializingbean]]
-=== Initialization Callbacks
-
-The `org.springframework.beans.factory.InitializingBean` interface lets a bean
-perform initialization work after the container has set all necessary properties on the
-bean. The `InitializingBean` interface specifies a single method:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	void afterPropertiesSet() throws Exception;
----
-
-We recommend that you do not use the `InitializingBean` interface, because it
-unnecessarily couples the code to Spring. Alternatively, we suggest using
-the xref:core/beans/annotation-config/postconstruct-and-predestroy-annotations.adoc[`@PostConstruct`] annotation or
-specifying a POJO initialization method. In the case of XML-based configuration metadata,
-you can use the `init-method` attribute to specify the name of the method that has a void
-no-argument signature. With Java configuration, you can use the `initMethod` attribute of
-`@Bean`. See xref:core/beans/java/bean-annotation.adoc#beans-java-lifecycle-callbacks[Receiving Lifecycle Callbacks]. Consider the following example:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="exampleInitBean" class="examples.ExampleBean" init-method="init"/>
----
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class ExampleBean {
-
-		public void init() {
-			// do some initialization work
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class ExampleBean {
-
-		fun init() {
-			// do some initialization work
-		}
-	}
----
-======
-
-The preceding example has almost exactly the same effect as the following example
-(which consists of two listings):
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="exampleInitBean" class="examples.AnotherExampleBean"/>
----
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class AnotherExampleBean implements InitializingBean {
-
-		@Override
-		public void afterPropertiesSet() {
-			// do some initialization work
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class AnotherExampleBean : InitializingBean {
-
-		override fun afterPropertiesSet() {
-			// do some initialization work
-		}
-	}
----
-======
-
-However, the first of the two preceding examples does not couple the code to Spring.
-
-[NOTE]
-====
-Be aware that `@PostConstruct` and initialization methods in general are executed
-within the container's singleton creation lock. The bean instance is only considered
-as fully initialized and ready to be published to others after returning from the
-`@PostConstruct` method. Such individual initialization methods are only meant
-for validating the configuration state and possibly preparing some data structures
-based on the given configuration but no further activity with external bean access.
-Otherwise there is a risk for an initialization deadlock.
-
-For a scenario where expensive post-initialization activity is to be triggered,
-e.g. asynchronous database preparation steps, your bean should either implement
-`SmartInitializingSingleton.afterSingletonsInstantiated()` or rely on the context
-refresh event: implementing `ApplicationListener<ContextRefreshedEvent>` or
-declaring its annotation equivalent `@EventListener(ContextRefreshedEvent.class)`.
-Those variants come after all regular singleton initialization and therefore
-outside of any singleton creation lock.
-
-Alternatively, you may implement the `(Smart)Lifecycle` interface and integrate with
-the container's overall lifecycle management, including an auto-startup mechanism,
-a pre-destroy stop step, and potential stop/restart callbacks (see below).
-====
-
-
-
-[[beans-factory-lifecycle-disposablebean]]
-=== Destruction Callbacks
-
-Implementing the `org.springframework.beans.factory.DisposableBean` interface lets a
-bean get a callback when the container that contains it is destroyed. The
-`DisposableBean` interface specifies a single method:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	void destroy() throws Exception;
----
-
-We recommend that you do not use the `DisposableBean` callback interface, because it
-unnecessarily couples the code to Spring. Alternatively, we suggest using
-the xref:core/beans/annotation-config/postconstruct-and-predestroy-annotations.adoc[`@PreDestroy`] annotation or
-specifying a generic method that is supported by bean definitions. With XML-based
-configuration metadata, you can use the `destroy-method` attribute on the `<bean/>`.
-With Java configuration, you can use the `destroyMethod` attribute of `@Bean`. See
-xref:core/beans/java/bean-annotation.adoc#beans-java-lifecycle-callbacks[Receiving Lifecycle Callbacks]. Consider the following definition:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="exampleDestructionBean" class="examples.ExampleBean" destroy-method="cleanup"/>
----
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class ExampleBean {
-
-		public void cleanup() {
-			// do some destruction work (like releasing pooled connections)
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class ExampleBean {
-
-		fun cleanup() {
-			// do some destruction work (like releasing pooled connections)
-		}
-	}
----
-======
-
-The preceding definition has almost exactly the same effect as the following definition:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="exampleDestructionBean" class="examples.AnotherExampleBean"/>
----
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class AnotherExampleBean implements DisposableBean {
-
-		@Override
-		public void destroy() {
-			// do some destruction work (like releasing pooled connections)
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class AnotherExampleBean : DisposableBean {
-
-		override fun destroy() {
-			// do some destruction work (like releasing pooled connections)
-		}
-	}
----
-======
-
-However, the first of the two preceding definitions does not couple the code to Spring.
-
-Note that Spring also supports inference of destroy methods, detecting a public `close` or
-`shutdown` method. This is the default behavior for `@Bean` methods in Java configuration
-classes and automatically matches `java.lang.AutoCloseable` or `java.io.Closeable`
-implementations, not coupling the destruction logic to Spring either.
-
-TIP: For destroy method inference with XML, you may assign the `destroy-method` attribute
-of a `<bean>` element a special `(inferred)` value, which instructs Spring to automatically
-detect a public `close` or `shutdown` method on the bean class for a specific bean definition.
-You can also set this special `(inferred)` value on the `default-destroy-method` attribute
-of a `<beans>` element to apply this behavior to an entire set of bean definitions (see
-xref:core/beans/factory-nature.adoc#beans-factory-lifecycle-default-init-destroy-methods[Default Initialization and Destroy Methods]).
-
-[NOTE]
-====
-For extended shutdown phases, you may implement the `Lifecycle` interface and receive
-an early stop signal before the destroy methods of any singleton beans are called.
-You may also implement `SmartLifecycle` for a time-bound stop step where the container
-will wait for all such stop processing to complete before moving on to destroy methods.
-====
-
-
-
-[[beans-factory-lifecycle-default-init-destroy-methods]]
-=== Default Initialization and Destroy Methods
-
-When you write initialization and destroy method callbacks that do not use the
-Spring-specific `InitializingBean` and `DisposableBean` callback interfaces, you
-typically write methods with names such as `init()`, `initialize()`, `dispose()`,
-and so on. Ideally, the names of such lifecycle callback methods are standardized across
-a project so that all developers use the same method names and ensure consistency.
-
-You can configure the Spring container to "`look`" for named initialization and destroy
-callback method names on every bean. This means that you, as an application developer,
-can write your application classes and use an initialization callback called `init()`,
-without having to configure an `init-method="init"` attribute with each bean definition.
-The Spring IoC container calls that method when the bean is created (and in accordance
-with the standard lifecycle callback contract xref:core/beans/factory-nature.adoc#beans-factory-lifecycle[described previously]).
-This feature also enforces a consistent naming convention for initialization and
-destroy method callbacks.
-
-Suppose that your initialization callback methods are named `init()` and your destroy
-callback methods are named `destroy()`. Your class then resembles the class in the
-following example:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	public class DefaultBlogService implements BlogService {
-
-		private BlogDao blogDao;
-
-		public void setBlogDao(BlogDao blogDao) {
-			this.blogDao = blogDao;
-		}
-
-		// this is (unsurprisingly) the initialization callback method
-		public void init() {
-			if (this.blogDao == null) {
-				throw new IllegalStateException("The [blogDao] property must be set.");
-			}
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	class DefaultBlogService : BlogService {
-
-		private var blogDao: BlogDao? = null
-
-		// this is (unsurprisingly) the initialization callback method
-		fun init() {
-			if (blogDao == null) {
-				throw IllegalStateException("The [blogDao] property must be set.")
-			}
-		}
-	}
----
-======
-
-You could then use that class in a bean resembling the following:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<beans default-init-method="init">
-
-		<bean id="blogService" class="com.something.DefaultBlogService">
-			<property name="blogDao" ref="blogDao" />
-		</bean>
-
-	</beans>
----
-
-The presence of the `default-init-method` attribute on the top-level `<beans/>` element
-attribute causes the Spring IoC container to recognize a method called `init` on the bean
-class as the initialization method callback. When a bean is created and assembled, if the
-bean class has such a method, it is invoked at the appropriate time.
-
-You can configure destroy method callbacks similarly (in XML, that is) by using the
-`default-destroy-method` attribute on the top-level `<beans/>` element.
-
-Where existing bean classes already have callback methods that are named at variance
-with the convention, you can override the default by specifying (in XML, that is) the
-method name by using the `init-method` and `destroy-method` attributes of the `<bean/>`
-itself.
-
-The Spring container guarantees that a configured initialization callback is called
-immediately after a bean is supplied with all dependencies. Thus, the initialization
-callback is called on the raw bean reference, which means that AOP interceptors and so
-forth are not yet applied to the bean. A target bean is fully created first and
-then an AOP proxy (for example) with its interceptor chain is applied. If the target
-bean and the proxy are defined separately, your code can even interact with the raw
-target bean, bypassing the proxy. Hence, it would be inconsistent to apply the
-interceptors to the `init` method, because doing so would couple the lifecycle of the
-target bean to its proxy or interceptors and leave strange semantics when your code
-interacts directly with the raw target bean.
-
-
-
-[[beans-factory-lifecycle-combined-effects]]
-=== Combining Lifecycle Mechanisms
-
-As of Spring 2.5, you have three options for controlling bean lifecycle behavior:
-
-* The xref:core/beans/factory-nature.adoc#beans-factory-lifecycle-initializingbean[`InitializingBean`] and
-xref:core/beans/factory-nature.adoc#beans-factory-lifecycle-disposablebean[`DisposableBean`] callback interfaces
-* Custom `init()` and `destroy()` methods
-* The xref:core/beans/annotation-config/postconstruct-and-predestroy-annotations.adoc[`@PostConstruct` and `@PreDestroy` annotations]
-. You can combine these mechanisms to control a given bean.
-
-NOTE: If multiple lifecycle mechanisms are configured for a bean and each mechanism is
-configured with a different method name, then each configured method is run in the
-order listed after this note. However, if the same method name is configured -- for example,
-`init()` for an initialization method -- for more than one of these lifecycle mechanisms,
-that method is run once, as explained in the
-xref:core/beans/factory-nature.adoc#beans-factory-lifecycle-default-init-destroy-methods[preceding section].
-
-Multiple lifecycle mechanisms configured for the same bean, with different
-initialization methods, are called as follows:
-
-. Methods annotated with `@PostConstruct`
-. `afterPropertiesSet()` as defined by the `InitializingBean` callback interface
-. A custom configured `init()` method
-
-Destroy methods are called in the same order:
-
-. Methods annotated with `@PreDestroy`
-. `destroy()` as defined by the `DisposableBean` callback interface
-. A custom configured `destroy()` method
-
-
-
-[[beans-factory-lifecycle-processor]]
-=== Startup and Shutdown Callbacks
-
-The `Lifecycle` interface defines the essential methods for any object that has its own
-lifecycle requirements (such as starting and stopping some background process):
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	public interface Lifecycle {
-
-		void start();
-
-		void stop();
-
-		boolean isRunning();
-	}
----
-
-Any Spring-managed object may implement the `Lifecycle` interface. Then, when the
-`ApplicationContext` itself receives start and stop signals (for example, for a stop/restart
-scenario at runtime), it cascades those calls to all `Lifecycle` implementations
-defined within that context. It does this by delegating to a `LifecycleProcessor`, shown
-in the following listing:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	public interface LifecycleProcessor extends Lifecycle {
-
-		void onRefresh();
-
-		void onClose();
-	}
----
-
-Notice that the `LifecycleProcessor` is itself an extension of the `Lifecycle`
-interface. It also adds two other methods for reacting to the context being refreshed
-and closed.
-
-[TIP]
-====
-Note that the regular `org.springframework.context.Lifecycle` interface is a plain
-contract for explicit start and stop notifications and does not imply auto-startup
-at context refresh time. For fine-grained control over auto-startup and for graceful
-stopping of a specific bean (including startup and stop phases), consider implementing
-the extended `org.springframework.context.SmartLifecycle` interface instead.
-
-Also, please note that stop notifications are not guaranteed to come before destruction.
-On regular shutdown, all `Lifecycle` beans first receive a stop notification before
-the general destruction callbacks are being propagated. However, on hot refresh during
-a context's lifetime or on stopped refresh attempts, only destroy methods are called.
-====
-
-The order of startup and shutdown invocations can be important. If a "`depends-on`"
-relationship exists between any two objects, the dependent side starts after its
-dependency, and it stops before its dependency. However, at times, the direct
-dependencies are unknown. You may only know that objects of a certain type should start
-prior to objects of another type. In those cases, the `SmartLifecycle` interface defines
-another option, namely the `getPhase()` method as defined on its super-interface,
-`Phased`. The following listing shows the definition of the `Phased` interface:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	public interface Phased {
-
-		int getPhase();
-	}
----
-
-The following listing shows the definition of the `SmartLifecycle` interface:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	public interface SmartLifecycle extends Lifecycle, Phased {
-
-		boolean isAutoStartup();
-
-		void stop(Runnable callback);
-	}
----
-
-When starting, the objects with the lowest phase start first. When stopping, the
-reverse order is followed. Therefore, an object that implements `SmartLifecycle` and
-whose `getPhase()` method returns `Integer.MIN_VALUE` would be among the first to start
-and the last to stop. At the other end of the spectrum, a phase value of
-`Integer.MAX_VALUE` would indicate that the object should be started last and stopped
-first (likely because it depends on other processes to be running). When considering the
-phase value, it is also important to know that the default phase for any "`normal`"
-`Lifecycle` object that does not implement `SmartLifecycle` is `0`. Therefore, any
-negative phase value indicates that an object should start before those standard
-components (and stop after them). The reverse is true for any positive phase value.
-
-The stop method defined by `SmartLifecycle` accepts a callback. Any
-implementation must invoke that callback's `run()` method after that implementation's
-shutdown process is complete. That enables asynchronous shutdown where necessary, since
-the default implementation of the `LifecycleProcessor` interface,
-`DefaultLifecycleProcessor`, waits up to its timeout value for the group of objects
-within each phase to invoke that callback. The default per-phase timeout is 30 seconds.
-You can override the default lifecycle processor instance by defining a bean named
-`lifecycleProcessor` within the context. If you want only to modify the timeout,
-defining the following would suffice:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="lifecycleProcessor" class="org.springframework.context.support.DefaultLifecycleProcessor">
-		<!-- timeout value in milliseconds -->
-		<property name="timeoutPerShutdownPhase" value="10000"/>
-	</bean>
----
-
-As mentioned earlier, the `LifecycleProcessor` interface defines callback methods for the
-refreshing and closing of the context as well. The latter drives the shutdown
-process as if `stop()` had been called explicitly, but it happens when the context is
-closing. The 'refresh' callback, on the other hand, enables another feature of
-`SmartLifecycle` beans. When the context is refreshed (after all objects have been
-instantiated and initialized), that callback is invoked. At that point, the
-default lifecycle processor checks the boolean value returned by each
-`SmartLifecycle` object's `isAutoStartup()` method. If `true`, that object is
-started at that point rather than waiting for an explicit invocation of the context's or
-its own `start()` method (unlike the context refresh, the context start does not happen
-automatically for a standard context implementation). The `phase` value and any
-"`depends-on`" relationships determine the startup order as described earlier.
-
-
-
-[[beans-factory-shutdown]]
-=== Shutting Down the Spring IoC Container Gracefully in Non-Web Applications
-
-[NOTE]
-====
-This section applies only to non-web applications. Spring's web-based
-`ApplicationContext` implementations already have code in place to gracefully shut down
-the Spring IoC container when the relevant web application is shut down.
-====
-
-If you use Spring's IoC container in a non-web application environment (for
-example, in a rich client desktop environment), register a shutdown hook with the
-JVM. Doing so ensures a graceful shutdown and calls the relevant destroy methods on your
-singleton beans so that all resources are released. You must still configure
-and implement these destroy callbacks correctly.
-
-To register a shutdown hook, call the `registerShutdownHook()` method that is
-declared on the `ConfigurableApplicationContext` interface, as the following example shows:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	import org.springframework.context.ConfigurableApplicationContext;
-	import org.springframework.context.support.ClassPathXmlApplicationContext;
-
-	public final class Boot {
-
-		public static void main(final String[] args) throws Exception {
-			ConfigurableApplicationContext ctx = new ClassPathXmlApplicationContext("beans.xml");
-
-			// add a shutdown hook for the above context...
-			ctx.registerShutdownHook();
-
-			// app runs here...
-
-			// main method exits, hook is called prior to the app shutting down...
-		}
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	import org.springframework.context.support.ClassPathXmlApplicationContext
-
-	fun main() {
-		val ctx = ClassPathXmlApplicationContext("beans.xml")
-
-		// add a shutdown hook for the above context...
-		ctx.registerShutdownHook()
-
-		// app runs here...
-
-		// main method exits, hook is called prior to the app shutting down...
-	}
----
-======
-
-
-
-[[beans-factory-thread-safety]]
-=== Thread Safety and Visibility
-
-The Spring core container publishes created singleton instances in a thread-safe manner,
-guarding access through a singleton lock and guaranteeing visibility in other threads.
-
-As a consequence, application-provided bean classes do not have to be concerned about the
-visibility of their initialization state. Regular configuration fields do not have to be
-marked as `volatile` as long as they are only mutated during the initialization phase,
-providing visibility guarantees similar to `final` even for setter-based configuration
-state that is mutable during that initial phase. If such fields get changed after the
-bean creation phase and its subsequent initial publication, they need to be declared as
-`volatile` or guarded by a common lock whenever accessed.
-
-Note that concurrent access to such configuration state in singleton bean instances,
-e.g. for controller instances or repository instances, is perfectly thread-safe after
-such safe initial publication from the container side. This includes common singleton
-`FactoryBean` instances which are processed within the general singleton lock as well.
-
-For destruction callbacks, the configuration state remains thread-safe but any runtime
-state accumulated between initialization and destruction should be kept in thread-safe
-structures (or in `volatile` fields for simple cases) as per common Java guidelines.
-
-Deeper `Lifecycle` integration as shown above involves runtime-mutable state such as
-a `runnable` field which will have to be declared as `volatile`. While the common
-lifecycle callbacks follow a certain order, e.g. a start callback is guaranteed to
-only happen after full initialization and a stop callback only after an initial start,
-there is a special case with the common stop before destroy arrangement: It is strongly
-recommended that the internal state in any such bean also allows for an immediate
-destroy callback without a preceding stop since this may happen during an extraordinary
-shutdown after a cancelled bootstrap or in case of a stop timeout caused by another bean.
-
-
-
-[[beans-factory-aware]]
-== `ApplicationContextAware` and `BeanNameAware`
-
-When an `ApplicationContext` creates an object instance that implements the
-`org.springframework.context.ApplicationContextAware` interface, the instance is provided
-with a reference to that `ApplicationContext`. The following listing shows the definition
-of the `ApplicationContextAware` interface:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	public interface ApplicationContextAware {
-
-		void setApplicationContext(ApplicationContext applicationContext) throws BeansException;
-	}
----
-
-Thus, beans can programmatically manipulate the `ApplicationContext` that created them,
-through the `ApplicationContext` interface or by casting the reference to a known
-subclass of this interface (such as `ConfigurableApplicationContext`, which exposes
-additional functionality). One use would be the programmatic retrieval of other beans.
-Sometimes this capability is useful. However, in general, you should avoid it, because
-it couples the code to Spring and does not follow the Inversion of Control style,
-where collaborators are provided to beans as properties. Other methods of the
-`ApplicationContext` provide access to file resources, publishing application events,
-and accessing a `MessageSource`. These additional features are described in
-xref:core/beans/context-introduction.adoc[Additional Capabilities of the `ApplicationContext`].
-
-Autowiring is another alternative to obtain a reference to the
-`ApplicationContext`. The _traditional_ `constructor` and `byType` autowiring modes
-(as described in xref:core/beans/dependencies/factory-autowire.adoc[Autowiring Collaborators]) can provide a dependency of type
-`ApplicationContext` for a constructor argument or a setter method parameter,
-respectively. For more flexibility, including the ability to autowire fields and
-multiple parameter methods, use the annotation-based autowiring features. If you do,
-the `ApplicationContext` is autowired into a field, constructor argument, or method
-parameter that expects the `ApplicationContext` type if the field, constructor, or
-method in question carries the `@Autowired` annotation. For more information, see
-xref:core/beans/annotation-config/autowired.adoc[Using `@Autowired`].
-
-When an `ApplicationContext` creates a class that implements the
-`org.springframework.beans.factory.BeanNameAware` interface, the class is provided with
-a reference to the name defined in its associated object definition. The following listing
-shows the definition of the BeanNameAware interface:
-
-[source,java,indent=0,subs="verbatim,quotes"]
----
-	public interface BeanNameAware {
-
-		void setBeanName(String name) throws BeansException;
-	}
----
-
-The callback is invoked after population of normal bean properties but before an
-initialization callback such as `InitializingBean.afterPropertiesSet()` or a custom
-init-method.
-
-
-
-[[aware-list]]
-== Other `Aware` Interfaces
-
-Besides `ApplicationContextAware` and `BeanNameAware` (discussed xref:core/beans/factory-nature.adoc#beans-factory-aware[earlier]),
-Spring offers a wide range of `Aware` callback interfaces that let beans indicate to the container
-that they require a certain infrastructure dependency. As a general rule, the name indicates the
-dependency type. The following table summarizes the most important `Aware` interfaces:
-
-[[beans-factory-nature-aware-list]]
-.Aware interfaces
-|===
-| Name| Injected Dependency| Explained in...
-
-| `ApplicationContextAware`
-| Declaring `ApplicationContext`.
-| xref:core/beans/factory-nature.adoc#beans-factory-aware[`ApplicationContextAware` and `BeanNameAware`]
-
-| `ApplicationEventPublisherAware`
-| Event publisher of the enclosing `ApplicationContext`.
-| xref:core/beans/context-introduction.adoc[Additional Capabilities of the `ApplicationContext`]
-
-| `BeanClassLoaderAware`
-| Class loader used to load the bean classes.
-| xref:core/beans/definition.adoc#beans-factory-class[Instantiating Beans]
-
-| `BeanFactoryAware`
-| Declaring `BeanFactory`.
-| xref:core/beans/beanfactory.adoc[The `BeanFactory` API]
-
-| `BeanNameAware`
-| Name of the declaring bean.
-| xref:core/beans/factory-nature.adoc#beans-factory-aware[`ApplicationContextAware` and `BeanNameAware`]
-
-| `LoadTimeWeaverAware`
-| Defined weaver for processing class definition at load time.
-| xref:core/aop/using-aspectj.adoc#aop-aj-ltw[Load-time Weaving with AspectJ in the Spring Framework]
-
-| `MessageSourceAware`
-| Configured strategy for resolving messages (with support for parameterization and
-  internationalization).
-| xref:core/beans/context-introduction.adoc[Additional Capabilities of the `ApplicationContext`]
-
-| `NotificationPublisherAware`
-| Spring JMX notification publisher.
-| xref:integration/jmx/notifications.adoc[Notifications]
-
-| `ResourceLoaderAware`
-| Configured loader for low-level access to resources.
-| xref:web/webflux-webclient/client-builder.adoc#webflux-client-builder-reactor-resources[Resources]
-
-| `ServletConfigAware`
-| Current `ServletConfig` the container runs in. Valid only in a web-aware Spring
-  `ApplicationContext`.
-| xref:web/webmvc.adoc#mvc[Spring MVC]
-
-| `ServletContextAware`
-| Current `ServletContext` the container runs in. Valid only in a web-aware Spring
-  `ApplicationContext`.
-| xref:web/webmvc.adoc#mvc[Spring MVC]
-|===
-
-Note again that using these interfaces ties your code to the Spring API and does not
-follow the Inversion of Control style. As a result, we recommend them for infrastructure
-beans that require programmatic access to the container.
-
-
-
@@ -1,779 +0,0 @@
-[[beans-factory-scopes]]
-= Bean Scopes
-
-When you create a bean definition, you create a recipe for creating actual instances
-of the class defined by that bean definition. The idea that a bean definition is a
-recipe is important, because it means that, as with a class, you can create many object
-instances from a single recipe.
-
-You can control not only the various dependencies and configuration values that are to
-be plugged into an object that is created from a particular bean definition but also control
-the scope of the objects created from a particular bean definition. This approach is
-powerful and flexible, because you can choose the scope of the objects you create
-through configuration instead of having to bake in the scope of an object at the Java
-class level. Beans can be defined to be deployed in one of a number of scopes.
-The Spring Framework supports six scopes, four of which are available only if
-you use a web-aware `ApplicationContext`. You can also create
-xref:core/beans/factory-scopes.adoc#beans-factory-scopes-custom[a custom scope.]
-
-The following table describes the supported scopes:
-
-[[beans-factory-scopes-tbl]]
-.Bean scopes
-[cols="20%,80%"]
-|===
-| Scope| Description
-
-| xref:core/beans/factory-scopes.adoc#beans-factory-scopes-singleton[singleton]
-| (Default) Scopes a single bean definition to a single object instance for each Spring IoC
-  container.
-
-| xref:core/beans/factory-scopes.adoc#beans-factory-scopes-prototype[prototype]
-| Scopes a single bean definition to any number of object instances.
-
-| xref:core/beans/factory-scopes.adoc#beans-factory-scopes-request[request]
-| Scopes a single bean definition to the lifecycle of a single HTTP request. That is,
-  each HTTP request has its own instance of a bean created off the back of a single bean
-  definition. Only valid in the context of a web-aware Spring `ApplicationContext`.
-
-| xref:core/beans/factory-scopes.adoc#beans-factory-scopes-session[session]
-| Scopes a single bean definition to the lifecycle of an HTTP `Session`. Only valid in
-  the context of a web-aware Spring `ApplicationContext`.
-
-| xref:core/beans/factory-scopes.adoc#beans-factory-scopes-application[application]
-| Scopes a single bean definition to the lifecycle of a `ServletContext`. Only valid in
-  the context of a web-aware Spring `ApplicationContext`.
-
-| xref:web/websocket/stomp/scope.adoc[websocket]
-| Scopes a single bean definition to the lifecycle of a `WebSocket`. Only valid in
-  the context of a web-aware Spring `ApplicationContext`.
-|===
-
-NOTE: A thread scope is available but is not registered by default. For more information,
-see the documentation for
-{spring-framework-api}/context/support/SimpleThreadScope.html[`SimpleThreadScope`].
-For instructions on how to register this or any other custom scope, see
-xref:core/beans/factory-scopes.adoc#beans-factory-scopes-custom-using[Using a Custom Scope].
-
-
-
-[[beans-factory-scopes-singleton]]
-== The Singleton Scope
-
-Only one shared instance of a singleton bean is managed, and all requests for beans
-with an ID or IDs that match that bean definition result in that one specific bean
-instance being returned by the Spring container.
-
-To put it another way, when you define a bean definition and it is scoped as a
-singleton, the Spring IoC container creates exactly one instance of the object
-defined by that bean definition. This single instance is stored in a cache of such
-singleton beans, and all subsequent requests and references for that named bean
-return the cached object. The following image shows how the singleton scope works:
-
-image::singleton.png[]
-
-Spring's concept of a singleton bean differs from the singleton pattern as defined in
-the Gang of Four (GoF) patterns book. The GoF singleton hard-codes the scope of an
-object such that one and only one instance of a particular class is created per
-ClassLoader. The scope of the Spring singleton is best described as being per-container
-and per-bean. This means that, if you define one bean for a particular class in a
-single Spring container, the Spring container creates one and only one instance
-of the class defined by that bean definition. The singleton scope is the default scope
-in Spring. To define a bean as a singleton in XML, you can define a bean as shown in the
-following example:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="accountService" class="com.something.DefaultAccountService"/>
-
-	<!-- the following is equivalent, though redundant (singleton scope is the default) -->
-	<bean id="accountService" class="com.something.DefaultAccountService" scope="singleton"/>
----
-
-
-
-[[beans-factory-scopes-prototype]]
-== The Prototype Scope
-
-The non-singleton prototype scope of bean deployment results in the creation of a new
-bean instance every time a request for that specific bean is made. That is, the bean
-is injected into another bean or you request it through a `getBean()` method call on the
-container. As a rule, you should use the prototype scope for all stateful beans and the
-singleton scope for stateless beans.
-
-The following diagram illustrates the Spring prototype scope:
-
-image::prototype.png[]
-
-(A data access object
-(DAO) is not typically configured as a prototype, because a typical DAO does not hold
-any conversational state. It was easier for us to reuse the core of the
-singleton diagram.)
-
-The following example defines a bean as a prototype in XML:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="accountService" class="com.something.DefaultAccountService" scope="prototype"/>
----
-
-In contrast to the other scopes, Spring does not manage the complete lifecycle of a
-prototype bean. The container instantiates, configures, and otherwise assembles a
-prototype object and hands it to the client, with no further record of that prototype
-instance. Thus, although initialization lifecycle callback methods are called on all
-objects regardless of scope, in the case of prototypes, configured destruction
-lifecycle callbacks are not called. The client code must clean up prototype-scoped
-objects and release expensive resources that the prototype beans hold. To get
-the Spring container to release resources held by prototype-scoped beans, try using a
-custom xref:core/beans/factory-extension.adoc#beans-factory-extension-bpp[bean post-processor]
-which holds a reference to beans that need to be cleaned up.
-
-In some respects, the Spring container's role in regard to a prototype-scoped bean is a
-replacement for the Java `new` operator. All lifecycle management past that point must
-be handled by the client. (For details on the lifecycle of a bean in the Spring
-container, see xref:core/beans/factory-nature.adoc#beans-factory-lifecycle[Lifecycle Callbacks].)
-
-
-
-[[beans-factory-scopes-sing-prot-interaction]]
-== Singleton Beans with Prototype-bean Dependencies
-
-When you use singleton-scoped beans with dependencies on prototype beans, be aware that
-dependencies are resolved at instantiation time. Thus, if you dependency-inject a
-prototype-scoped bean into a singleton-scoped bean, a new prototype bean is instantiated
-and then dependency-injected into the singleton bean. The prototype instance is the sole
-instance that is ever supplied to the singleton-scoped bean.
-
-However, suppose you want the singleton-scoped bean to acquire a new instance of the
-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 xref:core/beans/dependencies/factory-method-injection.adoc[Method Injection].
-
-
-
-[[beans-factory-scopes-other]]
-== Request, Session, Application, and WebSocket Scopes
-
-The `request`, `session`, `application`, and `websocket` scopes are available only
-if you use a web-aware Spring `ApplicationContext` implementation (such as
-`XmlWebApplicationContext`). If you use these scopes with regular Spring IoC containers,
-such as the `ClassPathXmlApplicationContext`, an `IllegalStateException` that complains
-about an unknown bean scope is thrown.
-
-
-
-[[beans-factory-scopes-other-web-configuration]]
-=== Initial Web Configuration
-
-To support the scoping of beans at the `request`, `session`, `application`, and
-`websocket` levels (web-scoped beans), some minor initial configuration is
-required before you define your beans. (This initial setup is not required
-for the standard scopes: `singleton` and `prototype`.)
-
-How you accomplish this initial setup depends on your particular Servlet environment.
-
-If you access scoped beans within Spring Web MVC, in effect, within a request that is
-processed by the Spring `DispatcherServlet`, no special setup is necessary.
-`DispatcherServlet` already exposes all relevant state.
-
-If you use a Servlet web container, with requests processed outside of Spring's
-`DispatcherServlet` (for example, when using JSF), you need to register the
-`org.springframework.web.context.request.RequestContextListener` `ServletRequestListener`.
-This can be done programmatically by using the `WebApplicationInitializer` interface.
-Alternatively, add the following declaration to your web application's `web.xml` file:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<web-app>
-		...
-		<listener>
-			<listener-class>
-				org.springframework.web.context.request.RequestContextListener
-			</listener-class>
-		</listener>
-		...
-	</web-app>
----
-
-Alternatively, if there are issues with your listener setup, consider using Spring's
-`RequestContextFilter`. The filter mapping depends on the surrounding web
-application configuration, so you have to change it as appropriate. The following listing
-shows the filter part of a web application:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<web-app>
-		...
-		<filter>
-			<filter-name>requestContextFilter</filter-name>
-			<filter-class>org.springframework.web.filter.RequestContextFilter</filter-class>
-		</filter>
-		<filter-mapping>
-			<filter-name>requestContextFilter</filter-name>
-			<url-pattern>/*</url-pattern>
-		</filter-mapping>
-		...
-	</web-app>
----
-
-`DispatcherServlet`, `RequestContextListener`, and `RequestContextFilter` all do exactly
-the same thing, namely bind the HTTP request object to the `Thread` that is servicing
-that request. This makes beans that are request- and session-scoped available further
-down the call chain.
-
-
-
-[[beans-factory-scopes-request]]
-=== Request scope
-
-Consider the following XML configuration for a bean definition:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="loginAction" class="com.something.LoginAction" scope="request"/>
----
-
-The Spring container creates a new instance of the `LoginAction` bean by using the
-`loginAction` bean definition for each and every HTTP request. That is, the
-`loginAction` bean is scoped at the HTTP request level. You can change the internal
-state of the instance that is created as much as you want, because other instances
-created from the same `loginAction` bean definition do not see these changes in state.
-They are particular to an individual request. When the request completes processing, the
-bean that is scoped to the request is discarded.
-
-When using annotation-driven components or Java configuration, the `@RequestScope` annotation
-can be used to assign a component to the `request` scope. The following example shows how
-to do so:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	@RequestScope
-	@Component
-	public class LoginAction {
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@RequestScope
-	@Component
-	class LoginAction {
-		// ...
-	}
----
-======
-
-
-
-[[beans-factory-scopes-session]]
-=== Session Scope
-
-Consider the following XML configuration for a bean definition:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="userPreferences" class="com.something.UserPreferences" scope="session"/>
----
-
-The Spring container creates a new instance of the `UserPreferences` bean by using the
-`userPreferences` bean definition for the lifetime of a single HTTP `Session`. In other
-words, the `userPreferences` bean is effectively scoped at the HTTP `Session` level. As
-with request-scoped beans, you can change the internal state of the instance that is
-created as much as you want, knowing that other HTTP `Session` instances that are also
-using instances created from the same `userPreferences` bean definition do not see these
-changes in state, because they are particular to an individual HTTP `Session`. When the
-HTTP `Session` is eventually discarded, the bean that is scoped to that particular HTTP
-`Session` is also discarded.
-
-When using annotation-driven components or Java configuration, you can use the
-`@SessionScope` annotation to assign a component to the `session` scope.
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	@SessionScope
-	@Component
-	public class UserPreferences {
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@SessionScope
-	@Component
-	class UserPreferences {
-		// ...
-	}
----
-======
-
-
-
-[[beans-factory-scopes-application]]
-=== Application Scope
-
-Consider the following XML configuration for a bean definition:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="appPreferences" class="com.something.AppPreferences" scope="application"/>
----
-
-The Spring container creates a new instance of the `AppPreferences` bean by using the
-`appPreferences` bean definition once for the entire web application. That is, the
-`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),
-and it is actually exposed and therefore visible as a `ServletContext` attribute.
-
-When using annotation-driven components or Java configuration, you can use the
-`@ApplicationScope` annotation to assign a component to the `application` scope. The
-following example shows how to do so:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	@ApplicationScope
-	@Component
-	public class AppPreferences {
-		// ...
-	}
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	@ApplicationScope
-	@Component
-	class AppPreferences {
-		// ...
-	}
----
-======
-
-
-
-[[beans-factory-scopes-websocket]]
-=== WebSocket Scope
-
-WebSocket scope is associated with the lifecycle of a WebSocket session and applies to
-STOMP over WebSocket applications, see
-xref:web/websocket/stomp/scope.adoc[WebSocket scope] for more details.
-
-
-
-[[beans-factory-scopes-other-injection]]
-=== Scoped Beans as Dependencies
-
-The Spring IoC container manages not only the instantiation of your objects (beans),
-but also the wiring up of collaborators (or dependencies). If you want to inject (for
-example) an HTTP request-scoped bean into another bean of a longer-lived scope, you may
-choose to inject an AOP proxy in place of the scoped bean. That is, you need to inject
-a proxy object that exposes the same public interface as the scoped object but that can
-also retrieve the real target object from the relevant scope (such as an HTTP request)
-and delegate method calls onto the real object.
-
-[NOTE]
-====
-You may also use `<aop:scoped-proxy/>` between beans that are scoped as `singleton`,
-with the reference then going through an intermediate proxy that is serializable
-and therefore able to re-obtain the target singleton bean on deserialization.
-
-When declaring `<aop:scoped-proxy/>` against a bean of scope `prototype`, every method
-call on the shared proxy leads to the creation of a new target instance to which the
-call is then being forwarded.
-
-Also, scoped proxies are not the only way to access beans from shorter scopes in a
-lifecycle-safe fashion. You may also declare your injection point (that is, the
-constructor or setter argument or autowired field) as `ObjectFactory<MyTargetBean>`,
-allowing for a `getObject()` call to retrieve the current instance on demand every
-time it is needed -- without holding on to the instance or storing it separately.
-
-As an extended variant, you may declare `ObjectProvider<MyTargetBean>` which delivers
-several additional access variants, including `getIfAvailable` and `getIfUnique`.
-
-The JSR-330 variant of this is called `Provider` and is used with a `Provider<MyTargetBean>`
-declaration and a corresponding `get()` call for every retrieval attempt.
-See xref:core/beans/standard-annotations.adoc[here] for more details on JSR-330 overall.
-====
-
-The configuration in the following example is only one line, but it is important to
-understand the "`why`" as well as the "`how`" behind it:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<?xml version="1.0" encoding="UTF-8"?>
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:aop="http://www.springframework.org/schema/aop"
-		xsi:schemaLocation="http://www.springframework.org/schema/beans
-			https://www.springframework.org/schema/beans/spring-beans.xsd
-			http://www.springframework.org/schema/aop
-			https://www.springframework.org/schema/aop/spring-aop.xsd">
-
-		<!-- an HTTP Session-scoped bean exposed as a proxy -->
-		<bean id="userPreferences" class="com.something.UserPreferences" scope="session">
-			<!-- instructs the container to proxy the surrounding bean -->
-			<aop:scoped-proxy/> <1>
-		</bean>
-
-		<!-- a singleton-scoped bean injected with a proxy to the above bean -->
-		<bean id="userService" class="com.something.SimpleUserService">
-			<!-- a reference to the proxied userPreferences bean -->
-			<property name="userPreferences" ref="userPreferences"/>
-		</bean>
-	</beans>
----
-<1> The line that defines the proxy.
-
-To create such a proxy, you insert a child `<aop:scoped-proxy/>` element into a
-scoped bean definition (see
-xref:core/beans/factory-scopes.adoc#beans-factory-scopes-other-injection-proxies[Choosing the Type of Proxy to Create]
-and xref:core/appendix/xsd-schemas.adoc[XML Schema-based configuration]).
-
-Why do definitions of beans scoped at the `request`, `session` and custom-scope
-levels require the `<aop:scoped-proxy/>` element in common scenarios?
-Consider the following singleton bean definition and contrast it with
-what you need to define for the aforementioned scopes (note that the following
-`userPreferences` bean definition as it stands is incomplete):
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="userPreferences" class="com.something.UserPreferences" scope="session"/>
-
-	<bean id="userManager" class="com.something.UserManager">
-		<property name="userPreferences" ref="userPreferences"/>
-	</bean>
----
-
-In the preceding example, the singleton bean (`userManager`) is injected with a reference
-to the HTTP `Session`-scoped bean (`userPreferences`). The salient point here is that the
-`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).
-
-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
-bean as a dependency into singleton bean). Rather, you need a single `userManager`
-object, and, for the lifetime of an HTTP `Session`, you need a `userPreferences` object
-that is specific to the HTTP `Session`. Thus, the container creates an object that
-exposes the exact same public interface as the `UserPreferences` class (ideally an
-object that is a `UserPreferences` instance), which can fetch the real
-`UserPreferences` object from the scoping mechanism (HTTP request, `Session`, and so
-forth). The container injects this proxy object into the `userManager` bean, which is
-unaware that this `UserPreferences` reference is a proxy. In this example, when a
-`UserManager` instance invokes a method on the dependency-injected `UserPreferences`
-object, it is actually invoking a method on the proxy. The proxy then fetches the real
-`UserPreferences` object from (in this case) the HTTP `Session` and delegates the
-method invocation onto the retrieved real `UserPreferences` object.
-
-Thus, you need the following (correct and complete) configuration when injecting
-`request-` and `session-scoped` beans into collaborating objects, as the following example
-shows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="userPreferences" class="com.something.UserPreferences" scope="session">
-		<aop:scoped-proxy/>
-	</bean>
-
-	<bean id="userManager" class="com.something.UserManager">
-		<property name="userPreferences" ref="userPreferences"/>
-	</bean>
----
-
-[[beans-factory-scopes-other-injection-proxies]]
-==== Choosing the Type of Proxy to Create
-
-By default, when the Spring container creates a proxy for a bean that is marked up with
-the `<aop:scoped-proxy/>` element, a CGLIB-based class proxy is created.
-
-[NOTE]
-====
-CGLIB proxies do not intercept private methods. Attempting to call a private method
-on such a proxy will not delegate to the actual scoped target object.
-====
-
-Alternatively, you can configure the Spring container to create standard JDK
-interface-based proxies for such scoped beans, by specifying `false` for the value of
-the `proxy-target-class` attribute of the `<aop:scoped-proxy/>` element. Using JDK
-interface-based proxies means that you do not need additional libraries in your
-application classpath to affect such proxying. However, it also means that the class of
-the scoped bean must implement at least one interface and that all collaborators
-into which the scoped bean is injected must reference the bean through one of its
-interfaces. The following example shows a proxy based on an interface:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<!-- DefaultUserPreferences implements the UserPreferences interface -->
-	<bean id="userPreferences" class="com.stuff.DefaultUserPreferences" scope="session">
-		<aop:scoped-proxy proxy-target-class="false"/>
-	</bean>
-
-	<bean id="userManager" class="com.stuff.UserManager">
-		<property name="userPreferences" ref="userPreferences"/>
-	</bean>
----
-
-For more detailed information about choosing class-based or interface-based proxying,
-see xref:core/aop/proxying.adoc[Proxying Mechanisms].
-
-
-
-[[beans-factory-scopes-injection]]
-=== Injecting Request/Session References Directly
-
-As an alternative to factory scopes, a Spring `WebApplicationContext` also supports
-the injection of `HttpServletRequest`, `HttpServletResponse`, `HttpSession`,
-`WebRequest` and (if JSF is present) `FacesContext` and `ExternalContext` into
-Spring-managed beans, simply through type-based autowiring next to regular injection
-points for other beans. Spring generally injects proxies for such request and session
-objects which has the advantage of working in singleton beans and serializable beans
-as well, similar to scoped proxies for factory-scoped beans.
-
-
-
-[[beans-factory-scopes-custom]]
-== Custom Scopes
-
-The bean scoping mechanism is extensible. You can define your own
-scopes or even redefine existing scopes, although the latter is considered bad practice
-and you cannot override the built-in `singleton` and `prototype` scopes.
-
-
-[[beans-factory-scopes-custom-creating]]
-=== Creating a Custom Scope
-
-To integrate your custom scopes into the Spring container, you need to implement the
-`org.springframework.beans.factory.config.Scope` interface, which is described in this
-section. For an idea of how to implement your own scopes, see the `Scope`
-implementations that are supplied with the Spring Framework itself and the
-{spring-framework-api}/beans/factory/config/Scope.html[`Scope`] javadoc,
-which explains the methods you need to implement in more detail.
-
-The `Scope` interface has four methods to get objects from the scope, remove them from
-the scope, and let them be destroyed.
-
-The session scope implementation, for example, returns the session-scoped bean (if it
-does not exist, the method returns a new instance of the bean, after having bound it to
-the session for future reference). The following method returns the object from the
-underlying scope:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	Object get(String name, ObjectFactory<?> objectFactory)
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	fun get(name: String, objectFactory: ObjectFactory<*>): Any
----
-======
-
-The session scope implementation, for example, removes the session-scoped bean from the
-underlying session. The object should be returned, but you can return `null` if the
-object with the specified name is not found. The following method removes the object from
-the underlying scope:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	Object remove(String name)
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	fun remove(name: String): Any
----
-======
-
-The following method registers a callback that the scope should invoke when it is
-destroyed or when the specified object in the scope is destroyed:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	void registerDestructionCallback(String name, Runnable destructionCallback)
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	fun registerDestructionCallback(name: String, destructionCallback: Runnable)
----
-======
-
-See the {spring-framework-api}/beans/factory/config/Scope.html#registerDestructionCallback[javadoc]
-or a Spring scope implementation for more information on destruction callbacks.
-
-The following method obtains the conversation identifier for the underlying scope:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	String getConversationId()
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	fun getConversationId(): String
----
-======
-
-This identifier is different for each scope. For a session scoped implementation, this
-identifier can be the session identifier.
-
-
-
-[[beans-factory-scopes-custom-using]]
-=== Using a Custom Scope
-
-After you write and test one or more custom `Scope` implementations, you need to make
-the Spring container aware of your new scopes. The following method is the central
-method to register a new `Scope` with the Spring container:
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	void registerScope(String scopeName, Scope scope);
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	fun registerScope(scopeName: String, scope: Scope)
----
-======
-
-This method is declared on the `ConfigurableBeanFactory` interface, which is available
-through the `BeanFactory` property on most of the concrete `ApplicationContext`
-implementations that ship with Spring.
-
-The first argument to the `registerScope(..)` method is the unique name associated with
-a scope. Examples of such names in the Spring container itself are `singleton` and
-`prototype`. The second argument to the `registerScope(..)` method is an actual instance
-of the custom `Scope` implementation that you wish to register and use.
-
-Suppose that you write your custom `Scope` implementation, and then register it as shown
-in the next example.
-
-NOTE: The next example uses `SimpleThreadScope`, which is included with Spring but is not
-registered by default. The instructions would be the same for your own custom `Scope`
-implementations.
-
-[tabs]
-======
-Java::
-+
-[source,java,indent=0,subs="verbatim,quotes",role="primary"]
----
-	Scope threadScope = new SimpleThreadScope();
-	beanFactory.registerScope("thread", threadScope);
----
-
-Kotlin::
-+
-[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
----
-	val threadScope = SimpleThreadScope()
-	beanFactory.registerScope("thread", threadScope)
----
-======
-
-You can then create bean definitions that adhere to the scoping rules of your custom
-`Scope`, as follows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<bean id="..." class="..." scope="thread">
----
-
-With a custom `Scope` implementation, you are not limited to programmatic registration
-of the scope. You can also do the `Scope` registration declaratively, by using the
-`CustomScopeConfigurer` class, as the following example shows:
-
-[source,xml,indent=0,subs="verbatim,quotes"]
----
-	<?xml version="1.0" encoding="UTF-8"?>
-	<beans xmlns="http://www.springframework.org/schema/beans"
-		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		xmlns:aop="http://www.springframework.org/schema/aop"
-		xsi:schemaLocation="http://www.springframework.org/schema/beans
-			https://www.springframework.org/schema/beans/spring-beans.xsd
-			http://www.springframework.org/schema/aop
-			https://www.springframework.org/schema/aop/spring-aop.xsd">
-
-		<bean class="org.springframework.beans.factory.config.CustomScopeConfigurer">
-			<property name="scopes">
-				<map>
-					<entry key="thread">
-						<bean class="org.springframework.context.support.SimpleThreadScope"/>
-					</entry>
-				</map>
-			</property>
-		</bean>
-
-		<bean id="thing2" class="x.y.Thing2" scope="thread">
-			<property name="name" value="Rick"/>
-			<aop:scoped-proxy/>
-		</bean>
-
-		<bean id="thing1" class="x.y.Thing1">
-			<property name="thing2" ref="thing2"/>
-		</bean>
-
-	</beans>
----
-
-NOTE: When you place `<aop:scoped-proxy/>` within a `<bean>` declaration for a
-`FactoryBean` implementation, it is the factory bean itself that is scoped, not the object
-returned from `getObject()`.
-
-
-
-
--- a/Show More
+++ b/Show More