Techland

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.

After discussing the ApplicationIndexBuildItem and CombinedIndexBuildItem, let’s continue exploring Quarkus build items with the AdditionalBeanBuildItem. This build item is part of the configuration items for the Arc library , which handles dependency injection in Quarkus.

Quarkus and Dependency Injection

Quarkus heavily relies on dependency injection, allowing for loose coupling between different objects in a Quarkus application. Quarkus uses a library called Arc that automatically scans the application’s classpath and references all classes declared as beans (e.g., those annotated with @Controller, @Service, etc.) for injection.

Quarkus has a very powerful extension system based on the concept of BuildItem. Each BuildItem allows you to configure an extension in a specific way. However, the documentation for these BuildItems is very incomplete. Among the hundreds of BuildItems that exist, I propose to study two of them in this post. Let’s focus on ApplicationIndexBuildItem and CombinedIndexBuildItem.

A Story of Jandex

Quarkus needs to gather information about the application at build time. Jandex allows analyzing and storing metadata of the application’s classes in a jandex.idx file. This file is then used by Quarkus to retrieve information about the classes. This is a significant improvement over using runtime introspection.