Allow configuration to specify randomly generated database name

[robfletcher]

Currently (it seems to me) the only way to have an embedded test database use a random name is to completely override the dataSource bean or to use XML configuration with<embedded-database generate-name="true"/>.
This PR makes it possible to do so by using spring.datasource.generate-name = true in properties or yaml config.

This is useful when running tests with multiple application context configurations as all cached contexts will try to destroy their dataSource bean which by default are all pointing to the same in-memory H2 database.
The first will successfully shut down the embedded database and any subsequent ones will throw exceptions.
This does not cause the tests to fail but does produce a large stacktrace.

[pivotal-issuemaster]

@robfletcher Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[pivotal-issuemaster]

@robfletcher Thank you for signing the Contributor License Agreement!

[snicoll]

Thanks for the PR! I actually hit that issue as well. With Boot 1.4 and slicing we tend to create more contexts than before. Unfortunately, the in-memory database might be shared (that's what I saw with H2 at a customer at least). They are using data.sql and had to flip continueOnError to avoid their test suite to crash. This isn't new but slicing doesn't help in this area.

Having X in-memory databases lying around until the test suite completes is probably a concern then...

[robfletcher]

I'd argue it's no more a concern than having X application contexts lying around!

This isn't new functionality, it's just exposing functionality already available to people using XML config or rolling their own data source.

It looks like these are the original issues for the unique name option and the XML attribute that exposes it.
https://jira.spring.io/browse/SPR-8849
https://jira.spring.io/browse/SPR-12835

[snicoll]

I am not sure I agree. Application context caching is here since the early days of the test context framework. Us generating a new database per context is an entire new thing that can have side effects.

Having said that we should fix this issue one way or the other ;)

[snicoll]

We just discussed this change and we all agree that the current situation can lead to unpredictable results. More than the error on shutdown, the fact that a single database is shared by multiple application contexts is quite problematic. We'll integrate this PR with 1.4, flipping that property to true in tests for 1.5