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.

Spring Boot Recipe: Reading and Validating Lists of Configuration Properties

In one of my Spring Boot microservices, I want to keep track of a list of servers that can be externally configurable.

I can have zero to infinity servers, so I want my application to allow me to easily define this.

I also want to be able to check that the configuration is correct, so I don’t accidentally forget to enter a url or a name for my server.

In this post, I will show you how you can use the Spring ConfigurationProperties to organize and validate a map of configuration values.
Continue reading

Adding an optional internal artifactory repository to Gradle to speed up builds

For Asgard 2, we’re developing heavily with Spring Boot, Groovy and Gradle.

For our jenkins jobs, we found that our internal artifactory repository is much faster than Bintray’s jcenter. Due to the large number of dependencies in the project, a project that takes 30 minutes downloading and building with jcenter only takes 3 minutes using an internal artifactory.

Since our internal repository is only available to us within our network, we don’t really want to expose those credentials in the project we eventually want to open source.

In this post, I will show you how we add an optional internal artifactory repository to our open source builds.

Continue reading

Setting a Tomcat version with Spring Boot and Gradle

Spring Boot allows you to easily specify a tomcat version when using Maven (Docs). But there doesn’t seem to be an equivalent mechanism for Gradle.

To lock down a specific tomcat version for war deployment, I found that I had to exclude the starter-tomcat module and add the dependencies specified in the tomcat starter POM in my Spring Boot project’s build.gradle file.

compile('org.springframework.boot:spring-boot-starter-web:1.0.0.RC4'){
   exclude module: spring-boot-starter-tomcat
}
providedRuntime 'org.apache.tomcat.embed:tomcat-embed-core:7.0.52'
providedRuntime 'org.apache.tomcat.embed:tomcat-embed-el:7.0.52'
providedRuntime 'org.apache.tomcat.embed:tomcat-embed-logging-juli:7.0.52'
providedRuntime 'org.apache.tomcat:tomcat7-websocket:7.0.52'

Note: embed-el doesn’t seem to be included in versions below 7.0.52.

I imagine a similar approach would be needed to use Jetty 9.