From c9044151f5eb63f4d2bcc5a552c66ebb286a603c Mon Sep 17 00:00:00 2001 From: Stephane Nicoll Date: Wed, 8 Jan 2014 16:31:50 +0100 Subject: [PATCH] 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 | 46 +++++++++++++++++++++++++++++++++++------ 1 file changed, 40 insertions(+), 6 deletions(-) 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 { }