Polish explanation of the 'default' profile

Issue: SPR-11256
This commit is contained in:
Sam Brannen 2014-01-14 21:05:40 +01:00
parent bac9f43b66
commit 5ee89a3021
1 changed files with 6 additions and 6 deletions

View File

@ -19047,20 +19047,20 @@ 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 three times, that is the __production__ profile, the
__dev__ profile and the __default__ profile.
`dataSource` is defined three times: in 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
`{"dev"}`. As a result, an embedded database will be created, and the
`accountRepository` bean will be wired with a reference to the development `DataSource`.
And that's likely what we want in an integration test.
`{"dev"}`. As a result, an embedded database will be created and populated with test data,
and the `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.
data source as a default when neither of these is active.
The following code listings demonstrate how to implement the same configuration and
integration test but using `@Configuration` classes instead of XML.