Code Splitting von GWT ist eine tolle Sache. Da ich kein Guru bin werde ich mal versuchen das in meinen laienhaften Worten zu erklären. GWT liefert alles was man programmiert an den Client aus, da das teilweise sehr viel sein kann wurde Code Splitting eingeführt. Presenter, deren Proxies mit der ProxyCodeSplit Annotation versehen sind werden erst vom Server nachgeladen, sobald diese das erste mal mit Inject verwendet werden. Dadurch kann der Client den GWT Code schneller laden, da dort nur die notwendigen Sachen hinterlegt werden. Der Code von Presentern die nicht von Anfang an benötigt werden, wird also erst bei deren erster Verwendung vom Server zum Client übertragen.

Diese Möglichkeit lässt es sinnvoll erscheinen, im gesamten Anwendungscode bzw. soviel wie möglich, Code Splitting zu verwenden. Ein zusätzlicher Vorteil ist, die Funktionalität der einzelnen Klassen kann schön klein gehalten werden, da der Presenter notwendige Klassen injiziert bekommen kann. Die Sache hat nur einen Haken: Das Nachladen benötigt erstens etwas Zeit und zweitens muss für jeden gesplitteten Code eine Anfrage an den Server gestellt werden. Jede Anfrage benötigt durch den Overhead noch zusätzlich Zeit, außerdem bearbeiten Browser i.d.R. nur zwei Anfragen an eine Domain gleichzeitig. Wird also ein Presenter angezeigt, der selber mehrere gesplittete Teile enthält, kann dies den Benutzereindruck trüben.

Die Lösung hierfür haben die Entwickler von GWT mit Provider Bundles geschaffen. In einem ProviderBundle legt man alle zusammenhängende Teile fest, die gemeinsam nachgeladen werden sollen. In der Anwendung an der ich gerade arbeite verwenden wir das, um bestimmte Aktionen auszulagern, die von mehreren Presentern verwendet werden können. Dadurch kann jede Aktion in einem übersichtlichen Class File programmiert werden das zudem noch in einer entsprechenden Package Hirarchie für eine leichtere Wartbarkeit abgelegt werden kann. Für jeden Presenter gibt es dann ein ProviderBundle das festlegt, welche Actions mit dem Presenter geladen werden sollen. Code Splitting und Provier Bundles können aber auch anders verwendet werden.

Die GWT bzw. GWTP Dokumentation erklärt das Vorgehen leider (noch) nicht. Für viele mag sich die Verwendung auch aus den Kommentaren der ProviderBundle Klasse erschließen, ich hatte hierbei jedoch einige Anlaufschwierigkeiten. Daher möchte ich hier mal kurz die Vorgehensweise skizzieren:

public class ShowGalleriesA extends UiAction {
	...
}

Das ist die Action Klasse. Die Implementierung ist für den Mechanismus nicht wichtig, daher hab ich sie weg gelassen. Man muss hier eigentlich nur beachten, das es nichts zu beachten gibt ;)
Es ist eine ganz gewöhnliche Java Klasse, es sind keine Annotations oder ähnliches notwendig (außer natürlich das was für die Funktion der Klasse benötigt wird). Auch UiAction, die Basisklasse, enthält nichts was mit dem Code Splitting zu tun hat.

public class DashboardPr extends PlacePresenter {

	@ProxyCodeSplitBundle(bundleClass = DashboardBundle.class, id = DashboardBundle.ID_DashboardPresenter)
	@NameToken(NameTokens.dashboard)
	public interface MyProxy extends ProxyPlace {
	}

	@Inject
	public DashboardPr(
            DashboardIf view,
            MyProxy proxy,
            final ShowGalleriesA aShowGalleries) {
		super(view, proxy);

		setActions(aShowGalleries);
	}
	...
}

Der Presenter hingegen ist schon interessanter. Die normalerweise verwendete @ProxyCodeSplit Annotation wird durch @ProxyCodeSplitBundle ersetzt. In den Parametern der Annotation muss angegeben werden welche Klasse das Bundle definiert und welche ID daraus der des annotierten Proxies entspricht. Siehe Definition des Provider Bundles:

public class DashboardBundle extends ProviderBundle {
	public final static int ID_DashboardPresenter = 0;
	public final static int ID_ActionShowGalleries = 1;
	public final static int BUNDLE_SIZE = 2;

	@Inject
	public DashboardBundle(
			final Provider dashboardPresenter,
			final Provider actionShowGalleries) {
		super(BUNDLE_SIZE);

		providers[ID_DashboardPresenter] = dashboardPresenter;
		providers[ID_ActionShowGalleries] = actionShowGalleries;
	}
}

Sollte eigentlich relativ selbsterklärend sein ;)
Alle Teile des Bundles (die also zusammen geladen werden sollen) werden mit @Inject dem Konstruktor übergeben und in einem Feld providers der Basisklasse ProviderBundle hinterlegt. Wichtig ist hierbei, dass die Größe des providers Array dem Superklassen Konstruktor richtig mitgegeben wird. Am einfachsten macht man das über die gezeigten (und auch von Google empfohlenen) statischen Konstanten mit denen man dann auch auf die jeweiligen IDs der einzelnen Teile des Bundles verweisen kann (siehe Parameter der @ProxyCodeSplitBundle Annotation in der Presenter Klasse).

Nun müssen im Ginjector die AsyncProvider für die Einzelteile definiert werden, damit das Injizieren funktioniert:

public interface MyGinjector extends Ginjector {
	...
	AsyncProvider getCustomerDetailPresenter();
	AsyncProvider getShowGalleriesAction();
	AsyncProvider getDashboardBundle();
	...
}

Und schon wird die Aktion automatisch mit dem Presenter geladen. Einfach oder? ^^

Wie der Titel schon sagt verwende ich NetBeans 6.8 mit Glassfish v3 und Maven für meine Java EE 6 Anwendung. Wie es sich gehört wird fleißig Einsatz von JPA gemacht. Hier wird  mal vorausgesetzt, dass die Anwendung schon brav Kontakt zur Datenbank aufgenommen hat, in meinem Fall MySQL, sprich alle JDBC Pools und Connections wurden erfolgreich angelegt. Somit können wir später direkt die Konfiguration der Domains des richtigen Glassfish Application Servers in unserem Embedded Container verwenden um mittels JPA auf die Datenbank zu zu greifen. Wer lieber zum Testen eine seperate Datenbank nehmen möchte kann hier nachlesen wie er da vorgehen muss.

Als erstes muss die embedded Version des Glassfishes in Maven eingebunden werden. Hier ergab sich bereits mein erstes Problem, da sich die Repositories und der notwendige Dependency Eintrag nicht so einfach im Internet finden lassen. Deshalb hier die Abhängigkeit:

<dependency>
  <groupId>org.glassfish.extras</groupId>
  <artifactId>glassfish-embedded-all</artifactId>
  <version>3.0</version>
  <scope>test</scope>
</dependency>

<dependency>
  <groupId>javax</groupId>
  <artifactId>javaee-api</artifactId>
  <version>6.0</version>
  <scope>provided</scope>
</dependency>

Der untere Eintrag wird für den Container zwar nicht benötigt, wird hier aber dennoch erwähnt, da es wichtig ist, das der embedded Glassfish Eintrag vor diesem in der pom.xml erscheint, da es sonst zu Fehlermeldungen beim Testen und Deployen kommen kann.
Der zugehörige Repository Eintrag lautet wie folgt:

<repository>
  <id>embedded-glassfish</id>
  <name>Embedded Glassfish Maven Repository</name>
  <url>http://download.java.net/maven/glassfish</url>
</repository>

Nun sollten diese Abhängigkeiten erstmal durch ein Build besorgt werden um zu sehen ob hier alles geklappt hat. Achtung! die embedded Version des Glassfish hat knapp 45MB, das Herunterladen kann also etwas dauern (wenn man wie ich nur ne 768kBit/s Leitung hat).

Nun kümmern wir uns um die Unit Tests. Dazu poste ich euch hier einen komplett funktionsfähigen Test den ich im Anschluss versuche zu erläutern. Da ich nämlich keinen kompletten Test in anderen Blogs finden konnte, sondern nur Codeschnipsel, hatte ich am Anfang noch mit einigen Exceptions zu kämpfen (naja, ich programmiere erst seit ein paar Wochen in Java, was will man erwarten).

package sample.test.controller;

import sample.controller.UserEntityFacade;
import sample.model.UserEntity;
import java.io.File;
import java.util.HashMap;
import java.util.Map;
import javax.ejb.embeddable.EJBContainer;
import javax.naming.Context;
import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;
import org.junit.Assert;

public class UserEntityFacadeFixture {

    public UserEntityFacadeFixture() {
    }

    public static EJBContainer container;
    public static Context context;
    public static UserEntityFacade facade;

    @BeforeClass
    public static void setUpClass() throws Exception {
        Map properties = new HashMap();
        properties.put(EJBContainer.MODULES, new File("target/classes"));
        properties.put("org.glassfish.ejb.embedded.glassfish.installation.root", "/Applications/NetBeans/sges-v3/glassfish");
        container = EJBContainer.createEJBContainer(properties);
        context = container.getContext();
        facade = (UserEntityFacade)context.lookup("java:global/classes/UserEntityFacade");
    }

    @AfterClass
    public static void tearDownClass() throws Exception {
        context.close();
        container.close();
    }

    @Before
    public void setUp() {
    }

    @After
    public void tearDown() {
    }

    @Test
    public void CreateUserEntity() {
        UserEntity user = new UserEntity();
        user.setUsername("jack");
        user.setPassword("jack");

        int count = facade.count();
        facade.create(user);
        Assert.assertEquals(count + 1, facade.count());
    }
}

Hauptaugenmerk muss hier natürlich auf die Initialisierung des Containers gelegt werden. Dazu werden statische Variablen angelegt um den Container beim Start des Tests zu Starten und für alle Tests zur Verfügung zu haben. Am Ende der Tests wird der Container und der Context wieder geschlossen. Man beachte auch den import Bereich, da ich bei simpler Angabe von “public static Context context;” in einigen Codeschnipseln nämlich nicht rauslesen konnte das es sich dabei um den “javax.naming.Context” handeln soll. Aber wahrscheinlich ist das allen Java Experten klar.

Beim Erstellen des Containers wird der createEJBContainer Mehtode hier eine Hashmap mit Einstellungen übergeben. Dies ist an dieser Stelle wichtig, da wir JPA verwenden und daher das Verzeichnis vom Glassfish mit angeben müssen, damit der EJB Container die Konfiguration der JDBC Resourcen aus dessen Konfiguration lesen kann. Wird kein JPA verwendet, können die Einstellungen ganz entfallen, sprich es wird kein Parameter übergeben.

Anschließend holt man sich den Context und frägt daraus seine EJBs an. An dieser Stelle hatte ich auch wieder zu kämpfen. Mir war nicht ganz klar wie sich der JNDI Name aufbaut. Beim JBOSS hätte ich jetzt immerhin gewusst wo ich diesen nachschauen kann. Bei TheServerSide werden die mit EJB 3.1 eingeführten globalen JNDI Namen zwar erläutert, doch damit ließen sich meine Beans dennoch nicht auffinden. Nach langem Suchen bin ich dann auf die einfache und funktionierende Version oben gestoßen. Dabei ist der vordere Teil fest und nur der Name der Bean angehängt. Wenn mir jemand diesen Sachverhalt genauer erklären kann darf er sich in den Kommentaren dazu gerne auslassen ;-)

Der Rest des Listings dürfte hoffentlich keine Schwierigkeiten bereiten. Der Vollständigkeit halber hier noch die Blog Posts, die mir hierbei sehr hilfreich waren:

[1] Using the EJBContainer API with or without Maven (but with GlassFish v3)
[2] Unit Testing EJBs and JPA with Embeddable GlassFish
[3] EMBEDDING EJB 3.1 CONTAINER INTO YOUR UNIT TESTS – BOOT TIME: 5 SECONDS
[4] HOW TO UNIT-TEST EJB 3 …IN 0.8 SECONDS [SOURCE CODE INCLUDED]
[5] EJB Lite testing with JUnit and embeddable container

Doch das eigentliche Problem trat bei mir ganz am Anfang der Anleitung auf. Man muss den MySQL Connector für Java im CLASSPATH hinterlegen. Nun reicht es dabei unter Windows schon aus den Connector im Glassfish Verzeichnis in lib zu positionieren, was auf dem Mac unseren geliebten Application Server aber noch lange nicht zufrieden stellt. Nach langem Stöbern bei Onkel Google bin ich über den Beitrag Mac OS X for Java Geeks gestolpert, der mir die CLASSPATH Geschichte des Betriebssystems näher zu bringen versuchte. Allerdings hat auch das Ablegen der Connector JAR Datei im Extension Ordner des Java Verzeichnisses nur wenig Erfolg gezeigt.

Erst in einem Forum Post hab ich die für mich funktionierende Lösung tatsächlich gefunden. Innerhalb von NetBeans kann man die CLASSPATH Variablen verwalten. Dazu geht man im Menü auf “Tools” und anschließend auf “Libraries”. Links findet man eine Liste die in Class- und Server Libraries aufgeteilt ist. Unter Server ist schließlich ein Eintrag “Java-EE-GlassFish-v3″. Nach anwählen kann man sich im Fenster rechts die enthaltenen Bibliotheken ansehen. Nach kurzem durchforsten fällt auf das diese alle unter “/Applications/NetBeans/sges-v3/glassfish/modules/” liegen. Also habe ich kurzerhand den MySQL Connector da rein geschmissen und hier als Library mittels “Add JAR/Folder…” hinzugefügt. Im Anschluss noch kurz Glassfish neugestartet und schon funktioniert der Ping auf den MySQL Connection Pool wie gewünscht. Nun kann mit den oben genannten Tutorials weiter verfahren werden um MySQL zum Connection Pool hinzu zu fügen.