Posts

The source code is available here As a developer, I understand the importance of having effective testing tools to improve the quality of software products. One such tool is Hoverfly, a popular open-source simulation tool used to create HTTP(S) services that mimic the behavior of real APIs. With Hoverfly, developers can test their code against mocked services that mimic the behavior of real APIs, enabling them to detect and fix issues before the code goes into production.

The data-access layer is often where performance problems emerge and what defines your application response time. Uncontrolled SQL queries can produce long-running transactions that affect the scalability of your software. Hibernate is a powerful tool, but it’s often criticized because it can sometimes have unpredictable behavior when it converts all your entities fetch/update to SQL statements (N+1 Select, Cartesian product…). How to track Hibernate SQL statements The easiest way to track the SQL statements is by enabling their logging, unfortunately, even if it’s useful in development, that cannot prevent regression of your data access queries in production, we need some testing to help us.

A cache is a good way of optimizing slow calls. The two common caches used in most Spring applications are Spring Cache and the JPA Cache. There are already a lot of very good articles on how to configure each one, but I want to emphasize on their differences. These caches are independent and configured differently, but they are both compatible with JCache (JSR-107) specification and can use the same cache implementation as EhCache.

An application can contain many cross-cutting concerns and Spring AOP is a good tool that allows you to add behaviors to a method without having to alter its implementation. Imagine a simple example where you’re developing an application that can provide blog posts to consumers, and they can filter the posts they want by their creation date. Note: The working example is accessible here The model: @Data @AllArgsConstructor @NoArgsConstructor public class BlogPost { private Instant creationDate; private String title; } The returned DTO:

When you want to speed up your integration tests, you often want to use ApplicationContext caching. It allows you to reuse your context across tests instead of destroying it at the end of each test, avoiding ~5 seconds of container initialization. You just have to clean your database between each test and Spring will caches all automatically, each Context containerized in its own space. But when you try to write Quartz tests after this change, some problems appear.

A quick guide to configuring many log4j2 configurations with different profiles (QA, Prod…). First, you need to add the log4j2 spring starter, and to exclude the logback starter (here the version is inherited from your Spring Boot BOM). <dependency> <artifactId>spring-boot-starter-web</artifactId> <exclusions> <!-- Exclude logback (default implementation) --> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-logging</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> You can put your log4j2-local.xml and the log4j2-prod.xml in the resource directory of your choice, in this example it will be src/main/resources/log/.

In my current project, we needed to identify each build with a version number. We decided to inject this number at compile-time, so it would be generated at each Jenkins Build with a unique build-number, allowing us to always be in a “production-ready” state. Setting up the POM You can set a default value in the properties, here I’ve added metadata information “-dev”, that is useful to distinguish different build profiles (local, Jenkins CI, etc…).