3 Jul 2011

Migration eines Eclipse RCP Projektes auf 4.x

von | Veröffentlicht in: Eclipse, Java, RCP | 0

Zur Zeit liegt das Eclipse SDK in Version 4.1 zum Download unter http://www.eclipse.org/eclipse4/ bereit. Im Gegensatz zum Early Adopter Release (Version 4.0) verwendet die Version 4.1 die neuere Indigo Update Seite, die seit dem 22 Juni 2011 zur Verfügung steht. Der Vorgänger verwendete hier noch die Update Seite von Helios.

Für die Migration eines bestehenden RCP Projektes auf das Eclipse SDK 4.1 habe ich mich dazu entschieden, dass Produkt Plugin komplett zu ersetzten, um die Vorteile von Eclipse 4.x direkt verwenden zu können. Insgesamt besteht das Projekt aus 13 reinen Plugin Projekten und weiteren 3 Projekten, die sowohl dem Server als auch dem Client zur Verfügung stehen. Hierbei handelt es sich um Maven Projekte, das Manifest wird mit dem Maven Plugin Felix erstellt. Weiterhin wird in den Client Projekten Spring DM eingesetzt, die OSGI Services werden hierüber veröffentlicht.

Nachdem das Eclipse SDK installiert ist fällt einem neben dem veränderten Aussehen vor allem die Geschwindigkeit auf, mit der sich nun die Plugins installieren lassen. Selbst die Installation von größeren Plugins wie WTP gehen extrem schnell vonstatten. Nach der Installation der benötigten Plugins (Eclipse e4 Tools, Subclipse, WTP, Maven, Maven Extras) werden zunächst alle Projekte in den aktuellen Workspace ausgecheckt, mit Ausnahme von der Target Plattform und dem Produkt Plugin.

Schnell ist ein neues Projekt angelegt, welches als neues Target dienen soll. Hier werden nun die benötigten neuen Eclipse SDK 4.1 Plugins rein kopiert und natürlich alle anderen verwendeten OSGI Libraries. Nun fügt man dem Projekt noch die Target Definition hinzu und konfiguriert sie entsprechend. Nachdem nun die von Eclipse verwendete Target Plattform auf das neu angelegte Target gewechselt wurde, dürften die Compile-Fehler in den Projekten verschwunden sein.

Anschließend kann das neue Produkt Plugin erstellt werden, hierbei handelt es sich zunächst um ein ganz normales „Plug-in Project“, welches als OSGI Framework Equinox verwendet. Öffnet man nun das Manifest kann man mit einem Klick auf Extensions den entsprechenden Reiter sichtbar machen. Nun fügt man als Abhängigkeit org.eclipse.equinox.app hinzu und setzt das Häkchen bei „This plug-in is a singleton“. Anschließend fügt man die Extension org.eclipse.core.runtime.products
hinzu und trägt bei ID product ein. Dem Feld wird nun ein Product hinzugefügt mit der Application org.eclipse.e4.ui.workbench.swt.E4Application und einem beliebigen Namen. Dem Product wiederum wird die Property appName mit einem entsprechenden Namen hinzugefügt. Es wird noch eine zweite Property mit dem Namen applicationXMI benötigt, mit dem Wert <Projektname>/Application.e4xmi. Die entsprechende Datei existiert zum jetzigen Zeitpunkt noch nicht, wird aber im folgenden Schritt angelegt.

Dem Projekt wird nun ein neues Application Model hinzugefügt. Dies ist nur möglich, wenn vorher die Eclipse e4 Tools erfolgreich installiert worden sind. Als Container wird das Produkt Projekt angegeben, der Dateiname Application.e4xmi sollte beibehalten werden.

In dem sich nun öffnenden Editor fügt man unter Windows ein Trimmed Window hinzu, hier kann der Titel und die gewünschte Fenster-Größe definiert werden. Nun benötigt das Projekt noch eine Product-Configuration. Sobald sich der entsprechende Editor geöffnet hat, fügt man neben den eigenen Projekten noch folgende Abhängigkeiten hinzu:

  • org.eclipse.equinox.ds
  • org.eclipse.equinox.event
  • org.eclipse.e4.ui.workbench.renderers.swt

Nun kann das neu erstellte Produkt zum ersten Mal gestartet werden, es wird sich ein leeres Fenster in der gewünschten Größe mit dem angegebenen Titel öffnen.

Will man nun noch Spring DM verwenden, muss anschließend noch das Bundle org.springframework.osgi.extender gestartet werden. Werden jetzt die eigenen Bundle gestartet, erkennt Spring DM – sofern vorhanden – die XML-Konfigurationsdateien im META-INF Ordner und fährt für die jeweiligen Bundle den Spring Context hoch.

Jetzt erst wird die erste Java Klasse im Product Projekt erstellt, die bisher benötigten Standard Implementierungen von

  • ActionBarAdvisor
  • WorkbenchAdvisor
  • WorkbenchWindowAdvisor
  • IApplication
  • IPerspectiveFactory

sind endlich nicht mehr nötig.

Stattdessen kann direkt mit der Implementierung von Funktionalitäten begonnen werden, für ein simples Beispiel reicht zunächst einmal ein ExitHandler zum Beenden der Workbench aus.

public class ExitHandler {

@Execute
public void execute(IWorkbench workbench) {
workbench.close();
}

}

Die Workbench selber, wird dem ExitHandler hierbei von OSGI per Dependency Injection übergeben. Es können beliebige weitere Parameter verwendet werden, wie z.B. in Spring DM exportierte OSGI Services oder andere OSGI Komponenten. Kann OSGI die entsprechenden Klassen nicht injizieren kommt es zu einer RuntimeException.

Um den ExitHandler zu verwenden müssen nun noch ein paar Einstellungen in der Application.e4xmi vorgenommen werden.  Zunächst wird ein Command erstellt mit der Id app.exit und dem Namen Exit. Jetzt wird ein Handler erstellt, der das gerade erstellte Command verwendet und der auf den ExitHandler als Implementierung verweist.

In dem Trimmed Window kann anschließend ein Main Menu erzeugt werden, dieses wiederum erhält ein Menu und dieses schlussendlich ein HandledMenuItem, welches das Exit Command Aufruft.

Natürlich soll das Applikations-Fenster entsprechenden Inhalt bekommen. Hierzu wird, wie in der Vorgänger Version, eine View benötigt. Mittlerweile muss diese aber nicht von ViewPart Erben, ein ganz normales POJO reicht als View aus. Lediglich über dem Konstruktor wird eine @Inject Annotation benötigt, so dass das Parent Composite vom OSGI Framework übergeben werden kann.

  @Inject
public MyView(Composite parent) {
// do what you have to do – something with ui for example
}

Um die View zu verwenden muss auch diesmal eine Anpassung in der Application.e4xmi vorgenommen werden. Unterhalb des Trimmed Window befindet sich der Punkt Controls, hier kann nun ein Part Stack erstellt werden. Dieser bekommt wiederum einen Part der die soeben erstellte MyView Klasse zur Ausführung erhält.

Dieser Artikel soll einen kurzen Einblick in Eclipse SDK 4.x vermitteln und erläutern wie man einfach ein bestehendes RCP Projekt migrieren kann. Grade die endlich in OSGI integrierte Dependency Injection und das neue Application Model mit dem hilfreichen und einfach zu bedienenden e4xmi-Editor machen Freude.

20 Jun 2011

CDI Events – Das Observer Pattern in Java EE 6

von | Veröffentlicht in: Java, JEE 6 | 2

CDI Events können als ein neues Architekturmuster für Java EE 6 Anwendungen gesehen werden, dass am meisten dem Observer Pattern ähnelt. Auch hier gibt es ein zu überwachendes Objekt, auf welches verschiedenste Komponenten reagieren, deren Implementierung aber unbekannt bleiben soll.

Um dies zu ermöglichen benötigt das zu überwachende Objekt Möglichkeiten zum Registrieren und Entfernen von sogenannten Observern, welche bei bestimmten Änderungen des Objektes benachrichtigt werden.

Bei CDI Events reichen einfache Annotations aus, um die Observer im CDI Kontext zu registrieren. Eine Registrierung beim überwachten Objekt selbst, ist nicht mehr nötig.

Dieses Objekt, bzw. Event ist ein ganz normales POJO mit beliebigen Attributen und entsprechenden getter– und setter Methoden.

public class UserEvent {

private String username;

public UserEvent() {}

public String getUsername() {
return username;
}
public void setUsername(String username) {
this.username = username;
}
}

Um das Event zu feuern, auf welches anschließend von den Observern reagiert werden soll, ist folgendes Code Fragment nötig:

 @Inject
private Event<UserEvent> event;

public void doSomething() {
event.fire(new UserEvent(„Mustermann“));
}

Das Registrieren von Observern im CDI Kontext erfolgt mittels der Annotation @Observes und dem Event als Übergabe-Parameter. Der Observer kann nun seine Aufgabe verrichten und dabei auf das Event zugreifen. Die Implementierung eines Interfaces ist nicht mehr nötig:

public class UserHandler {
public void handleUser(@Observes UserEvent event) {
// do what you have to do …
}
}

Soll die Abarbeitung innerhalb eines Observers asynchron erfolgen, d.h. nach dem Aufruf der fire-Methode des Events nicht auf den Observer gewartet werden, kann dies mit der Annotation @Asynchronous innerhalb des Observers definiert werden:

@Stateless
public class UserHandler {

@Asynchronous
public void handleUser(@Observes UserEvent event) {
// do what you have to do … but asynchronously
}
}

Mit Hilfe von CDI Events kann man die Software-Architektur recht einfach entkoppeln und hat eine Möglichkeit geschaffen, leicht Funktions-Erweiterungen implementieren zu können.

Bereits vor CDI gab es Frameworks, die Events unterstützt haben. Hier sei das Axon Framework (CQRS – Command Query Responsibility Segregation) genannt, wobei hier das Event-, bzw. Command-Handling nur eine Komponente von vielen war.

Ganz neu ist die Event Idee auf jeden Fall nicht, nun hat sie aber ihren Weg in den Java EE Standard gefunden.

8 Jun 2011

CDI im Tomcat verwenden

von | Veröffentlicht in: Java, JEE 6 | 0

Die einfachste Art die Java EE 6 Funktionalität CDI einsetzten zu können, ist die Verwendung eines vollwertigen Application Servers wie z.B. Glassfish in der aktuellen Version 3.1. Um CDI in einem Tomcat 7 verwenden zu können, ist etwas mehr Aufwand vonnöten, da dieser außer der Servlet API 3.0 keine Java EE 6 Komponenten von Haus aus mitliefert.

Um in einer Web-Applikation die innerhalb eines Tomcats läuft CDI bzw. Wend verwenden zu können, reicht ein einziges JAR-Archiv aus: weld-servlet.jar

Dieses kann bequem per Maven in einer Web-Applikation integriert werden:

<dependency>
<groupId>org.jboss.weld.servlet</groupId>
<artifactId>weld-servlet</artifactId>
<version>1.0.1-Final</version>
</dependency>

Zusätzlich wird noch folgender Eintrag in der web.xml des jeweiligen Web-Projektes benötigt:

<listener>
<listener-class>
org.jboss.weld.environment.servlet.Listener
</listener-class>
</listener>

Leider verwendet der Tomcat 6 die Servlet API 2.5, so dass hier nicht so einfach die Vorteile der Servlet API 3.0 zum Einsatz kommen können. CDI selber kann natürlich dennoch verwendet werden, hier kommt es nicht zu Konflikten mit den Libraries des Tomcats.

7 Jun 2011

Quickstart in Java EE 6 und CDI

von | Veröffentlicht in: Java, JEE 6 | 0

Auf der JAX 2011 konnte ich mir ein paar interessante Vorträge über Java EE 6 im Allgemeinen und CDI im Speziellen anhören. Leider bin ich erst jetzt – einen guten Monat später – dazu gekommen, entsprechende Beispiele zu vertiefen.

Für einen möglichst schnellen Start empfiehlt es sich den Application Server GlassFish in der aktuellen Version 3.1 zu downloaden, bei diesem handelt es sich um die Referenz-Implementierung zu Java EE 6. Dementsprechend liefert GlassFish 3.1 bereits alle Java EE 6 Funktionalitäten inklusive der Servlet API 3.0 und CDI von Haus aus.

Aus Eclipse heraus lässt sich einfach ein Dynamic Web Project erstellen. Eclipse WTP in der aktuellen Version 3.2.3 unterstützt bereits GlassFish 3.1.

Dank der Servlet API 3.0 muss nicht länger die web.xml konfiguriert werden, eine einfache Annotation in der entsprechenden Klasse reicht aus, um das Servlet im Web Container zu registrieren.

@WebServlet(„/MyUserServlet“)
public class MyUserServlet extends HttpServlet {
…
}

Hier kann nun wie bereits in den Vorgängerversionen gehabt, die doGet Methode überschrieben werden. Anschließend ist das Servlet bereits über den Browser aufrufbar. Für weitere Request-Arten gibt es natürlich ebenfalls Methoden, die überschrieben werden können.

Kommen wir nun zur eigentlichen CDI Funktionalität, welche auch unter dem Namen Weld bekannt ist. Um CDI im Web Container zu aktivieren, ist es notwendig eine Datei beans.xml im WEB-INF Verzeichnis der Web Applikation zu erstellen. Eine leere Datei ist hierfür ausreichend.

Ein Beispiel von CDI ist die fachliche Dependency Injection. Hierbei wird nicht wie in der bisherigen Dependency Injection ein Service injiziert, sondern ein fachlicher Context. In einer herkömmlichen Web Applikation ist es nötig den UserService injiziert zu bekommen, ausschliesslich um an den eingeloggten Benutzer zu kommen. Statt dessen kann man sich nun einfach den Benutzer in die Applikation injizieren lassen und spart sich so den unnötigen Serveraufruf und eine Abhängigkeit auf den UserService.

Hierfür wird lediglich die Annotation @Produces über der Methode getCurrentUser benötigt, anschließend kann CDI eine @Inject Annotation auflösen, mit deren Hilfe der Benutzer an die entsprechende Stelle injiziert werden kann.

Der UserService hierfür sieht so aus:

@Produces
public User getCurrentUser() {
User user = new User(„max mustermann“);
return user;
}

Um den Benutzer in das Servlet injizieren zu lassen, reicht folgendes Code-Fragment:

@Inject User user;

Dieses Verfahren funktioniert allerdings nur, solange nicht weitere Methoden mit @Produces annotiert sind, die einen User zurück geben. Ist dies der Fall müssen diese unterschieden werden. Hierfür werden Qualifier benötigt, die mittels eigener Annotation definiert werden:

@Qualifier
@Retention(RUNTIME)
@Target( { TYPE, METHOD, PARAMETER, FIELD })
public @interface CurrentUser {
@Nonbinding String name();
}

Um das Beispiel interessanter zu machen, wird direkt in der Annotation der Name des Benutzers mit übergeben, so dass an der erzeugenden Stelle, der Name des Benutzers über die Annotation abgefragt werden kann:

@Produces
@CurrentUser(name=““)
public User getCurrentUser(InjectionPoint injectionPoint) {
String username = null;
for (Annotation qualifier : injectionPoint.getQualifiers()) {
if (qualifier instanceof CurrentUser) {
CurrentUser currentUser = (CurrentUser) qualifier;
username = currentUser.name();
}
}
User user = new User(username);
return user;
}

Die Annotation @CurrentUser zeigt an, dass diese Methode lediglich für den CurrentUser zuständig ist. Der Name der hier leer gelassen wurde, spielt keine Rolle, muss aber angegeben werden, da dies in der Annotation so gefordert ist. Der Parameter InjectionPoint wird direkt von CDI in die Methode injiziert. Über diesen Parameter kommt man an die Annotation, die im Injizierungspunkt gesetzt wurde. So kann man den Namen des Benutzers erfragen, der in der Annotation festgelegt wurde und diesen für den zu erstellenden Benutzer verwenden.

Die Stelle an der man den Benutzer injiziert bekommen möchte, sieht so aus:

@Inject @CurrentUser(name=“max mustermann“) User user;

Hier wird der Name gesetzt, der in der @Produces Methode dem Benutzer übergeben wird.

Dies war lediglich ein kleiner Teil der CDI Funktionalität. Ebenfalls sehr interessant ist das Event Konzept, die Möglichkeit einzelne Teile einer Anwendung per Annotation asynchron ausführen zu können, Aspekte unter CDI und vieles mehr.

Doch dazu zu einem späteren Zeitpunkt mehr.