Monthly Archives: October 2014

Spring Boot Shannanigan: Overriding properties via the command line when using Gradle

If you use Spring Boot and Gradle, you might sometimes find yourself in a homicidal rage when looking stuff up in the Spring Boot Reference Manual and encounter lines like ‘or specify on the command line using the switch –spring.profiles.active=dev,hsqldb.‘ because command line switches don’t bloody work in Gradle.

You can overcome this problem by adding the parameters to you application.properties file and reverting it before commit. It is a terrible solution that should be tied up and shot with arrows.

Better yet, you can use this dirty little trick to provide your own properties and it works with the Gradle command line.

Let’s say you want to provide your own value to spring.profiles.active, all you need to do is capitalize the letters and change the dots to underscores and Spring Boot will pick up the change.

./gradlew bootRun --spring.profiles.active=dev,hsqldb 

does nothing, but

SPRING_PROFILES_ACTIVE=dev,hsqldb ./gradlew bootRun

works like a charm.

The reason this works is that while Gradle won’t pass along system properties to Spring Boot, it does pass along environment variables. Spring Boot is able to pick up the environment variable when it resolves the property and the last ten months of changing property files by hand makes me look like a total and absolute moron.

You can use this mechanism to set server ports,

 SERVER_PORT=9000 ./gradlew bootRun 

Set your own properties

 MY_SERVER_URL=http://www.springtoot.com/ ./gradlew bootRun

And specify the name of the config you want to use:

 SPRING_CONFIG_NAME=killmenow ./gradlew bootRun

Yipikaye!

Spring Boot Recipe: Embedding local instances of datastores

A technique we found very useful in our Spring Boot development process is to embed a local version of Redis, Cassandra or Elastic Search that starts when we call bootRun.

Embedding these datastores also simplifies the setup needed for Continous Delivery and testing, since all the bits needed to run all our tests is available within our source code.

In this post, I will give an example configuration of how we launch a local elastic search instance and how this can then be used.

Continue reading

Spring Boot Recipe: Turn beans on and off by setting a property

In Spring Boot, you can use the @ConditionalOnProperty annotation to enable or disable a particular bean based on the presence of a property. This is very useful if you want to provide optional features to your microservice.

To do so, add the annotation either at the class or bean level, as follows

@ConditionalOnProperty(value='mybean.enabled')
@Bean 
MyOptionalClass optionalBean(){
}

Any place where you want this bean used, you should specify that is it optionally required:

@Autowired(required=false)
MyOptionalClass optionalClass

And that’s it. Your optionalClass bean should resolve to null when you specify mybean.enabled=false in your application.properties or system property file, or if it does not exist.

This mechanism is used extensively in Spring Boot itself, for example to turn on autoconfiguration in Spring social.

Warning, this blog post applies to Spring Boot 1.1.x and below, the annotation is slightly different in Spring Boot 1.2.