1. Primärschlüssel von Entitäten in AppEngine müssen den Typ com.google.appengine.api.datastore.Key haben. Dies ist nicht konform zur JPA-Spezifikation.
2. Nach Aufruf von EntityManager.persist ist die Id des persistierten Entity-Objekts nicht gesetzt. Dies ist ebenso nicht JPA-Spec-konform.

Ein Aufruf an EntityManager.refresh hilft, damit die Id gesetzt ist und z.B. an den Client zurückgeliefert werden kann, wie folgendes Beispiel zeigt:

QuestEntity questEntity = new QuestEntity();
questEntity.setMessage(quest.message);
entityManager.persist(questEntity);
entityManager.refresh(questEntity); // to retrieve the id
assert questEntity.getId() != null;
quest.id = KeyFactory.keyToString(questEntity.getId());

Mit einer JPA-Implementierung wie Hibernate oder EclipseLink wäre questEntity.id bereits nach Aufruf von “persist()” gesetzt. Vermutlich hat dies etwas mit dem Fakt zu tun, dass App Engine mit der verteilten Objektdatenbank Big Table arbeitet und nicht mit einer relationalen Datenbank.

Maven-Module verwalten Produktiv- und Testcode in getrennten Verzeichnissen (src/main und test). Das Packaging (z.B. als JAR) exkludiert Testklassen und -ressourcen. Damit andere Module Test-Hilfsklassen, Mock-Implementierungen, etc. verwenden können, müssen diese in src/main liegen. Elemente von src/test bleiben für andere Module verborgen. Um Testklassen wiederzuverwenden, lagert man in diese in ein separates Testmodul aus. Das sieht z.B. wie folgt aus:

Der Testcode und die Hilfsklassen für “framework” sind nach “framework-test” ausgelagert worden. Die Test-Hilfsklassen operieren auf “framework”-Klassen. Die Testklassen benötigen die Testhilfsklassen. Würden die Tests innerhalb von “framework” liegen gebe es einen Modulzyklus. Dies ist weder sinnvoll noch von Maven erlaubt.

Wer seine Testabdeckung automatisiert ermittelt bekommt mit dieser Modulaufteilung Probleme. Per Default ermitteln Cobertura, Clover, Emma die Unit-Test-Abdeckung nur pro Modul. Obwohl umfangreiche Tests für den Code in “framework” existieren, liefert eine Messung 0% Abdeckung.

Lösung mit JaCoCo

JaCoCo wird von den Emma-Machern entwickelt und arbeitet über Byte-Code-Instrumentation zur Laufzeit mittels eines JVM-Agents.

Mittels JaCoCo-Agent und dem JaCoCo-Sonar-Plugin lässt sich das Testabdeckungsproblem lösen und sogar die Abdeckung für Integrationstests messen. Das im Folgenden beschriebene Setup umfasst Jenkins / Hudson sowie Sonar Konfiguration und Anpassungen an Euren Maven POMs.

1. JaCoCo bereitstellen

Das “jacoco-agent.jar” wird auf dem System, welches die Tests ausführt (z.B. Euer CI Server), benötigt.

1. ZIP herunterladen (wget …) z.B. nach /var/lib/jacoco. Achte darauf, dass Deine Sonar-Installation zum JaCoCo-Agent kompatibel ist oder entschließe Dich, Deine Sonar-Installation upzugraden.
2. unzip

2. POM anpassen

Das Surefire Plugin muss den JaCoCo-Agent einbinden, wenn es die Tests ausführt. Der Agent muss Coverage-Informationen für alle Eure Module in dieselbe Datei schreiben.

   1: <profiles>

   2:   <profile>

   3:     <id>ci</id>

   4:       <build>

   5:         <pluginManagement>

   6:           <plugins>

   7:             <plugin>

   8:               <artifactId>maven-surefire-plugin</artifactId>

   9:                 <configuration>

  10:                   <argLine>-javaagent:${jacoco.agent.path}=destfile=${jacoco.unit.path}</argLine>

  11:                 </configuration>

  12:               </plugin>

  13:             </plugins>

  14:           </pluginManagement>

  15:       </build>

  16:   </profile>

  17: </profiles>

3. Jenkins / Hudson Job konfigurieren

Jenkins muss die Variablen “jacoco.agent.path” und “jacoco.unit.path”. Dazu bei “Goals und Optionen” in der Job-Konfiguration z.Bsp. folgendes angeben:

clean install -P ci -Djacoco.agent.path="/var/lib/jacoco/lib/jacocoagent.jar" -Djacoco.unit.path="/tmp/mapgame-jacoco-unit"

Gib bei der Sonarkonfiguration des CI-Jobs die Option “-Dsonar.jacoco.itReportPath=/tmp/mapgame-jacoco-it“ an. Das JaCoCo-Sonar-Plugin erkennt diese System-Property und findet dadurch die Report-Datei.

4. Sonar JaCoCo Plugin installieren

Installiere im Sonar Update Center das Plugin “JaCoCo”. Konfiguriere unter Sonar – Settings – Core – Code Coverage Plugin den Wert “jacoco”. Hast Du alles korrekt gemacht, so wirst Du auf Deinem Sonar-Dashboard nach Lauf des CI-Jobs im Jenkins / Hudson den korrekten Wert für die Unit-Testabdeckung sehen.

Trennung Unit- und Integration-Tests

JaCoCo kann natürlich auf die Integration-Test-Abdeckung messen. Dies solltest Du getrennt von der Unit-Test-Messung halten. Mit Unit-Tests kann nach TDD entwickelt werden, mittels Integration-Tests nicht wirklich, welche Change & Test-Phase zu lang dauert und Unit-Tests eine viel lokalere Betrachtung erlauben. Dadurch ist Bugfixing bei Testfehlschlägen effizienter.

Für Integrationstests sollte das “maven-failsafe-plugin” verwendet werden, da es Aufräumarbeiten nach Integrationstests (Server stoppen, etc.) besser beherrscht (post-integration-test Phase wird bei Test-Fehlschlägen aufgerufen. Dies ist bei Surefire nicht der Fall.).

1. POM erweitern

Die Code-Abdeckung in den Integration-Tests selbst soll gemessen werden:

<plugin>  <artifactId>maven-failsafe-plugin</artifactId>  <configuration>    <argLine>-javaagent:${jacoco.agent.path}=destfile=${jacoco.it.path}</argLine>  </configuration></plugin>

Natürlich musst Du den JaCoCo-Agent auch in den getesteten Systemen einbinden. Bei mir ist dies die lokale Google App Engine.

<profiles>  <profile>    <id>ci</id>    <build>      <pluginManagement>        <plugins>          <plugin>            <groupId>net.kindleit</groupId>            <artifactId>maven-gae-plugin</artifactId>            <executions>              <execution>                <id>start-app-engine</id>                <phase>pre-integration-test</phase>                <goals>                  <goal>start</goal>                </goals>                <configuration>                  <javaAgent>${jacoco.agent.path}=destfile=${jacoco.it.path}</javaAgent>                </configuration>              </execution>            </executions>          </plugin>        </plugins>      </pluginManagement>    </build>  </profile></profiles>

2. Jenkins / Hudson CI Job erweitern

• Zusätzlicher Parameter bei “Goals und Optionen”: -Djacoco.it.path="/tmp/mapgame-jacoco-it"
• Zusätzlicher Parameter bei Sonar MAVEN_OPTS: -Dsonar.jacoco.itReportPath=/tmp/mapgame-jacoco-it

3. Sonar Dashboard erweitern

1. Im Sonar Dashboard “configure widgets” klicken
2. “IT coverage widget” hinzufügen

Fazit

JaCoCo funktioniert!

Hohe Code-Abdeckung durch gut strukturierte Unit- und Integrationstests, die jeweils nur eine “Sache” testen, sind die halbe Miete für gute Softwarequalität!

Memory Allocation

1. App in Eclipse mittels Android Development Tools (ADT) starten.
2. App in den Zustand versetzen ab der die Untersuchung relevant ist (bei mir: in Spielewelt einloggen)
3. In Eclipse-Perspektive DDMS wechseln.
4. Den Prozess im Emulator / Device auswählen, der Eurer App entspricht.
5. Auf den Reiter “Allocation Tracking” wechseln
6. Button “Start Tracking” klicken
   
7. Abwarten bis aus Eurer Sicht genug Daten gesammelt sind (bei mir ein paar Animation-Frames)
8. “Get Allocations” Button klicken um die gesammelten Informationen anzuzeigen
9. Interessant für Optimierungen sind für mich häufig auftretende Allokation an denselben Code-Stellen. Dazu die Tabelle nach “Allocated In” sortieren. Für jede Allokation kann im unteren Teil der View der Stack-Trace betrachtet werden um die verantwortliche Stelle im eigenen Code zu identifizieren.
   

Anhand dieser Analysen habe ich Stellen identifiziert in den z.B. unnötig Collection-Objekte erzeugt wurden. Diese habe ich durch Caching der verwendeten Collection in Instanzvariablen des längerlebigen Objekts optimiert (Vermeidung von Allokationen).

Ausführungszeiten von Methoden

Analog zu den Speicherallokationen können die Ausführungszeiten – genauer der Anteil der Ausführungszeit einzelner Methoden an der Gesamt-Ausführungszeit der App – analysiert werden. Effizienter Code für Android Apps wie Spiele ist zum Einen essentiell für eine akzeptable Frame-Rate und zum Anderen für die Optimierung des Batterieverbrauchs. Wer schon mal Angry Birds gespielt und danach Kopfschüttelnd zum Ladekabel gegriffen hat, kann das sicher nachvollziehen.

Die Infos zu Ausführungszeiten schreibt Emulator / Device auf die SD-Card. Daher muss das “AndroidManifest.xml” die entsprechende Permission anfordern:

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

Um die Analyse durchzuführen zunächst die Schritte 1 – 4 von oben wie bei Memory Allocations ausführen, dann

5. “Start Method Profiling” Icon-Button klicken

6. Warten bis genug Daten gesammelt sind (ein paar Frames in meinem Spiel)
7. “Stop Method Profiling” Icon-Button klicken
8. Trace-File vom Emulator / Device herunterladen

9. Trace-File mittels Trace-View-Tool des Android SDK (liegt bei mir unter “D:\java\android-sdk-windows\tools\traceview.bat”) öffnen. Optimalerwise verknüpft Ihr die Endung “.trace” mit dem Trace-View-Tool in Windows. Dann sieht das Ergebnis in Trace-View wie folgt aus:

10. Die Prozent-Angaben der Spalte “Incl %” waren für mich relevant. In welchen, möglichst tief in der Aufrufhierarchie liegenden Methoden, wird sehr viel Zeit verbraucht? In einem ersten Schritt habe ich TreeMaps durch eine eigene Implementierung ersetzt, die für meine Zwecke effizienter ist. Ohne diese Analyse mit Trace-View fällt die Identifikation der optimierungsrelevanten Stellen schwer.

Fazit

Optimiert Eure Apps nicht ins Blaue hinein. Aufwand und Nutzen müssen in gesundem Verhältnis stehen. Mit den oben beschrieben Ansätzen lassen sich schnell Stellen für Optimierungspotential finden. Mindestens genauso wichtig ist die Erfolgsprüfung Eurer Optimierungsmaßnahmen und die Nachhaltung über automatisierte Tests.

In meiner Tower Defense App durchläuft der Benutzer drei Activities: WelcomeActivity, WorldSelectActivity und WorldActivity = Spielen. Die Klassenhierarchie wie folgt:

Die im folgenden beschriebenen Methoden sind Bestandteil des Layer-Supertypes AbstractActivity. Der Nutzer drückt “quit” im Menu der WorldActivity, dann soll die aktuelle und alle vorher aufgerufenen Activities der App beendet werden.

  public boolean onOptionsItemSelected(final MenuItem _item) {
    switch (_item.getItemId()) {
      case R.id.menuEntryQuit:
        quitApp();
        return true;
      default:
    }
 
    return super.onOptionsItemSelected(_item);
  }

Beim Beenden der Activity muss ein entsprechender Result-Code gesetzt werden, …

  protected void quitApp() {
    setResult(RESULT_QUIT_APP);
    finish();
  }

…damit die aufrufende Activity das Beenden der App erkennt und sich ebenfalls beendet.

  protected void onActivityResult(final int _requestCode,
      final int _resultCode, final Intent _data) {
    if (_resultCode == RESULT_QUIT_APP) {
      quitApp();
    } else {
      super.onActivityResult(_requestCode, _resultCode, _data);
    }
  }

Obwohl die aufrufende Activity kein echtes Ergebnis der Folge-Activity erwartet, muss es die folgende Actvity in Erwartung eines Ergebnisses starten um das Result-Ergebnis RESULT_QUIT_APP über onActivityResult zu erhalten:

startActivityForResult(intent, REQUEST_WORLD);

Drückt also der Nutzer “quit” so beenden sich alle Activities im Stack der App. Dieser Blog-Post zerstört sich im Übrigen auch in 10 Sekunden selbst

1. Dump erzeugen auf altem Subversion-Repository

svnadmin dump /pfad/deines/subversion/repositories | gzip >svn.dmp.gz

2. Dump auf neuen Server kopieren

scp svn.dmp.gz du@deinserver.de:.

3.  Neues Subversion Repository anlegen und Dump einspielen

1. cd /pfad/zum/parent-verzeichnis/des/neuen/repositories (z.B. /var/svn)

2. svnadmin create repository-name

3. gzip -cd svn.dmp.gz |  svnadmin load repository-name

Wenn Du Subversion über Apache betreibst, solltest Du die Befehle unter (3) als User www-data ausführen (su www-data). Danach:

chown -R www-data:subversion /pfad/zum/neuen/repository

Für mich ist es sinnvoll, die WSDL-Dateien des anzusprechenden Services direkt in “src/wsdl” meines Projekts abzulegen statt diese über eine URL einzubinden. Dies hat den Vorteil, dass ich Änderungen an der Schnittstelle des Service in der Subversion-Historie nachvollziehen kann. Muss mein Projekt mehrere Service ansprechen, so lege ich die WSDL- plus die Schema-Datei (XSD) jedes Service im genannten Verzeichnis ab.

Ich verwende pro Service im Client-Projekt eine JAXB-Binding-Datei um ein Mapping von Datentypen der Service-Schnittstelle auf bestehende Java-Klassen zu definieren. Diese Binding-XML-Dateien liegen per Default des JAXWS-Plugins im Verzeichnis “src/jaxws”. So sieht zum Bsp eine solche Mapping-Datei bei mir aus:

<?xml version="1.0"?>
<jxb:bindings version="1.0" xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">
 
  <jxb:bindings schemaLocation="../wsdl/Service1_schema1.xsd" node="/xs:schema">
    <jxb:bindings node="//xs:complexType[@name='type1']">
      <jxb:class ref="com.corp.package.Type1" />
    </jxb:bindings>
    <jxb:bindings node="//xs:complexType[@name='type2']">
      <jxb:class ref="com.corp.package.Type2" />
    </jxb:bindings>
    <jxb:bindings node="//xs:simpleType[@name='typeEnum']">
      <jxb:typesafeEnumClass ref="com.corp.package.TypeEnum" />
    </jxb:bindings>
  </jxb:bindings>
 
</jxb:bindings>

Ist in der pom.xml das JAX-WS-Plugin ohne zusätzliche Einstellungen (also Defaults) für “wsimport” eingebunden, so gibt es den folgenden Fehler:

[ERROR] "file:/[...]_schema1.xsd" is not a part of this compilation.
Is this a mistake for "file:/[...]Service_schema1.xsd"?
  line 5 of file:/[...]bindings_[...].xml

Um diesen Fehler zu vermeiden, muss Maven das JAX-WS-Plugin für jede WSDL-Datei getrennt in Verbindung mit der richtigen JAXB-Binding-Datei aufrufen.

Dies kann in der pom.xml durch Konfiguration nach folgendem Schema erreicht werden:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>jaxws-maven-plugin</artifactId>
  <version>1.11</version>
  <executions>
    <execution>
      <id>wsimport Service1</id>
      <goals>
        <goal>wsimport</goal>
      </goals>
      <configuration>
        <staleFile>${project.build.directory}/jaxws/stale/wsdl.Service1.done</staleFile>
        <packageName>com.corp.package1</packageName>
        <wsdlFiles>
          <wsdlFile>Service1.wsdl</wsdlFile>
        </wsdlFiles>
        <bindingFiles>
          <bindingFile>bindings_service1.xml</bindingFile>
        </bindingFiles>
      </configuration>
    </execution>
    <execution>
      <id>wsimport Service2</id>
      <goals>
        <goal>wsimport</goal>
      </goals>
      <configuration>
        <staleFile>${project.build.directory}/jaxws/stale/wsdl.Service2.done</staleFile>
        <packageName>com.corp.package2</packageName>
        <wsdlFiles>
          <wsdlFile>Service2.wsdl</wsdlFile>
        </wsdlFiles>
        <bindingFiles>
          <bindingFile>bindings_service2.xml</bindingFile>
        </bindingFiles>
      </configuration>
    </execution>
  </executions>
</plugin>

Die Java-Klassen für den WebService-Client liegen dann unter “target/jaxws/import”. Ich hoffe mit diesen Zeilen kann ich wieder ein paar armen Seelen helfen, Aspirin zu sparen.

Explodierte Verzeichnisstruktur

Für alle Schnell-Checker: So sieht das Verzeichnis-Layout meiner Beispiel-Applikation aus:

Explodierte EAR-Verzeichnisstruktur für Glassfish

Der Deskriptor “application.xml” des EAR sieht wie folgt aus:

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://java.sun.com/xml/ns/javaee" xmlns:application="http://java.sun.com/xml/ns/javaee/application_5.xsd"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd"
    version="5">
    <display-name>codis vc</display-name>
    <module>
        <ejb>jboss-seam-2.1.0.SP1.jar</ejb>
    </module>
    <module>
        <ejb>codis_base.jar</ejb>
    </module>
    <module>
        <ejb>vc_core.jar</ejb>
    </module>
    <module>
        <ejb>vc_business.jar</ejb>
    </module>
    <module>
        <web>
            <web-uri>vc_web.war</web-uri>
            <context-root>vc</context-root>
        </web>
    </module>
    <library-directory>/lib</library-directory>
</application>

Wichtig ist, dass alle Module des EAR explodiert vorliegen. Ein Mischbetrieb von explodierten und verpackten Modulen innerhalb einer Applikation wird von Glassfish V2 nicht unterstützt. Daher muss auch das verwendete Seam-Framework, welches als EJB-Modul einzubinden ist, entpackt vorliegen. Dies ist zum Beispiel in JBoss 4.2.2 anders.

Die Verzeichnisnamen der explodierten EAR-Module sind die URIs aus “application.xml” mit dem Unterschied, dass Glassfish statt “.jar” den Suffix “_jar” bzw. statt “.war” den Suffix “_war” voraussetzt.

Diese Besonderheiten sind sicherlich ein Grund, warum das Glassfish-Plugin für Eclipse WTP aktuell kein Deployment von explodierten EARs unterstützt.

Exploded JARs innerhalb des EAR-Verzeichnis

Zur Strukturierung der Applikation ist die Aufteilung in mehrere Softwareprojekte notwendig, die jeweils ein Artefakt (JAR bzw. WAR) erzeugen. Durch diese Unterteilung werden Abhängigkeiten innerhalb des Systems über die Projektabhängigkeiten schon grob eingeschränkt.

Um JAR-Dateien auch explodiert innerhalb des EAR deployen zu können, müssen diese als Module im Deskriptor “application.xml” definiert werden. Bisher habe ich keine andere elegante Möglichkeit gefunden. Möglich wäre noch die Angabe von Classpath-Referenzen auf die JAR-Verzeichnisse mittels “META-INF/manifest.mf” in den EAR-Modulen, welche die JARs benötigen.

Module die in “application.xml” als JAR definiert werden, sind nach JEE-Spezifikation die Application Clients. Dies kann zum Beispiel eine Swing-Anwendung sein, die als Client fungiert. Im EAR-Deskriptor sieht ein JAR-Modul wie folgt aus:

<module>
  <java>vc_core.jar</java>
</module>

Glassfish versucht diese JAR-Module per Java WebStart bereitzustellen. Dabei prüft der Glassfish Deployer die Datei “META-INF/MANIFEST.MF” auf den Eintrag “Main-class”. Dieser Eintrag muss den vollqualifizierte Klassenname der Startklasse enthalten, für welche die main-Methode aufgerufen wird. Ist dieser Eintrag nicht vorhanden, so meldet Glassfish eine Warnung:

[#|2008-11-16T08:50:38.859+0100|WARNING|sun-appserver9.1|javax.enterprise.system.tools.deployment|
_ThreadID=15;_ThreadName=Timer-40;vc_business.jar;_RequestID=5
16b05a8-8e7f-4bd9-a448-ea5184b4280e;|App client vc_business.jar did not specify
Main-Class in its manifest as described in the Java EE specification;
no annotations in this app client will be processed|#]

Kurz danach wirft Glassfish eine Exceptions ins "server.log":

[#|2008-11-16T08:50:41.187+0100|SEVERE|sun-appserver9.1|javax.enterprise.system|
_ThreadID=15;_ThreadName=Timer-40;_RequestID=516b05a8-8e7f-4bd9-a448-ea5184b4280
e;|Error updating Java Web Start information for application vc_app
java.lang.NullPointerException
        at com.sun.enterprise.appclient.jws.AppclientJWSSupportInfo.prepareApplication(AppclientJWSSupportInfo.java:1221)
        at com.sun.enterprise.appclient.jws.AppclientJWSSupportInfo.startJWSServicesForApplication(AppclientJWSSupportInfo.java:475)
        at com.sun.enterprise.appclient.jws.AppclientJWSSupportManager.handleApplicationEvent(AppclientJWSSupportManager.java:156)

Das ist unschön, trotzdem ist das JAR-Modul deployt. Andere Module im EAR können auf die Klassen des JAR-Modules zugreifen.

Um den obigen Fehler im Log zu vermeiden, verwende ich statt dessen EJB-Module, obwohl ich aktuell gar keine EJBs sondern ausschließlich Seam-Beans verwende. Lediglich ein Dummy-EJB muss in jedem EJB-Modul enthalten sein, sonst beschwert sich Glassfish () und deployt das EJB-Modul nicht.

Damit ist für mich das Thema exploded Deployment in Glassfish V2 gelöst. Bleibt nur zu hoffen, dass folgende JEE-Spezifikationen das explodierte Deployment endlich standardisieren. Für die effiziente Entwicklung von JEE-Applikationen ist das aus meiner Sicht absolut notwendig.

Re-Deployment vermeiden

Einige Änderungen im Code benötigen gar kein Re-Deployment.

Einfache Änderungen im Java-Code lassen sich direkt über die Debugging-Schnittstelle in den Application Server übertragen. Eclipse muss also per Remote Debugger mit dem Application Server verbunden sein in welchem die JEE-App läuft. Alternativ kann der Application Server auch direkt mittels Eclipse WTP im Debugging-Modus gestartet sein. Aber Vorsicht: Nach dem Neustarten des Servers sind die Änderungen wieder weg, da die Class-Dateien des Deployments geladen werden.

Einfache Änderungen beziehen sich auf das Verändern von Methodenblöcken (Method Body). Wichtig für das Funktionieren von Hot Code Replacement in Eclipse ist, dass Auto-Build (Kompilieren) aktiv ist. Wartet der Debugger gerade per Breakpoint in der veränderten Methode, so wird der aktuelle Frame vom Ausführungsstack gepoppt und die Methode wird quasi erneut mit denselben Argumenten aufgerufen.

Das Ändern der Klassensignatur ist nicht mittels Hot Code Replacement (HCR) möglich. Die Klassensignatur ändert sich zum Beispiel durch neue Methoden oder Felder, Umbenennen von Methoden oder Feldern, sowie durch Verändern von Methodensignaturen. Eclipse zeigt in diesem Fall folgendes Meldungsfenster an:

Dann ist in der Regel ein Re-Deployment notwendig. Das Neustarten des Application-Servers dauert länger und sollte vermieden werden.

Re-Deployment beschleunigen

Wenn Hot Code Replace nicht ausreicht, wird also ein Re-Deployment notwendig. Die Code-Änderungen müssen inkrementell kompiliert und dem Application Server bereitgestellt werden. Eclipse kompiliert bereits inkrementell. Warum also eine gesonderte Kompilierung per Ant durchführen? Das kostet Zeit.

Das Kopieren von Class-Dateien in das “explodierte” Deployment-Verzeichnis kostet ebenso Zeit. Praktisch ist die Verwendung von symbolischen Verzeichnislinks im Dateisystem. Entsprechende Verzeichnisse im Deployment-Verzeichnis zeigen auf die Verzeichnisse mit den Class-Dateien in Eclipse.

Folgendes Bild veranschaulicht die Verzeichnislinks bei einem meiner Projekt, welches ein Maven-Setup verwendet (erkennbar an den Verzeichnissen “target/classes”):

Die symbolischen Links werden mittels Ant-Skript und dem freien Windows-Tool Junction angelegt. Folgendes Ant-Fragment kann dabei helfen, dasselbe im eigenen Projekt zu machen:

<target name="_create_symlink" description="Creates a symbolic link">
<fail unless="from.path" />
<fail unless="to.path" />

<!-- junction executable must use absolute path since it operates in a different work directory -->
<property name="to.path.abs" location="${to.path}" />

<dirname file="${from.path}" property="from.path.dir" />
<basename file="${from.path}" property="from.path.name" />

<echo level="info" message="Creating symlink ${from.path} -> ${to.path.abs}" />
<basename file="" property="" />
<exec executable="${project.root.tools.dir}/junction.exe" dir="${from.path.dir}" failonerror="true">
  <arg value="${from.path.name}" />
  <arg value="${to.path.abs}" />
</exec>
<echo file="${from.path}_readme.txt">
  ${symlink.src.name} represents a symbolic link and it is not intended to be handled like a normal directory.
  Under Windows use the junction.exe tool to manage it!
</echo>
</target>

<target name="_del_symlink" description="Deletes a symbolic link">
<fail unless="from.path" />

<dirname file="${from.path}" property="from.path.dir" />
<basename file="${from.path}" property="from.path.name" />

<echo level="info" message="Deleting symlink ${from.path}" />
<exec executable="${project.root.tools.dir}/junction.exe" dir="${from.path.dir}">
  <arg value="-d" />
  <arg value="${from.path.name}" />
</exec>
<delete file="${from.path}_readme.txt" failonerror="false" />
</target>

In einem meiner Projekte (Großprojekt, JEE, Automotive) haben wir sehr viele Klassen explodiert deployt (aktuell 7299). Man kann sich Vorstellen wie viel Zeit täglich durch den Wegfall des Kopierens beim Re-Deployment gespart wird.

Re-Deployment anstossen

Nachdem die neuen Class-Dateien jetzt im Deployment-Verzeichnis bereit stehen, kann re-deployt werden. Der Application Server stoppt und entlädt die JEE-App. Dabei werden geladene Class-Dateien freigegeben. Anschließend wird die JEE-App wieder geladen und gestartet.

Das Anstoßen eines Re-Deployments ist abhängig vom Application Server. Unter JBoss funktioniert dies einfach über das Verändern des Deployment-Deskriptors. Für ein EAR-Deployment muss der Deskriptor “META-INF/application.xml” modifiziert werden. Dies lässt sich mit Ant wie folgt realisieren:

<touch file="${deploy.ear.exploded.dir}/META-INF/application.xml"/>

Unter BEA Weblogic 8 können die Weblogic Admin Tools in Ant verwendet werden:

<java classname="weblogic.Deployer" fork="true">
  <classpath>
    <pathelement location="${weblogic.lib.dir}/weblogic.jar"/>
  </classpath>

  <!-- options -->
  <arg value="-adminurl"/>
  <arg value="${domain.admin.url}"/>
  <arg value="-username"/>
  <arg value="${domain.admin.user}"/>
  <arg value="-password"/>
  <arg value="${domain.admin.pwd}"/>
  <arg value="-name"/>
  <arg value="${domain.deployment.packaged.name}"/>
  <arg value="-targets"/>
  <arg value="${domain.deployment.exploded.business.name}@${domain.deployment.target}"/>
  <arg value="-verbose"/>

  <!-- action -->
  <arg value="-redeploy"/>
</java>

Ich hoffe Eure Entwicklungsumgebung ist so schnell wie meine. Ja? Dann können wir mal um die Wette coden…