Add explanation for the special 'default' profile

Better integrated explanation of the 'default' profile with both XML
and Java config examples showing the same thing.

Issue: SPR-11256

src/asciidoc/index.adoc

@@ -19012,6 +19012,13 @@ Let's take a look at some examples with XML configuration and `@Configuration` c
 			<jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/>
 		</beans>
 
+		<beans profile="default">
+			<jdbc:embedded-database id="dataSource">
+				<jdbc:script
+					location="classpath:com/bank/config/sql/schema.sql"/>
+			</jdbc:embedded-database>
+		</beans>
+
 	</beans>
 ----
 
@@ -19040,8 +19047,8 @@ When `TransferServiceTest` is run, its `ApplicationContext` will be loaded from
 `app-config.xml` configuration file in the root of the classpath. If you inspect
 `app-config.xml` you'll notice that the `accountRepository` bean has a dependency on a
 `dataSource` bean; however, `dataSource` is not defined as a top-level bean. Instead,
-`dataSource` is defined twice: once in the __production__ profile and once in the
-__dev__ profile.
+`dataSource` is defined three times, that is the __production__ profile, the
+__dev__ profile and the __default__ profile.
 
 By annotating `TransferServiceTest` with `@ActiveProfiles("dev")` we instruct the Spring
 TestContext Framework to load the `ApplicationContext` with the active profiles set to
@@ -19049,6 +19056,12 @@ TestContext Framework to load the `ApplicationContext` with the active profiles
 `accountRepository` bean will be wired with a reference to the development `DataSource`.
 And that's likely what we want in an integration test.
 
+It is sometimes useful to assign beans to a `default` profile. Beans within the default profile
+are only included when no other profile is specifically activated. This can be used to define
+_fallback_ beans to be used in the application's default state. For example, you may
+explicitly provide a data source for `dev` and `production` profiles, but define an in-memory
+data source as a default when neither of these are specified.
+
 The following code listings demonstrate how to implement the same configuration and
 integration test but using `@Configuration` classes instead of XML.
 
@@ -19085,6 +19098,23 @@ integration test but using `@Configuration` classes instead of XML.
 	}
 ----
 
+[source,java,indent=0]
+[subs="verbatim,quotes"]
+----
+	@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();
+		}
+	}
+----
+
 [source,java,indent=0]
 [subs="verbatim,quotes"]
 ----
@@ -19120,7 +19150,8 @@ integration test but using `@Configuration` classes instead of XML.
 	@ContextConfiguration(classes = {
 			TransferServiceConfig.class,
 			StandaloneDataConfig.class,
-			JndiDataConfig.class})
+			JndiDataConfig.class,
+			DefaultDataConfig.class})
 	@ActiveProfiles("dev")
 	public class TransferServiceTest {
 
@@ -19134,7 +19165,7 @@ integration test but using `@Configuration` classes instead of XML.
 	}
 ----
 
-In this variation, we have split the XML configuration into three independent
+In this variation, we have split the XML configuration into four independent
 `@Configuration` classes:
 
 * `TransferServiceConfig`: acquires a `dataSource` via dependency injection using
@@ -19143,9 +19174,11 @@ In this variation, we have split the XML configuration into three independent
   developer tests
 * `JndiDataConfig`: defines a `dataSource` that is retrieved from JNDI in a production
   environment
+* `DefaultDataConfig`: defines a `dataSource` for a default embedded database in case
+  no profile is active
 
 As with the XML-based configuration example, we still annotate `TransferServiceTest`
-with `@ActiveProfiles("dev")`, but this time we specify all three configuration classes
+with `@ActiveProfiles("dev")`, but this time we specify all four configuration classes
 via the `@ContextConfiguration` annotation. The body of the test class itself remains
 completely unchanged.
 
@@ -19165,7 +19198,8 @@ annotations) has been moved to an abstract superclass, `AbstractIntegrationTest`
 	@ContextConfiguration(classes = {
 			TransferServiceConfig.class,
 			StandaloneDataConfig.class,
-			JndiDataConfig.class})
+			JndiDataConfig.class,
+			DefaultDataConfig.class})
 	@ActiveProfiles("dev")
 	public abstract class AbstractIntegrationTest {
 	}