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. XML has schema validation out-of-the-box: an XML document can declare a gr
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. In particular, Oliver Drotbohm, a developer on the Spring framework, has been a long-time proponent of the moduli
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. For example, the Beans DSL and the Routes DSL allow for a more funct
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. Via its convention-other-configuration nature, it was po
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. To be
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: +<div class='jekyll-twitter-plugin'><blockquote class='twitter-tweet'><p lang='en' dir='ltr'>"It boils down to excluding the spring-boot-starter-logging in every Spring Boot starter"<br><br>Since you've put every in bold, I assume yo
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. The fi
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. Modern versions compile the running bytecode to native code, depe
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.
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. One of the deciding factors is the si
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. As
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. To sum it up, the actuator offers endpoints that allow monitoring of the application from
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. Having an application server is good when infrastructure resources are expensive, and sharing them across ap
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. Since a lesson learned is only as useful as its audience, I’d like to share my mista
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. Standard MVC Usage In Spring MVC, in
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. In the former, all API are available with no restriction; i
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.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency&