I’m maintaining an application, which is using the Keycloak Spring Security adapter. Now that Keycloak deprecated their adapter, without providing a migration guide, I had to find a solution.

I had the opportunity to visit DrivUn and AxonIQ Conference, both organised by AxonIQ.

It were 2 intensive days full of collaboration with people inspired by Domain Driven Design and Event Driven systems. Please, read on for my key takeaways.

Unfortunately Oracle databases aren’t compatible with the new Apple Silicon CPU architecture. Due to this fact you’re not able to run an Oracle XE image with TestContainers on your brand-new MacBook, but there’s a workaround!

TLDR;

Unfortunately Oracle databases aren’t compatible with the new Apple Silicon CPU architecture. Due to this fact you’re not able to run an Oracle XE database on your brand-new MacBook, but there’s a workaround!

TLDR;

Amazon Web Services offers a way to connect to a MySQL or PostgreSQL database without having a password, instead an authentication token can be used.
Within AWS this type of authentication is called RDS IAM.
Users don’t need to store an username and password and credentials don’t need to be stored in the database, which makes this a secure authentication method.

So, this makes it interesting to use this in your Spring Boot application. Spring Boot will use a HikariCP connection pool by default, but HikariCP 4.0.3 doesn’t support the use of authentication tokens.

So, how do I make this work within my Spring Boot application?

Building Event Driven systems is great, but not all systems are Event Driven. Communication with those systems can be via HTTP and those systems may not be able to respond quickly to a request, taking up to minutes to serve a response.

Are there tools to mock such a situation to be used for testing?

When using Springfox you can annotate your endpoints to automatically generate OpenAPI docs for your clients.
This blogpost will show how you can prevent Springfox generating a model on an endpoint with ResponseEntity as return type.
I’ll also cover how to prevent generating default responses.

There are those moments you wish you could just start up a real database or system for your (integration) test. In many tests I’ve written I used H2 or HSQLDB to have a data storage for my tests. It starts up quickly and almost supports everything you need to do your repository test or any other test needing data storage. But when your project progresses you start using other ways to store your data other than standard SQL or you use dialect specifics to create your database. This is the moment you discover H2 or HSQLDB is not supporting your database vendor specific features and you can’t get your test running. For example the support for PostgreSQL in H2 or HSQLDB isn’t great, using TIMESTAMP in a SQL script already makes H2 or HSQLDB break. Yes, there are workarounds, but you rather not apply them to keep your code clean and simple. This is the moment you wish it is cheap to start up a real database instance you can test against, so you’re sure your code works in your production environment. You could install the database software locally, make some scripts to initialise the database and clean up afterwards. Or you can make scripts to do this in a Docker container. But what if there’s something which makes this even cheaper to setup?

Making IntelliJ understand your QueryDSL generated classes needs some work. QueryDSL has an annotation processor to generate Q-classes from your entities. Just running the annotation processor doesn’t mean your IDE will understand where to find the generated classes. I was struggling to get IntelliJ IDEA picking up the generated classes. Probably there are more ways to get this done in Gradle, but I found out one that’s pretty easy to configure, without any adjustments to you IntelliJ settings. Because you could configure the annotation processor via the IntelliJ settings in the Annotation Processor screen (Build, Execution, Deployment → Compiler → Annotation Processors). It would be easier if you can achieve the same just using Gradle. With the following in your Gradle build file, it generates the classes and instructs IntelliJ where to find the classes:

If you’re using Lombok in your entities, generating the QueryDSL classes will fail, as it won’t understand the Lombok annotations. To solve this you have to add the Lombok dependency to the annotationProcessor block.

Maven can be set up to use a private repository, i.e. Nexus. Usually the repository runs on http and there isn’t any problem to connect to the repository, but when the repository runs on https maven isn’t able to connect to it automatically. The solution to this is to add the server’s certificate to the default Java keystore. When connecting to your https-repository fails, Maven will show you an exception like

To resolve this, download the server’s certificate and add it to the default Java keystore. The easiest way to download the certificate is with the Java provided keytool. The following command is an example to download the certificate to a .pem file