DataSource initialization fails for tests if @EnableCaching is on

[ericdahl]

I ran into a strange issue when enabling caching on an app: my tests started failing due to the database not having been loaded with data from data.sql.

Here's a test case that reproduces it: https://github.com/ericdahl/spring-boot-db-initialization-test

$ git clone https://github.com/ericdahl/spring-boot-db-initialization-test.git
$ cd spring-boot-db-initialization-test
$ mvn test
...
(various output)
2014-10-14 10:31:46.998  INFO 3788 --- [           main] o.s.jdbc.datasource.init.ScriptUtils     : Executing SQL script from URL [file:/Users/edahl/repos/github/spring-boot-db-initialization-test/target/classes/schema.sql]
2014-10-14 10:31:46.999  INFO 3788 --- [           main] o.s.jdbc.datasource.init.ScriptUtils     : Executed SQL script from URL [file:/Users/edahl/repos/github/spring-boot-db-initialization-test/target/classes/schema.sql] in 1 ms.
2014-10-14 10:31:47.000  WARN 3788 --- [           main] o.s.b.a.jdbc.DataSourceInitializer       : Could not send event to complete DataSource initialization (ApplicationEventMulticaster not initialized - call 'refresh' before multicasting events via the context: org.springframework.web.context.support.GenericWebApplicationContext@4cc5aa00: startup date [Tue Oct 14 10:31:45 PDT 2014]; root of context hierarchy)
...
Expected: is a value greater than <0>
     but: <0> was equal to <0>

If I comment out @EnableCaching in Application.java, the test passes and there's no warning message emitted from the DataSourceInitializer. Alternatively, if I comment out @WebAppConfiguration in the test, it passes.

This was reproduced with:

• 1.1.7.RELEASE
• 1.1.8.RELEASE
• 1.2.0.BUILD-SNAPSHOT

[snicoll]

Interesting, thanks. It looks like we are forcing that bean to start "too early" in those cases.

[wilkinsona]

Many thanks for the recreation @ericdahl. Here's what's happening:

1. @EnableCaching switches on proxying and InfrastructureAdvisorAutoProxyCreator starts post-processing beans
2. InfrastructureAdvisorAutoProxyCreator looks for all Advisor beans. This triggers the creation of ProxyCachingConfiguration as it's responsible for creating BeanFactoryCacheOperationSourceAdvisor
3. ProxyCachingConfiguration depends on a Collection of CacheManager beans. This triggers the creation of Application as it declares a CacheManager bean
4. Application depends on a DataSource so creation of the DataSource is triggered
5. DataSourceInitializerPostProcessor kicks in and creates DataSourceInitializer
6. DataSourceInitializer attempts to publish an event and it fails

One way to avoid this problem is to move the configuration of the CacheManager bean into a separate configuration class:

@Configuration
@ComponentScan
@EnableAutoConfiguration
@EnableCaching
public class Application
{
    @Autowired
    private DataSource dataSource;

    public static void main(String[] args)
    {
        SpringApplication.run(Application.class, args);
    }

    @Configuration
    static class CacheConfiguration {

        @Bean
        public CacheManager cacheManager() {
            return new ConcurrentMapCacheManager("widgetCache");
        }   
    }
}

[dsyer]

There's not much we can do about this in Spring Boot. I think Stephane is going to take this to the @EnableCaching implementation in Spring. BTW see similar analysis here if you're interested: https://gist.github.com/dsyer/ebeb25d5afbdd9242cd5.

[snicoll]

Indeed, SPR-12336

[snicoll]

@wilkinsona I am actually thinking of closing this one. SPR-12336 has been fixed and will be available for boot 1.2.RC1. The project attached works fine with the snapshot. Thoughts?

[wilkinsona]

Will the fix be backported to 4.0.8? This issue was reported against 1.1.x so, if possible, it'd be good to fix it there too.

[snicoll]

It won't. SmartInitializingSingleton is new in 4.1 and won't be backported. Is that a real problem?

[wilkinsona]

No, I don't think so. Especially given that 1.2 will be released in the next few weeks.