uebung5
This commit is contained in:
@@ -0,0 +1,204 @@
|
||||
\documentclass{uebung}
|
||||
|
||||
\author{Linus Nagel}
|
||||
\chapter{5}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\maketitle
|
||||
|
||||
\begin{exercises}
|
||||
|
||||
\item \textbf{Worum handelt es sich bei Dependency Injection?}
|
||||
|
||||
Dependency Injection (DI) ist ein Entwurfsmuster, bei dem der Container (z.B. der CDI-Container) die Abhängigkeiten eines Objekts automatisch bereitstellt, anstatt dass das Objekt sie selbst erzeugt oder sucht.
|
||||
Dadurch wird eine lose Kopplung erreicht, der Code wird besser testbar und die Verantwortung für die Erstellung der Abhängigkeiten wird aus der Klasse ausgelagert.
|
||||
In CDI wird dies hauptsächlich über die Annotation \texttt{@Inject} realisiert.
|
||||
|
||||
\item \textbf{Beschreiben Sie den Lebenszyklus von CDI-Beans.}
|
||||
|
||||
Der Container verwaltet den gesamten Lebenszyklus einer CDI-Bean:
|
||||
\begin{enumerate}
|
||||
\item \textbf{Instanziierung} – Aufruf des parameterlosen Konstruktors.
|
||||
\item \textbf{Dependency Injection} – Alle mit \texttt{@Inject} annotierten Felder/Setter werden gesetzt.
|
||||
\item \textbf{PostConstruct} – Eine mit \texttt{@PostConstruct} annotierte Methode wird ausgeführt (Initialisierung).
|
||||
\item \textbf{Nutzung} – Die Bean steht für Geschäftslogik zur Verfügung.
|
||||
\item \textbf{PreDestroy} – Vor dem Entfernen der Bean wird eine mit \texttt{@PreDestroy} annotierte Methode aufgerufen.
|
||||
\item \textbf{Zerstörung} – Die Bean wird aus dem Speicher entfernt (Scope-abhängig).
|
||||
\end{enumerate}
|
||||
|
||||
\item \textbf{Worum handelt es sich beim Bean Discovery? Welche Voraussetzung gibt es für das Bean Discovery?}
|
||||
|
||||
Bean Discovery ist der Prozess, bei dem der CDI-Container während des Deployments nach CDI-Beans sucht (z.B. in JARs oder Klassenordnern).
|
||||
Voraussetzung ist das Vorhandensein der Datei \texttt{beans.xml} im Ordner \texttt{META-INF} (für JARs) oder \texttt{WEB-INF} (für WARs).
|
||||
Seit CDI 1.1 kann der Modus \texttt{bean-discovery-mode="annotated"} verwendet werden; dann werden nur Klassen mit einer \textit{bean defining annotation} (z.B. \texttt{@RequestScoped}) entdeckt.
|
||||
|
||||
\item \textbf{Welche Regeln gelten für CDI-Beans?}
|
||||
|
||||
Eine CDI-Bean muss folgende Regeln erfüllen:
|
||||
\begin{itemize}
|
||||
\item Sie ist eine konkrete Klasse (oder mit \texttt{@Decorator} annotiert).
|
||||
\item Sie besitzt einen parameterlosen Konstruktor (Default-Konstruktor).
|
||||
\item Sie kann mit Scopes annotiert sein (z.B. \texttt{@RequestScoped}).
|
||||
\item Sie befindet sich in einem Archiv, das vom Bean Discovery erfasst wird.
|
||||
\end{itemize}
|
||||
|
||||
\item \textbf{Worum handelt es sich bei Qualifizierern?}
|
||||
|
||||
Qualifizierer sind benutzerdefinierte Annotationen, die es dem CDI-Container ermöglichen, zwischen mehreren Implementierungen desselben Schnittstellentyps zu unterscheiden.
|
||||
Sie werden an der Implementierungsklasse und am Injection Point verwendet und sorgen für typsichere Auswahl (im Gegensatz zu String-basierten Lösungen).
|
||||
|
||||
\item \textbf{Wie wird ein Qualifizierer erstellt? Wie wird er im Quellcode verwendet?}
|
||||
|
||||
Erstellung einer Qualifier-Annotation:
|
||||
\begin{minted}[breaklines]{java}
|
||||
@Qualifier
|
||||
@Retention(RetentionPolicy.RUNTIME)
|
||||
@Target({ElementType.TYPE, ElementType.FIELD, ElementType.METHOD})
|
||||
public @interface Lotto6aus49 {}
|
||||
\end{minted}
|
||||
Verwendung:
|
||||
\begin{itemize}
|
||||
\item Implementierungsklasse: \texttt{@Lotto6aus49 public class Generator6aus49 implements LottoGenerator \{ ... \}}
|
||||
\item Injection Point: \texttt{@Inject @Lotto6aus49 private LottoGenerator generator;}
|
||||
\end{itemize}
|
||||
|
||||
\item \textbf{Wie kann ein Qualifizierer mit Attributen versehen werden?}
|
||||
|
||||
Man definiert Methoden in der Annotation, die die Attribute zurückgeben. Als Typen sind nur primitive Typen, Strings, Enums, Class und deren Arrays erlaubt.
|
||||
Beispiel:
|
||||
\begin{minted}[breaklines]{java}
|
||||
@Qualifier
|
||||
@Retention(RetentionPolicy.RUNTIME)
|
||||
@Target({ElementType.TYPE, ElementType.FIELD})
|
||||
public @interface LottoNausM {
|
||||
Auswahl auswahl();
|
||||
Gesamt gesamt();
|
||||
}
|
||||
\end{minted}
|
||||
Verwendung: \texttt{@LottoNausM(auswahl=Auswahl.SECHS, gesamt=Gesamt.NEUNUNDVIERZIG)}.
|
||||
|
||||
\item \textbf{Worum handelt es sich bei einer Alternative?}
|
||||
|
||||
Eine Alternative ist eine Implementierung eines Interfaces, die mit \texttt{@Alternative} annotiert wird.
|
||||
Sie kann in der \texttt{beans.xml} aktiviert werden, um die Standardimplementierung zu überschreiben (z.B. für Mock-Objekte in Tests). Ohne Aktivierung in \texttt{beans.xml} wird sie ignoriert.
|
||||
|
||||
\item \textbf{Welchen Zweck erfüllen Producer?}
|
||||
|
||||
Producer (Methoden oder Felder mit \texttt{@Produces}) erzeugen Objekte, die keine CDI-Beans sind (z.B. \texttt{String}, \texttt{Date}, externe Bibliotheken) oder deren Erzeugung eine besondere Logik erfordert. Sie machen solche Objekte injizierbar.
|
||||
|
||||
\item \textbf{Wie werden Producer erstellt und verwendet?}
|
||||
|
||||
Eine Methode oder ein Feld wird mit \texttt{@Produces} annotiert. Meist gibt man zusätzlich einen Qualifizierer an.
|
||||
Beispiel – Producer-Methode:
|
||||
\begin{minted}[breaklines]{java}
|
||||
@Produces @Datum
|
||||
public Date aktuellesDatum() {
|
||||
return new Date();
|
||||
}
|
||||
\end{minted}
|
||||
Verwendung – Injection:
|
||||
\begin{minted}[breaklines]{java}
|
||||
@Inject @Datum private Date datum;
|
||||
\end{minted}
|
||||
|
||||
\item \textbf{Welche Aufgabe übernimmt ein Disposer? Wie wird ein Disposer erstellt?}
|
||||
|
||||
Ein Disposer schließt oder räumt Ressourcen auf, die von einem Producer erzeugt wurden (z.B. Datenbankverbindungen).
|
||||
Erstellt wird er durch eine Methode in derselben Klasse wie der Producer, die den zu zerstörenden Wert als Parameter mit der Annotation \texttt{@Disposes} erhält.
|
||||
\begin{minted}[breaklines]{java}
|
||||
public void schliesse(@Disposes Date datum) {
|
||||
// Ressourcen freigeben
|
||||
}
|
||||
\end{minted}
|
||||
|
||||
\item \textbf{Welche Scopes umfasst CDI?}
|
||||
|
||||
CDI definiert fünf Scopes:
|
||||
\begin{itemize}
|
||||
\item \texttt{@ApplicationScoped} – eine Instanz pro Anwendung.
|
||||
\item \texttt{@SessionScoped} – eine Instanz pro HTTP-Session.
|
||||
\item \texttt{@RequestScoped} – eine Instanz pro HTTP-Request.
|
||||
\item \texttt{@ConversationScoped} – vom Entwickler steuerbarer, längerlebiger Scope.
|
||||
\item \texttt{@Dependent} (Pseudo-Scope) – Lebenszyklus abhängig von der injizierenden Bean.
|
||||
\end{itemize}
|
||||
|
||||
\item \textbf{Welche Lebensdauer deckt der Conversation Scope ab? Wie kann eine Conversation gestartet und beendet werden?}
|
||||
|
||||
Der Conversation Scope bleibt über mehrere Requests erhalten, bis er explizit beendet wird.
|
||||
Eine mit \texttt{@ConversationScoped} annotierte Bean kann eine \texttt{Conversation} injizieren:
|
||||
\begin{minted}[breaklines]{java}
|
||||
@Inject private Conversation conversation;
|
||||
\end{minted}
|
||||
Start: \texttt{conversation.begin();} (danach ist die Conversation \textit{long running})
|
||||
Ende: \texttt{conversation.end();} (danach ist sie wieder \textit{transient}).
|
||||
|
||||
\item \textbf{Welchen Zweck erfüllt die Annotation @Named?}
|
||||
|
||||
\texttt{@Named} vergibt einen Namen für eine CDI-Bean, damit sie in Expression Languages (z.B. JSF) angesprochen werden kann.
|
||||
Standardname ist der einfache Klassenname mit kleinem Anfangsbuchstaben.
|
||||
Beispiel: \texttt{@Named("meinService")} erlaubt den Zugriff über \texttt{\#\{meinService.methode()\}}.
|
||||
|
||||
\item \textbf{Welchen Sinn haben Interceptoren? Wie ist der Ablauf eines Interceptoraufrufs?}
|
||||
|
||||
Interceptoren führen Querschnittsaufgaben (Logging, Security, Transaktionen) vor/nach einer Methode aus.
|
||||
Ablauf:
|
||||
\begin{enumerate}
|
||||
\item Der Client ruft eine Methode der Zielklasse auf.
|
||||
\item Der Container ruft zuerst die \texttt{@AroundInvoke}-Methode des Interceptors auf.
|
||||
\item Diese führt eigenen Code aus und ruft dann \texttt{ic.proceed()} auf.
|
||||
\item \texttt{proceed()} ruft die eigentliche Zielmethode (oder den nächsten Interceptor) auf.
|
||||
\item Der Rückgabewert wird zurückgegeben.
|
||||
\end{enumerate}
|
||||
|
||||
\item \textbf{Wie werden Interceptoren für Methoden erstellt?}
|
||||
|
||||
Man schreibt eine Methode mit der Annotation \texttt{@AroundInvoke}, die ein \texttt{InvocationContext}-Objekt erhält und \texttt{Object} zurückgibt. Beispiel:
|
||||
\begin{minted}[breaklines]{java}
|
||||
@AroundInvoke
|
||||
public Object log(InvocationContext ic) throws Exception {
|
||||
System.out.println("Vorher");
|
||||
return ic.proceed();
|
||||
}
|
||||
\end{minted}
|
||||
|
||||
\item \textbf{Wie können Interceptoren für mehrere Klassen erstellt werden?}
|
||||
|
||||
Man lagert die Interceptor-Methode in eine eigene Klasse aus und bindet sie mit \texttt{@Interceptors(LoggingInterceptor.class)} an die gewünschte Klasse oder Methode.
|
||||
Alternativ verwendet man ein \textit{Interceptor Binding} (siehe nächste Aufgabe).
|
||||
|
||||
\item \textbf{Worum handelt es sich beim Interceptor Binding?}
|
||||
|
||||
Interceptor Binding ist eine Qualifizierer-ähnliche Annotation, die mit \texttt{@InterceptorBinding} markiert wird.
|
||||
Der Interceptor wird mit dieser Annotation sowie \texttt{@Interceptor} versehen.
|
||||
Man kann dann jede Klasse oder Methode mit der Binding-Annotation versehen, um den Interceptor anzuwenden – ohne direkte Referenz auf die Interceptor-Klasse (lose Kopplung).
|
||||
|
||||
\item \textbf{Worum handelt es sich bei Dekoratoren?}
|
||||
|
||||
Dekoratoren sind spezielle CDI-Beans, die das Verhalten einer bestehenden Bean erweitern, indem sie dieselbe Schnittstelle implementieren und eine delegierte Referenz injizieren.
|
||||
Sie werden mit \texttt{@Decorator} annotiert und in \texttt{beans.xml} aktiviert.
|
||||
Dekoratoren eignen sich, um fachliche Erweiterungen (z.B. eine Superzahl bei Lottozahlen) hinzuzufügen.
|
||||
|
||||
\item \textbf{Wie können mit CDI Events erstellt werden?}
|
||||
|
||||
Ein Event wird über die generische Klasse \texttt{Event<T>} injiziert:
|
||||
\begin{minted}[breaklines]{java}
|
||||
@Inject private Event<MyEvent> event;
|
||||
\end{minted}
|
||||
Senden: \texttt{event.fire(myEvent);} (synchron) oder \texttt{event.fireAsync(myEvent);} (asynchron, seit CDI 2.0).
|
||||
Empfangen: Eine Methode mit Parameter \texttt{@Observes MyEvent event} (oder \texttt{@ObservesAsync}) in einer beliebigen CDI-Bean.
|
||||
|
||||
\item \textbf{Erstellen Sie einen Producer der ein Objekt vom Typ org.jboss.logging.Logger erstellt. Dieser Logger soll in verschiedene Klassen injizierbar sein. Testen Sie den Producer, indem Sie sich den Logger in einer Stateless Session Bean injizieren lassen und einen beliebigen String in die Konsole loggen.}
|
||||
|
||||
Die vollständige Implementierung befindet sich in den folgenden Dateien (siehe Code-Verzeichnis).
|
||||
Kurze Erklärung: Der Producer verwendet die \texttt{InjectionPoint}-API, um den Typ der injizierenden Klasse zu ermitteln. Dadurch wird der korrekte Logger für jede Klasse erzeugt. Die Stateless Session Bean injiziert den Logger und ruft \texttt{info()} auf.
|
||||
|
||||
\noindent\textbf{LoggerProducer.java}
|
||||
\inputminted[breaklines]{java}{../../server/src/main/java/org/example/demo/uebung5/aufgabe21/LoggerProducer.java}
|
||||
|
||||
\noindent\textbf{TestLoggerService.java}
|
||||
\inputminted[breaklines]{java}{../../server/src/main/java/org/example/demo/uebung5/aufgabe21/TestLoggerService.java}
|
||||
|
||||
\end{exercises}
|
||||
|
||||
\end{document}
|
||||
Reference in New Issue
Block a user