diff --git a/src/asciidoc/index.adoc b/src/asciidoc/index.adoc
index 6223477405..e34602dc9c 100644
--- a/src/asciidoc/index.adoc
+++ b/src/asciidoc/index.adoc
@@ -19012,6 +19012,13 @@ Let's take a look at some examples with XML configuration and `@Configuration` c
+
+
+
+
+
+
----
@@ -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 {
}