CDI für Rich Clients

Um eine Implementierung eines Extension Points diesem nun zuordnen zu können, musste man jetzt nicht mehr direkt die Klasse in plugin.xml eintragen, sondern sie nur noch mit @EclipseExtension unter Angabe der entsprechenden ID annotieren. Listing 3 zeigt dies anhand der Klasse ArtistEditor aus Listing 1.

Listing 3
@EclipseExtension(ArtistEditor.ID)
public class ArtistEditor extends EditorPart {

    public static final String ID = "at.ticketline.editor.artist";

    // Implementierung von ArtistEditor. 
}

Außerdem muss der Eintrag in plugin.xml leicht abgeändert werden, damit unsere CdiExtensionFactory für das Instanziieren des Extension Points zuständig ist. Listing 4 zeigt den abgeänderten Eintrag von Listing 1.

Listing 4

Wie zu sehen ist, muss nur das class-Attribut von at.ticketline.kassa.ui.editor.ArtistEditor in org.apacheextras.openwebbeans.eclipse.CdiExtensionFactory geändert werden. Der Rest kann gleich bleiben. Dadurch wird die Klasse ArtistEditor nun von OpenWebBeans erstellt, und wir können Dependency Injection innerhalb dieser Klasse nutzen. Diese Änderungen führten wir nun bei allen Extension Points des Projekts durch. Dabei stellte sich allerdings heraus, dass bei Command Handlern kein ID-Attribut vorhanden ist. Hier verwendeten wir stattdessen das Attribut commandId.

Ein Wort zu Scopes

Ein Scope definiert die Lebensdauer einer von CDI erstellten Instanz. Dazu werden in einer Webumgebung die dafür typischen Scopes (Session, Request etc.) zur Verfügung gestellt. Ferner werden, unabhängig von der Umgebung, die Pseudo-Scopes Dependent und Singleton sowie der Application-Scope angeboten. Dependent bedeutet, dass bei jeder Instanzanforderung an den CDI-Container (in unserem Fall OpenWebBeans) eine neue Instanz erstellt wird. Singleton bedeutet, dass nur eine einzige Instanz erstellt und bei mehrfachem Anfordern einer Instanz immer die gleiche zurückgeliefert wird. Selbiges gilt für den Application Scope; dieser ist aber kein Pseudo-Scope und kann somit über einen Proxy angesprochen werden. Das bedeutet, dass man bei Instanzanforderung nicht die wirkliche Klasseninstanz bekommt, sondern einen Proxy, der die Aufrufe zur richtigen Instanz delegiert. Das hat unter anderem den Vorteil, dass Interceptoren (die wir später noch brauchen werden) verwendet werden können. Wenn nichts anderes angegeben ist, wird der Dependent Scope verwendet. Aufgrund der Extension-Point-Architektur von Eclipse RCP müssen die Extension-Point-Implementierungen im Dependent Scope liegen, was bei Annotation mit @EclipseExtension auch von unserer Extension Factory überprüft wird. Für alle anderen von CDI verwalteten Klassen in unserem Projekt haben wir den Application Scope verwendet.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.