Techland

In the previous article, we discussed how to automatically launch a container that exposes an API connected to its own database using a Quarkus extension. Now, we will explore how to communicate with this API from our main application.

In the previous article, we saw how to automatically launch a database using a Quarkus extension. Now, we will see how to start our service in the same way and make it use the database we just deployed. I won’t go over the points covered in the previous article, so I encourage you to read it before continuing.

Today, we’re tackling a major topic with a use case that is not documented by Quarkus but is extremely useful. Quarkus offers extensions with “dev services.” Once included in your project, these extensions automatically launch services when the project starts in dev mode. We will see how to create our own “dev service” for Quarkus applications. The idea is to provide an extension for each of our services to make them easily usable by others.

Backstage is an excellent dashboard tool for developers. Its plugin system makes it particularly flexible. However, configuring these plugins can be tedious. Backstage is constantly evolving, which sometimes makes it difficult for the documentation to keep up. This has been the case since the migration to the new Backend system. Backstage provides several plugins for connecting to most identity providers via OIDC. However, if you want to connect Backstage to a custom provider, like an enterprise Keycloak, the documentation is not very clear. That’s what we will explore in this post.

In the previous post on the AdditionalBeanBuildItem, we discussed how to reference a bean with the ARC dependency manager. While useful, there are cases where you need the manager to inject a specific instance of a pre-configured bean. Since AdditionalBeanBuildItem only accepts a bean class as a parameter, it cannot be used for this purpose. This is where the SyntheticBeanBuildItem comes into play.

Use Case

Imagine your extension needs to provide a configuration as an injectable bean to communicate with a third-party API. You’ll need to instruct Quarkus on which bean instance to inject and with what values.

In the previous post about the AdditionalBeanBuildItem, we saw how to reference a bean in the ARC dependency manager. This is very convenient, but in some cases, we want the manager to inject a specific instance of an already configured bean. Since AdditionalBeanBuildItem only takes a bean class as a parameter, it can’t be used for this. This is where SyntheticBeanBuildItem comes in.

Use Case

Imagine your extension wants to provide a configuration as an injectable bean to communicate with a third-party API. You need to tell Quarkus which bean instance to inject and with what values.