Now that logging aggregators are becoming ubiquitous, a common issue that we, developers, have to face is how to connect the log output of our applications to those tools. Some of the issues that we encounter during that process are: · Usually we don’t use an aggregator in development, we simply want to see all the logs in the development console, so the application has to start without issues when there is no aggregator listening.

Most of the times I had used the “relatively new” streams in Java, it was for straight-forward tasks with operations on one stream. I sometimes use more sophisticated collectors, like Collectors.toMap, but recently I had to use more complicated stuff to solve a real problem and I thought it might interesting writing about it, as the examples one usually reads about are synthetic and lack the focus of solving a real problem.

One of the issues that usually comes up when you have an application up & running is finding out what’s deployed in the different servers so you can know if what you committed in the source code repository is deployed in those releases or not. That thing that sounds so trivial becomes not that easy when you add automatic deployment, branches and everything that allows you to be “agile”, so you need to add some automatic mechanisms to your release and deployment process in order to make it easy again.

Recently, I’ve been installing the “Elastic Stack”, previously known as ELK, and one of the steps took me a while to figure it out, due to outdated documentation and missing pieces in the examples for the specific syntax that you need to get right, so here it comes: Imagine you have already gone through the Elastic Stack quick start and you have it secured with basic authentication, either directly through the configuration or through the recommended X-Pack plugin.

Spring Boot web applications, like many others unless you go for the mono-threaded option (yuck!) serve requests concurrently. That brings many advantages, but one of the drawbacks that come with it is that it makes harder to trace what each request is doing, as it is doing it while other requests are doing other, often similar, things. That hurts logging information badly, as the messages generated for one request can easily be intermingled with other messages generated for other requests.

Recently, I started using Spring caching in my Spring Boot applications and I came across a very nice entry in Daniel Olszewski’s blog (MULTIPLE TTL CACHES IN SPRING BOOT) that indeed explains how to set up multiple caches in Spring Boot with a specified TTL (Time To Live) setting and is really worth reading it as it even explains how to test the functionality. So, if you have not read it already, I invite you to do go ahead and do it now, as I’ll build on top of that.

Summary Nowadays, there are tons of literature and virtual ink written about how to develop for the cloud and make your applications Internet-scale. But how about those of us where the scale of our problems do not fit such model? Well, even if you are not developing for the cloud and you don’t need to go full scale with the Twelve-Factor App recommendations, there are still many benefits that can still be enjoyed by sticking to the main principles behind them.

One of the issues with Spring Boot that I have come across a couple of times and that are usually a bit painful to solve is how to configure multiple datasources and mappers with MyBatis. I have always had to browse the web, check different sources and try different examples while fighting unclear error messages until I get it right. And then the next time configuration has changed in some subtle way either in MyBatis or Spring Boot and it’s all over again.