The Spring Boot CLI is quite useful when building small groovy scripts.
I recently created a small dockerfile based on Java 8 and ubuntu that makes it easy to use the Spring Boot CLI in Docker.
This is available via the docker hub.
To start, simply add
to your docker file and it will provide you with a docker image with Spring boot CLI, Java 8 and ubuntu to work on your applications.
This post contains a full example on how to use this.
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
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.
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
Any place where you want this bean used, you should specify that is it optionally required:
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.
In a previous post, I highlighted how we use Gradle to create content jars that can be used in your Spring Boot application.
In this post, I will show you how to overwrite individual files within your content jar to let your server provide a custom configuration.
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.
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.