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.
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.
exclude module: spring-boot-starter-tomcat
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.
In this post, I will show you how you can use content jar files to separate the front-end development experience for your Spring Boot projects while still keeping your deployments simple.
I recently did a spike to get a Groovy-based Spring Boot project to communicate with an AngularJS/Yeoman front-end via the Websockets/SockJS support provided by Spring.
Here are a few resources and problems I ran into while integrating the project.
This post is a step by step guide on deploying a Spring Boot application on Cloud Foundry using the spring jar feature introduced in 1.0.0.RC2.
If you read the Cloud Foundry documentation, they would claim that the proper way to deploy Spring Boot Groovy scripts is via:
spring grab *.groovy
Unfortunately, this approach is almost as effective as Sex Panther Cologne.
It fails badly when you try to include other starter packs, such as the websocket starter pack.
Using the jar approach outlined here allows us to overcome the errors that you might encounter in Cloud Foundry otherwise. Continue reading