CDI SE – registry for managed services
Auf der Serverseite erfreut man sich der Möglichkeit per CDI die Komponenten zu entkoppeln.
Das ist ja bekanntlich auch auf der SE Seite möglich. Typische Konstrukte sehen dann meist wie folgt aus.
1) Initialisiere den Weldcontainer
2) Hole eine erste managed instance
3) Arbeite auf den Referenzen.
Was hier nicht schön ist, ist die Referenz auf den initialen Weldcontainer. Die muss an den verschiedenen Stellen in der Applikation zur Verfügung gestellt werden.
Anbei eine Demo wie dieses für eine Registry von Services aussehen kann.
Es gibt eine ServieRegistry von der aus man die vom Weldcontainer verwalteten Servicees bekommen kann. Der Einfachheit halber als Liste von Services.
Die Services selber sind abgeleitet von dem Interface Service. Soweit alles wie bekannt. Jeder Service erhält die Annotation RegisteredService.
Über diese Annotation kann die ServiceRegistry die Services selbständig identifizieren. Dass ist hier durch ein Classloading realisiert.
Dieser Prozess wird initial durch die Annotation @PostContruct getriggert.
Das Laden der Klassen ist per Reflection gelöst, kann natürlich auch beliebig anders erfolgen.
Die Klassen werden in einer internen ArrayList gespeichert und erst instanziiert , wenn die Services benötigt werden.
Wie man unschwer erkennen kann, ist die Serviceregistry selbst schon eine vom WeldContainer verwaltete Instanz. (Siehe Annotationen)
Der WeldContainer selbst wird in der ServiceRegistryFactory initialisiert und gehalten.
Damit hat man über diesen Umweg, die Möglichkeit eine vom WeldContainer verwaltete Serviceregistry zu erhalten.
Die Services selbst werden bei Bedarf erzeugt. Das passiert in der Methode getManagedService
Zu beachten ist, das man die Services über einen Producer erzeugen muss, damit die Services selber wieder vom WeldContainer verwaltet werden.
Die Verwendung selbst ist dann sehr einfach…
Die Sourcen zu diesem Beispiel befinden sich im Repository: https://bitbucket.org/rapidpm/java-cdi-se-demo
Das ist ja bekanntlich auch auf der SE Seite möglich. Typische Konstrukte sehen dann meist wie folgt aus.
1) Initialisiere den Weldcontainer
2) Hole eine erste managed instance
3) Arbeite auf den Referenzen.
Was hier nicht schön ist, ist die Referenz auf den initialen Weldcontainer. Die muss an den verschiedenen Stellen in der Applikation zur Verfügung gestellt werden.
Anbei eine Demo wie dieses für eine Registry von Services aussehen kann.
Es gibt eine ServieRegistry von der aus man die vom Weldcontainer verwalteten Servicees bekommen kann. Der Einfachheit halber als Liste von Services.
Die Services selber sind abgeleitet von dem Interface Service. Soweit alles wie bekannt. Jeder Service erhält die Annotation RegisteredService.
Über diese Annotation kann die ServiceRegistry die Services selbständig identifizieren. Dass ist hier durch ein Classloading realisiert.
Dieser Prozess wird initial durch die Annotation @PostContruct getriggert.
Das Laden der Klassen ist per Reflection gelöst, kann natürlich auch beliebig anders erfolgen.
Die Klassen werden in einer internen ArrayList gespeichert und erst instanziiert , wenn die Services benötigt werden.
Wie man unschwer erkennen kann, ist die Serviceregistry selbst schon eine vom WeldContainer verwaltete Instanz. (Siehe Annotationen)
Der WeldContainer selbst wird in der ServiceRegistryFactory initialisiert und gehalten.
Damit hat man über diesen Umweg, die Möglichkeit eine vom WeldContainer verwaltete Serviceregistry zu erhalten.
Die Services selbst werden bei Bedarf erzeugt. Das passiert in der Methode getManagedService
Zu beachten ist, das man die Services über einen Producer erzeugen muss, damit die Services selber wieder vom WeldContainer verwaltet werden.
Die Verwendung selbst ist dann sehr einfach…
Die Sourcen zu diesem Beispiel befinden sich im Repository: https://bitbucket.org/rapidpm/java-cdi-se-demo
Kommentare
Kommentar veröffentlichen