Erkundung synthetischer Bohnen in Quarkus. Ein leistungsstarker Erweiterungsmechanismus

In der Welt von Quarkus ist der Bereich der Abhängigkeitsinjektion umfangreich und vielseitig und bietet Entwicklern eine Vielzahl von Tools zur Verwaltung und Kontrolle von Beans. Ein solches Werkzeug ist das Konzept der synthetischen Bohnen. Synthetische Beans sind ein leistungsstarker Erweiterungsmechanismus, mit dem Sie Beans registrieren können, deren Attribute nicht von einer Java-Klasse, -Methode oder einem Java-Feld abgeleitet sind. Stattdessen werden alle Attribute einer synthetischen Bean durch eine Erweiterung definiert.

In diesem Artikel tauchen wir tief in die Welt der synthetischen Bohnen in Quarkus ein. Wir untersuchen den Bedarf an synthetischen Bohnen, ihre praktischen Anwendungen und wie Sie sie erstellen und in Ihren Quarkus-Anwendungen verwenden.

Synthetische Bohnen verstehen

In Quarkus sind Beans die Bausteine Ihrer Anwendung, die vom Contexts and Dependency Injection (CDI)-Framework verwaltet werden. Typischerweise sind CDI-Beans Java-Klassen, die mit verschiedenen CDI-Annotationen wie @ApplicationScoped, @RequestScoped oder @Inject annotiert sind. Diese Anmerkungen
Ermöglichen Sie CDI, den Lebenszyklus und die Injektion von Bohnen automatisch zu verwalten.

Es gibt jedoch Situationen, in denen Sie möglicherweise eine Bean registrieren müssen, die nicht genau in das traditionelle CDI-Modell passt. Hier kommen synthetische Bohnen ins Spiel. Synthetische Beans werden durch Erweiterungen erstellt und ihre Attribute werden vollständig durch diese Erweiterungen definiert. In der Welt des regulären CDI würden Sie dies mit den Methoden AfterBeanDiscovery.addBean() und SyntheticComponents.addBean() erreichen. In Quarkus wird dies mit SyntheticBeanBuildItem.

Wann brauchen Sie synthetische Bohnen?

Wann müssen Sie also möglicherweise synthetische Bohnen in Quarkus verwenden? Synthetische Bohnen sind ein wirkungsvolles Hilfsmittel, wenn:

1. Integration von Drittanbieter-Bibliotheken:Sie arbeiten mit einer Drittanbieter-Bibliothek, die keine CDI-Anmerkungen hat, aber in Ihre CDI-basierte Anwendung integriert werden muss. Mit synthetischen Bohnen können Sie diese Lücke schließen.

2. Dynamische Bean-Registrierung:Sie müssen Beans zur Laufzeit dynamisch registrieren, abhängig von der Konfiguration oder anderen Faktoren. Synthetische Bohnen geben Ihnen die Flexibilität, Bohnen im laufenden Betrieb zu erstellen und zu registrieren.

3. Maßgeschneiderte Bean-Verwaltung:Sie benötigen eine differenzierte Kontrolle über den Umfang und das Verhalten einer Bean, die mit Standard-CDI-Annotationen nicht erreicht werden kann.

4. Spezialisierte Beans implementieren:Sie möchten spezialisierte Beans mit eindeutigen Attributen erstellen, die nicht den herkömmlichen Java-Klassen oder -Methoden entsprechen.

5. Verspotten von Abhängigkeiten zum Testen:Synthetische Beans bieten eine nützliche Möglichkeit, Abhängigkeiten zu verspotten und Scheinimplementierungen zu Testzwecken einzufügen.

SynthesisFinishedBuildItem

Das SynthesisFinishedBuildItem wird verwendet, um anzuzeigen, dass der CDI-Bean-Erkennungs- und Registrierungsprozess abgeschlossen ist. Dadurch können Erweiterungen erkennen, wann die Interaktion mit den registrierten Beans sicher ist.

Zum Beispiel:

@BuildStep void onSynthesisFinished(SynthesisFinishedBuildItem synthesisFinished){ // CDI bean registration is complete, can now safely interact with beans }

SyntheticBeansRuntimeInitBuildItem

Das SyntheticBeansRuntimeInitBuildItem wird verwendet, um einen Rückruf zu registrieren, der zur Laufzeit aufgerufen wird, nachdem alle synthetischen Beans initialisiert wurden. Dies ist nützlich, wenn Sie eine zusätzliche Initialisierungslogik mit synthetischen Beans durchführen müssen.

Zum Beispiel:

@BuildStep SyntheticBeansRuntimeInitBuildItem initSyntheticBeans(){ return new SyntheticBeansRuntimeInitBuildItem(ids->{ // Perform logic with initialized synthetic beans }); }

Der an SyntheticBeansRuntimeInitBuildItem übergebene Rückruf erhält ein Set Enthält die IDs aller initialisierten synthetischen Beans.

Zusammenfassend zeigt SynthesisFinishedBuildItem an, dass die Bean-Erkennung abgeschlossen ist, während SyntheticBeansRuntimeInitBuildItem die Initialisierung der Logik abhängig von synthetischen Beans ermöglicht.

Erstellen synthetischer Beans mit SyntheticBeanBuildItem

In Quarkus ist die Erstellung synthetischer Bohnen dank der Klasse SyntheticBeanBuildItem ein unkomplizierter Prozess. Gehen wir die Schritte zum Erstellen und Verwenden einer synthetischen Bohne durch:

1. Erstellen Sie die synthetische Bohnenklasse:Beginnen Sie mit der Definition der synthetischen Bohnenklasse. Dieser Kurs bildet die Grundlage für Ihre synthetische Bohne.

package com.iqnev; public class MySyntheticBean { // Define the behavior and attributes of your synthetic bean public void printMessage() { System.out.println("Hello from synthetic bean!"); } }

1. Erstellen Sie eine Quarkus-Erweiterung:Sie müssen eine Quarkus-Erweiterung erstellen, um Ihre synthetische Bean zu registrieren. Diese Erweiterungsklasse verwendet SyntheticBeanBuildItem, um Ihr Bean zu konfigurieren.

Ansatz zur Bytecode-Generierung

package com.iqnev; import io.quarkus.arc.deployment.SyntheticBeanBuildItem; public class MySyntheticBeanExtension { @BuildStep SyntheticBeanBuildItem syntheticBean() { return SyntheticBeanBuildItem .configure(MySyntheticBean.class) .scope(ApplicationScoped.class) .creator(mc -> { mc.returnValue(new MySyntheticBean()); }) .done(); } }

Die .creator()-Methode auf SyntheticBeanBuildItem wird verwendet, um den Bytecode zu generieren, der zur Laufzeit Instanzen der synthetischen Bean erstellt.

Das an .creator() übergebene Argument ist ein Consumer Dies ermöglicht die Generierung von Java-Bytecode innerhalb einer Methode.

In diesem Beispiel:

1. mc is the MethodCreator instance
2. mc.returnValue(new MySyntheticBean()) generates the bytecode to create a new instance of MySyntheticBean and return it from the method.

So essentially, we are telling Quarkus to generate a method that looks something like:

MySyntheticBean createSyntheticBean(){ return new MySyntheticBean(); }

This generated method will then be called to instantiate the MySyntheticBean when it needs to be injected or used.

The reason bytecode generation is used is that synthetic beans do not correspond to real Java classes/methods, so we have to explicitly generate a method to instantiate them

The output of SyntheticBeanBuildItem is bytecode recorded at build time. This limits how instances are created at runtime. Common options are:

1. Generate bytecode directly via .creator()
2. Use a BeanCreator subclass
3. Produce instance via @Recorder method

Recorder Approach

The @Record and .runtimeValue() approaches are alternate ways of providing instances for synthetic beans in Quarkus.

This allows you to instantiate the synthetic bean via a recorder class method annotated with @Record(STATIC_INIT).

For example:

@Recorder public class MyRecorder { @Record(STATIC_INIT) public MySyntheticBean createBean() { return new MySyntheticBean(); } } @BuildStep SyntheticBeanBuildItem syntheticBean(MyRecorder recorder) { return SyntheticBeanBuildItem .configure(MySyntheticBean.class) .runtimeValue(recorder.createBean()); }

Here the .runtimeValue() references the recorder method to instantiate the bean. This allows passing a RuntimeValue directly to provide the synthetic bean instance.

For example:

@BuildStep SyntheticBeanBuildItem syntheticBean(){ RuntimeValue bean= //... return SyntheticBeanBuildItem .configure(MySyntheticBean.class) .runtimeValue(bean); }

The RuntimeValue could come from a recorder, supplier, proxy etc.

So in summary:

• @Record is one approach to generate the RuntimeValue
• .runtimeValue() sets the RuntimeValue on the SyntheticBeanBuildItem

They both achieve the same goal of providing a runtime instance, just in slightly different ways.

When it comes to providing runtime instances for synthetic beans in Quarkus, I would consider using recorders (via @Record) to be a more advanced approach compared to directly generating bytecode
with .creator() or supplying simple RuntimeValues.

Here are some reasons why using recorders can be more advanced:

• More encapsulation -The logic to instantiate beans is contained in a separate recorder class rather than directly in build steps. This keeps build steps lean.
• Reuse -Recorder methods can be reused across multiple synthetic beans rather than rewriting creator logic.
• Runtime data -Recorder methods execute at runtime so they can leverage runtime resources, configs, services etc. to construct beans.
• Dependency injection -Recorder methods can inject other services.
• Life cycle control -Recorder methods annotated with @Record(STATIC_INIT) or @Record(RUNTIME_INIT) give more control over bean instantiation life cycle.
• Managed beans -Beans instantiated inside recorders can themselves be CDI managed beans.

So in summary, recorder methods provide more encapsulation, flexibility and access to runtime data and services for instantiating synthetic beans. They allow for more advanced bean production logic compared to direct bytecode generation.

However, direct bytecode generation with .creator() can still be useful for simple cases where recorders may be overkill. But as synthetic bean needs grow, recorders are a more powerful and
advanced approach.

It is possible to configure a synthetic bean in Quarkus to be initialized during the RUNTIME_INIT phase instead of the default STATIC_INIT phase.

Here is an example:

@BuildStep @Record(RUNTIME_INIT) SyntheticBeanBuildItem lazyBean(BeanRecorder recorder){ return SyntheticBeanBuildItem .configure(MyLazyBean.class) .setRuntimeInit() // initialize during RUNTIME_INIT .runtimeValue(recorder.createLazyBean()); }

The key points are:

• Use setRuntimeInit() on the SyntheticBeanBuildItem to mark it for RUNTIME_INIT
• The recorder method must be annotated with @Record(RUNTIME_INIT)
• The runtime init synthetic beans cannot be accessed during STATIC_INIT

So in summary, synthetic beans can be initialized lazily during RUNTIME_INIT for cases where eager STATIC_INIT instantiation is not needed. This allows optimizing startup time.

Use the Synthetic Bean:Now that your synthetic bean is registered, you can inject and use it in your application.

package com.iqnev; import javax.inject.Inject; public class MyBeanUser { @Inject MySyntheticBean mySyntheticBean; public void useSyntheticBean() { // Use the synthetic bean in your code mySyntheticBean.printMessage(); } }

Running Your Application:Build and run your Quarkus application as usual, and the synthetic bean will be available for injection and use.

Conclusion

Synthetic beans in Quarkus provide a powerful mechanism for integrating external libraries, dynamically registering beans, and customizing bean behavior in your CDI-based applications. These beans, whose attributes are defined by extensions rather than Java classes, offer flexibility and versatility in managing dependencies.

Wie wir in diesem Artikel untersucht haben, ist die Herstellung und Verwendung synthetischer Bohnen in Quarkus ein unkomplizierter Prozess. Durch die Nutzung der Erweiterungen SyntheticBeanBuildItem und Quarkus können Sie die Lücke zwischen traditionellem CDI und spezielleren oder dynamischeren Bean-Registrierungsanforderungen nahtlos schließen.

In der sich ständig weiterentwickelnden Landschaft der Java-Frameworks sticht Quarkus weiterhin hervor, indem es innovative Lösungen wie synthetische Beans anbietet, was es zu einer überzeugenden Wahl für die moderne, effiziente und flexible Anwendungsentwicklung macht. Nutzen Sie die Kraft synthetischer Bohnen in Quarkus und bringen Sie Ihre Abhängigkeitsinjektion auf die nächste Stufe!

Das obige ist der detaillierte Inhalt vonErkundung synthetischer Bohnen in Quarkus. Ein leistungsstarker Erweiterungsmechanismus. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!