You may know I’m a big fan of OpenTelemetry. I recently finished developing a master class for the YOW! conference at the end of the year. During development, I noticed massive differences in configuration and results across programming languages. Even worse, differences exist across frameworks inside the same programming language.

Imagine an organization with the following practices: Commits code on GitHubRuns its CI/CD pipelines with GitHub ActionsRuns its production workload on KubernetesUses Google Cloud A new engineer manager arrives and asks for the following: On every PR, run integration tests in a Kubernetes cluster similar to the production one. It sounds reasonable.

My demo of OpenTelemetry Tracing features two Spring Boot components. One uses the Java agent, and I noticed a different behavior when I recently upgraded it from v1.x to v2.x. In the other one, I’m using Micrometer Tracing because I compile to GraalVM native, and it can’t process Java agents. I want to compare these three different ways in this post: Java agent v1, Java agent v2, and Micrometer Tracing.

Most inter-systems communication components that use REST serialize their payload in JSON. As of now, JSON lacks a widely-used schema validation standard: JSON Schema is not widespread. Standard schema validation allows delegating the validation to a third-party library and being done with it. Without one, we must fall back to manual validation in the code. Worse, we must keep the validation code in sync with the schema.

One of the main reasons to design microservices is that they enforce strong module boundaries. However, the cons of microservices are so huge that it’s like chopping off your right hand to learn to write with the left one; there are more manageable (and less painful!) ways to achieve the same result. Even since the microservices craze started, some cooler heads have prevailed.

I frequently use the Spring Boot framework in my demos. The latest one is no different. It shows how to achieve CQRS using two different code paths: the command part is implemented via Spring Data JPAthe query part via jOOQ My use case is a banking application that offers a REST layer allowing clients to call any parts.

The Cloud has enabled a lot of new usages that were not possible before. Among them stands Serverless: Serverless computing is a cloud computing execution model in which the cloud provider allocates machine resources on demand, taking care of the servers on behalf of their customers. Serverless computing does not hold resources in volatile memory; computing is rather done in short bursts with the results persisted to storage.

Frameworks promise to speed up one’s development pace provided one follows the mainstream path. The path may be more or less narrow. I’m a big fan of the Spring ecosystem because its design is extensible and customizable at different abstraction levels: thus, the path is as large as you need it to be. Functional Programming is becoming more and more popular. Spring provides a couple of DSLs for the Kotlin language.

Gone are the times when developers' jobs ended with the release of the application. Nowadays, developers care more and more about the operational side of IT: perhaps they operate applications themselves, but more probably, their organization fosters increased collaboration between Dev and Ops. I started to become interested in the Ops side of software when I was still a consultant. When Spring Boot released the Actuator, I became excited.

When your application goes beyond a dozen of lines of code, you should probably split the code into multiple classes. At this point, the question is how to distribute them. In Java, the classical format is the Java ARchive, better known as the JAR. But real-world applications probably depend on other JARs. This post aims to describe ways to create self-contained executable JARs, also known as uber-JARs or fat JARs. What is an executable JAR? A JAR is just a collection of class files.

Last week, I wrote a post that described how to hack the Maven dependency resolution system. I admit it was a dirty hack, it’s even in the post name. But I got it wrong. Thanks Stéphane Nicoll for pointing it out: "It boils down to excluding the spring-boot-starter-logging in every Spring Boot starter"Since you've put every in bold, I assume you meant it. That's actually wrong and not what the documentation states.Here is an example: https://t.

Logging is one of the fundamental components of any application which runs in production. Yet, between performance and logging in critical environments, I’d favor the former. For that reason, modern logging frameworks should implement at least two requirements: Async appenders: the write operation shouldn’t be blocking the execution of the programLazy computation: the framework doesn’t run expensive computations until they are needed - or never if that’s the case.

Last week, I migrated a sample Spring application to Micronaut. This week, I did the same for Quarkus. Spring Boot and Micronaut both offer a parent POM. Quarkus favors using a BOM.

In the last couple of years, I’ve been playing a bit with a generation of tools in the Java world, namely Micronaut, Quarkus and GraalVM. While I’m a Spring Boot fan since its beginning, I believe this quite an eye-opening opportunity. In this post, I’d like to see how easy, or how hard, it is to port a simple Spring Boot application to Micronaut. Setting up the context The JVM is an great piece of technology.

Containerizing an application based on a 'scripting' language is straightforward. Add the sources, download the dependencies, and you’re good to go. One could say they are WYSIWYR. With compiled languages in general, and Java in particular, things are a bit different. In this post, I’d like to list some alternatives to achieve that.

If you’re developing with Spring Boot, IntelliJ IDEA does offer a lot of niceties to speed up development. Let’s browse through some of them.

Last week, I wrote on how to migrate an existing Spring Boot application with a functional approach toward configuration. Since then, I got interesting feedback, and I had a presentation on that subject at Rockstar Night in Kiev, which made me think further. Here’s how I would refine my previous code.

In the latest years, there has been some push-back against frameworks, and more specifically annotations: some call it magic, and claim it’s hard to understand the flow of the application. It’s IMHO part of a developer’s job to know about some main frameworks. But it’s hard to argue in favor of annotations when there are more annotations than actual code.

Distributing Java webapps via Docker is pretty widespread. However, regarding replacing desktop applications, it suffers from a not-so-great integration with the user’s desktop. On OSX, a quite popular distribution channel is Homebrew. Let’s dedicate this post to check how to distribute our desktop webapp via Homebrew.

Two weeks ago, we studied how to replace desktop Java apps with Java webapps. Now is the time to think about distributing such desktop webapps. The current trend now is to use Docker. I assume readers are at least familiar with the technology. The most straightforward way is to create a WAR and deliver it inside a Tomcat image. Another option is to create a fat JAR with Tomcat embedded as per the previous post, and run it inside a image with the JRE only.

Though I fancy myself a backend developer, I love the frontend. It’s always magic to visualize what you coded. Believe it or not, 15 years ago, I wrote JavaScript to dynamically add rows to an HTML table for Internet Explorer 5.5. That was called Dynamic HTML. But I was still a Java developer at heart.

Last week, I wrote about how one could migrate metrics from Spring Boot 1.5 to Spring Boot 2.0. This week, it’s time to check the different metrics available in Spring Boot 2.0 and how to create them. Meter There are 4 main types of metrics available: CounterGaugeTimerDistribution summary To keep the post readable in one piece, it will be limited to Counter and Gauge All metrics inherit from the base Meter class. A Meter provides basic measurement storage capabilities.

I’ve already written about the excellent monitoring features available in Spring Boot. In Spring Boot 2.0, there has been a major rewrite regarding how the /metrics endpoint is designed. This is the subject of this post.

Some years ago, I discovered the Spring Boot actuator: Spring Boot includes a number of additional features to help you monitor and manage your application when it’s pushed to production. You can choose to manage and monitor your application using HTTP endpoints, with JMX or even by remote shell (SSH or Telnet). Auditing, health and metrics gathering can be automatically applied to your application.

Spring Boot is a huge success, perhaps even more so than its inceptors hoped for. There is a lot of documentation, blog posts, and presentations on Spring Boot. However, most of them are aimed toward a feature, like monitoring or configuring. Few - if any of them, describe real-world practices. In this post, I’d like to highlight how to design a Spring Boot having multiple modules.

Last week, I tried to make a Spring Boot app - the famous Pet Clinic, Java 9 compatible. It was not easy. I had to let go of a lot of features along the way. And all in all, the only benefit I got was improvement of String memory management. This week, I want to continue the migration by fully embracing the Java 9 module system.

With the coming of Java 9, there is a lot of buzz on how to migrate applications to use the module system. Unfortunately, most of the articles written focus on simple Hello world applications. Or worse, regarding Spring applications, the sample app uses legacy practices - like XML for example. This post aims to correct that by providing a step-to-step migration guide for a non-trivial modern Spring Boot application. The sample app chosen to do that is the Spring Pet clinic.

Some time ago, RAM and disk space were scarce resources. At that time, the widespread strategy was to host different applications onto the same platform. That was the golden age of the application server. I wrote in an earlier post that the current tendency toward cheaper resources will make it obsolete, in the short or long term. However, a technology trend might bring it back in favor.

Since one year or so, I try to show the developer community that there’s no magic involved in Spring Boot but rather just straightforward software engineering. This is achieved with blog posts and conference talks. At jDays, Stéphane Nicoll was nice enough to attend my talk and pointed out an issue in the code. I didn’t fix it then, and it came back to bite me last week during a Pivotal webinar.

As I wrote some weeks earlier, I’m trying to implement features of the Spring Boot actuator in a non-Boot Spring MVC applications. Developing the endpoints themselves is quite straightforward. Much more challenging, however, is to be able to configure the mapping in a properties file, like in the actuator. This got me to check more closely at how it was done in the current code. This post sums up my 'reverse-engineering' attempt around the subject.

This is the 3rd post in the JVM Security focus series. Last week, I wrote about the JVM policy file that explicitly lists allowed sensitive API calls when running the JVM in sandboxed mode. This week, I’d like to improve the security by signing the JAR.

This is the 2nd post in the JVM Security focus series. I’ve already written about the JVM security manager, and why it should be used - despite it being rarely the case, if ever. However, just advocating for it won’t change the harsh reality unless some guidelines are provided to do so. This post has the ambition to be the basis of such guidelines. As a reminder, the JVM can run in two different modes, standard and sandboxed.

This week’s post aims to describe how to send JMX metrics taken from the JVM to an Elasticsearch instance. Business app requirements The business app(s) has some minor requirements. The easiest use-case is to start from a Spring Boot application. In order for metrics to be available, just add the Actuator dependency to it: <dependency> <groupId>org.springframework.

Most Spring developers know about the BeanPostProcessor and the BeanFactoryPostProcessor classes. The former enables changes to new bean instances before they can be used, while the latter lets you modify bean definitions - the metadata to create the bean.

Logging is for sure not a glamorous subject, but it’s a critical one - at least for DevOps and Ops teams. While there are plenty of material on the Web describing how to change your ASCII banner, there is not much on how to efficiently manage the log output. By default, Spring Boot will output log on the console and not use any file at all. However, it’s possible to tell Spring Boot to log in an output file. At the simplest level, the path where Spring Boot will put the spring.

In the last post, I tried to describe the internal working of Spring Boot starter. It’s now time to develop our own! As an example, we will use XStream, a no-fluff just-stuff XML/JSON (de)serializer offered by Thoughtworks. Readers who only use JAXB and Jackson are advised to have a look at XStream, it’s extremely efficient and its API is quite easy to use. As seen in our last post, the entry-point of a starter lies in the META-INF/spring.factories file.

Since its release, Spring Boot has been a huge success: it boosts developers productivity with its convention over configuration philosophy. However, sometimes, it just feels too magical. I have always been an opponent of autowiring for this exact same reason. And when something doesn’t work, it’s hard to get back on track. This is the reason why I wanted to dig deeper into Spring Boot starter mechanism - to understand every nook and cranny.

It’s no mystery that I’m a fan of both Spring Boot and Vaadin. When the Spring Boot Vaadin add-on became GA, I was ecstatic. Lately, I became interested in Kotlin, a JVM-based language offered by JetBrains. Thus, I wanted to check how I could develop a small Spring Boot Vaadin demo app in Kotlin - and learn something in the process. Here are my discoveries, in no particular order.

This is the 3rd post in the Going the microservices way focus series. In the first post of this serie, I created a simple microservice based on a Spring Boot + Data JPA stack to display a list of available products in JSON format. In the second part, I demoed how this app could be uploaded on Pivotal Cloud Foundry. In this post, I’ll demo the required changes to deploy on Heroku.

This is the 2nd post in the Going the microservices way focus series. In my previous post, I developed a simple microservices REST application based on Spring Boot in a few lines of code. Now is the time to put this application in the cloud. In the rest of the article, I suppose you already have an account configured for the provider. Pivotal Cloud Foundry is the Cloud offering from Pivotal, based on Cloud Foundry.

This is the 1st post in the Going the microservices way focus series. <div class='paragraph'> <p><a href='https://en.wikipedia.org/wiki/Microservices' target='_blank' rel='noopener'>Microservices</a>, are trending right now, whether you like it or not. There are good reasons for that as it resolves many issues organizations are faced with.

I think Spring Boot brings something new to the table, especially concerning DevOps - and I’ve already written a post about it. However, there’s more than metrics and healthchecks. In one of another of my previous post, I described how to provide versioning information for Maven-built applications. This article will describe how this later post is not necessary when using Spring Boot.