Integration Testing Spring applications mandates to create small dedicated configuration fragments and to assemble them either during normal run of the application or during tests. Even in the latter case, different fragments can be assembled in different tests.
However, this practice doesn’t handle the use-case where I want to use the application in two different environments. As an example, I might want to use a JNDI datasource in deployed environments and a direct connection when developing on my local machine. Assembling different fragment combinations is not possible, as I want to run the application in both cases, not test it.
My only requirement is that the default should use the JNDI datasource, while activating a flag - a profile, should switch to the direct connection.
The Pavlovian reflex in this case would be to add a simple condition in the @Configuration class.
@Configuration
public class MyConfiguration {
@Autowired
private Environment env;
@Bean
public DataSource dataSource() throws Exception {
if (env.acceptsProfiles("dev")) {
org.apache.tomcat.jdbc.pool.DataSource dataSource = new org.apache.tomcat.jdbc.pool.DataSource();
dataSource.setDriverClassName("org.h2.Driver");
dataSource.setUrl("jdbc:h2:file:~/conditional");
dataSource.setUsername("sa");
return dataSource;
}
JndiDataSourceLookup dataSourceLookup = new JndiDataSourceLookup();
return dataSourceLookup.getDataSource("java:comp/env/jdbc/conditional");
}
}Starting to use this kind flow control statements is the beginning of the end, as it will lead to adding more control flow statements in the future, which will lead in turn to a tangled mess of spaghetti configuration, and ultimately to an unmaintainable application.
Spring Boot offers a nice alternative to handle this use-case with different flavors of @ConditionalXXX annotations.
Using them have the following advantages while doing the job: easy to use, readable and limited.
While the latter point might seem to be a drawback, it’s the biggest asset IMHO (not unlike Maven plugins).
Code is powerful, and with great power must come great responsibility, something that is hardly possible during the course of a project with deadlines and pressure from the higher-ups.
That’s the main reason one of my colleagues advocates XML over JavaConfig: with XML, you’re sure there won’t be any abuse while the project runs its course.
But let’s stop the philosophy and back to @ConditionalXXX annotations.
Basically, putting such an annotation on a @Bean method will invoke this method and put the bean in the factory based on a dedicated condition.
There are many of them, here are some important ones:
- Dependent on Java version, newer or older -
@ConditionalOnJava - Dependent on a bean present in factory -
@ConditionalOnBean, and its opposite, dependent on a bean name not present -@ConditionalOnMissingBean - Dependent on a class present on the classpath -
@ConditionalOnClass, and its opposite@ConditionalOnMissingClass - Whether it’s a web application or not -
@ConditionalOnWebApplicationand@ConditionalOnNotWebApplication - etc.
Note that the whole list of existing conditions can be browsed in Spring Boot’s org.springframework.boot.autoconfigure.condition package.
With this information, we can migrate the above snippet to a more robust implementation:
@Configuration
public class MyConfiguration {
@Bean
@Profile("dev")
public DataSource dataSource() throws Exception {
org.apache.tomcat.jdbc.pool.DataSource dataSource = new org.apache.tomcat.jdbc.pool.DataSource();
dataSource.setDriverClassName("org.h2.Driver");
dataSource.setUrl("jdbc:h2:file:~/localisatordb");
dataSource.setUsername("sa");
return dataSource;
}
@Bean
@ConditionalOnMissingBean(DataSource.class)
public DataSource fakeDataSource() {
JndiDataSourceLookup dataSourceLookup = new JndiDataSourceLookup();
return dataSourceLookup.getDataSource("java:comp/env/jdbc/conditional");
}
}The configuration is now neatly separated into two different methods, the first method will be called only when the dev profile is active while the second will be when the first method is not called, hence when the dev profile is not active.
Finally, the best thing in that feature is that it is easily extensible, as it depends only on the @Conditional annotation and the Condition interface (who are part of Spring proper, not Spring Boot).
Here’s a simple example in Maven/IntelliJ format for you to play with. Have fun!