Search results
Configuring JSON-Formatted Logs in Spring Boot applications with Slf4j, Logback and Logstash
1. OVERVIEW
Logging is an important part of application development.
It helps you to troubleshoot issues, to follow execution flows, not only inside the application, but also when spawning multiple requests across different services.
Logging also helps you to capture data and replicate production bugs in a development environment.
Often times, searching logs efficiently is a daunting task. That’s why there are plenty of Log Aggregators such as Splunk, ELK, Datadog, AWS CloudWatch, and many more, that help with capturing, standardizing, and consolidating logs to assist with log indexing, analysis, and searching.
Standard-formatted log messages like:
2023-08-01 12:43:44.421 INFO 73710 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 8080 (http) with context path ''
are easy to read by Engineers but not so easy to parse by Log Aggregators, especially if the log format keeps changing.
This blog post helps you to configure Spring Boot applications to format log messages as JSON using Slf4j, Logback and Logstash, and having them ready to be fed to Log Aggregators.
Uploading JaCoCo Code Coverage Reports to SonarQube
1. OVERVIEW
SonarQube is a widely adopted tool that collects, analyses, aggregates and reports the source code quality of your applications.
It helps teams to measure the quality of the source code as your applications mature.
SonarQube integrates with popular CI/CD tools so that you can get source code quality reports every time a new application build is triggered; helping teams to fix errors, reduce technical debt, maintain a clean source base, etc.
A previous blog post covered how to generate code coverage reports using Maven and JaCoCo.
This blog post covers how to generate JaCoCo code coverage reports and upload them to SonarQube.
Writing dynamic SQL queries using Spring Data JPA repositories, Hibernate and Querydsl
1. OVERVIEW
Let’s say you need to implement a RESTful endpoint where some or all of the request parameters are optional.
An example of such endpoint looks like:
/api/films?minRentalRate=0.5&maxRentalRate=4.99&releaseYear=2006&category=Horror&category=Action
Let’s also assume you need to retrieve the data from a relational database.
Processing these requests will translate to dynamic SQL queries, helping you to avoid writing a specific repository method for each use case. This would be error-prone and doesn’t scale as the number of request parameters increases.
In addition to:
-
Writing dynamic SQL queries using Spring Data JPA Specification and Criteria
-
Writing dynamic SQL queries using Spring Data JPA repositories and EntityManager
you could also write dynamic queries using Spring Data JPA and Querydsl.
Querydsl is a framework that helps writing type-safe queries on top of JPA and other backend technologies, using a fluent API.
Spring Data JPA provides support for your repositories to use Querydsl via the QuerydslJpaPredicateExecutor fragment.
These are some of the methods this repository fragment provides:
findOne(Predicate predicate) |
findAll(Predicate predicate) |
findAll(Predicate predicate, Pageable pageable) |
and more.
You can combine multiple Querydsl Predicates, which generates dynamic WHERE
clause conditions.
But I didn’t find support to generate a dynamic number of JOIN
clauses. Adding unneeded JOIN
clauses to your SQL queries will impact the performance of your Spring Boot application or database.
This blog post covers how to extend Spring Data JPA for your repositories to access Querydsl objects so that you can write dynamic SQL queries.
Parsing CSV responses with a custom RestTemplate HttpMessageConverter
1. OVERVIEW
Even though RestTemplate has been deprecated in favor of WebClient, it’s still a very popular choice to integrate Java applications with in-house or third-party services.
If you find yourself working on application modernization you would most-likely need to integrate with legacy systems. Don’t be surprised if you get HTML, plain text, or CSV responses when integrating with legacy systems.
Of course you could use RestTemplate to get the response as a String and covert it to a Java object. But that’s not how you do it when retrieving JSON or XML responses.
You would only need:
ResponseEntity<Film> result = this.restTemplate.getForEntity(uri, Film.class);
and RestTemplate’s default HttpMessageConverters take care of the conversion.
This blog post helps you to write a custom RestTemplate HttpMessageConverter to convert CVS responses to Java objects.
Writing dynamic SQL queries using Spring Data JPA repositories and EntityManager
1. OVERVIEW
You would need to write dynamic SQL queries for instance, if you need to implement a RESTful endpoint like:
/api/films?category=Action&category=Comedy&category=Horror&minRentalRate=0.5&maxRentalRate=4.99&releaseYear=2006
where the request parameters category
, minRentalRate
, maxRentalRate
, and releaseYear
might be optional.
The resulting SQL query’s WHERE clause or even the number of table joins change based on the user input.
One option to write dynamic SQL queries in your Spring Data JPA repositories is to use Spring Data JPA Specification and Criteria API.
But Criteria queries are hard to read and write, specially complex queries. You might have tried to come up with the SQL query and reverse-engineer it to implement it using the Criteria API.
There are other options to write dynamic SQL or JPQL queries using Spring Data JPA.
This tutorial teaches you how to extend Spring Data JPA for your repositories to access the EntityManager so that you can write dynamic native SQL or JPQL queries.
Let’s start with a partial ER diagram for the db_dvdrental
relational database:
Fixing Hibernate HHH000104 firstResult maxResults warning using Spring Data JPA Specification and Criteria API
1. OVERVIEW
Whenever you use pagination and SQL joins to retrieve entities and their associations to prevent the N+1 select queries problem you’ll most-likely run into this Hibernate’s HHH000104
warning message.
HHH000104: firstResult/maxResults specified with collection fetch; applying in memory!
This warning is bad and will affect your application’s performance once your dataset grows. Let’s see why.
Let’s start with these tables relashionship:
It helps us to write or generate our domain model, and we would endup with these relevant JPA associated entities:
Padding IN predicates using Spring Data JPA Specification
1. OVERVIEW
I recently discussed how Spring Data JPA Specification and Criteria queries might impact Hibernate’s QueryPlanCache. A high number of entries in the QueryPlanCache, or a variable number of values in the IN
predicates can cause frequent GC cycles where it releases fewer objects over time, and possibly throws OutOfMemoryError exceptions.
While padding the IN predicate parameters to optimize Hibernate’s QueryPlanCache we found setting in_clause_parameter_padding
to true didn’t work when using Spring Data JPA Specification.
This blog post helps you to pad IN
predicates when writing Spring Data JPA Specification and Criteria queries.
Troubleshooting Spring Data JPA Specification and Criteria queries impact on Hibernate's QueryPlanCache
1. OVERVIEW
Now that you know how to write dynamic SQL queries using Spring Data JPA Specification and the Criteria API, let’s evaluate the impact they might have in the performance of your Spring Boot applications.
As a Java developer, you have the responsibility to understand what SQL statements Hibernate generates and executes. It helps you to prevent the N+1 SELECT query problem, for instance.
Another common problem Hibernate developers experience is performance and memory problems as a result of writing queries with a variable number of values in the IN
predicates.
This blog post helps you to identify heap and garbage collection problems you might experience when using Spring Data JPA Specification with Criteria queries.
Documenting your relational database using SchemaSpy
1. OVERVIEW
You joined a new organization, maybe asked to troubleshoot if a Java application has the N+1 select problem or to write new SQL queries.
You started looking at a couple dozen JPA entities and decided to take a look at the RDBMS Entity Relationship diagram. You asked your peers and there is none.
This blog post helps you to document your relational database using SchemaSpy in different ways. Via command line, using a Maven plugin, or using Docker so that you don’t have to install SchemaSpy required software.
Writing dynamic SQL queries using Spring Data JPA Specification and Criteria API
1. OVERVIEW
A dynamic SQL query refers to building a query on the fly before executing it. Not just replacing query parameters by their name or position, but also including a variable number of columns in the WHERE clause, and even joining tables based on specific conditions.
How would you implement a RESTful endpoint like /api/films?minRentalRate=0.5&maxRentalRate=4.99
where you need to retrieve films from a relational database?
You could take advantage of Spring Data JPA support for:
Declared Queries
using @Query-annotated methods.- Plain JPA
Named Queries
using:orm.xml
’s <named-query /> and <named-native-query />.- @NamedQuery and @NamedNativeQuery annotations.
Derived Queries
from method names. For instance, naming a method findByRentalRateBetween() in your Film repository interface.
Let’s say later on you also need to search films based on movie categories, for instance, comedy, action, horror, etc.
You might think a couple of new repository methods would do the work. One for the new category filter and another to combine both, the rental rate range filter with the category filter. You would also need to find out which repository method to call based on the presence of the request parameters.
You soon realize this approach is error-prone and it doesn’t scale as the number of request parameters to search films increases.
This blog post covers generating dynamic SQL queries using Spring Data JPA Specification and Criteria API including joining tables to filter and search data.