Hinweis:
Die hier beschriebene Speicherverwaltung lässt sich erst ab der Tomcat Version 5.5.15 realisieren und konzentriert sich auf die Linux-Architektur!

Auch wenn Tomcat einige gewisse Schwierigkeiten mit dem Umgang von großen JavaServer Pages mit sich bringt, so hilft der Kniff des Mitteilens, wieviel Arbeitsspeicher Ihr Server besitzt. Solche Angaben werden mit Hilfe der Variable CATALINA_OPT realisiert, die sich optional mit starten von Tomcat einbinden lässt. Dazu ist im Vorfeld eine Datei anzupassen. Sollte diese noch nicht vorhanden sein, erstellen Sie diese bitte:

$CATALINA_HOME/bin/setenv.sh

Neben anderen optionalen Parametern, auf die in diesem Beitrag aber kein Bezug genommen wird, soll es im folgendem um das Setzen der Variable für die Verwaltung des Arbeitsspeichers gehen. Der Inhalt dieser Datei, wird unter Linux wie folgt befüllt:

export CATALINA_OPTS="$CATALINA_OPTS -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -Xms256m -Xmx2048m -XX:MaxPermSize=512m

Zunächst dient die Angabe von org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER für die Möglichkeit der Verwaltung des Arbeitsspeicher. Diese ist hierzu auf true zu setzen und steht erst ab der Tomcat-Version 5.5.15 zur Verfügung. Die nachfolgenden Attribute sind wie folgt zu verstehen:

-Xms256m (Mininum des Java Heap)
-Xmx2048m (Maximum des Java Heap)
-XX:MaxPermSize=512m (Permanent Generations Größe)

Die Angabe von -Xmx2048m verrät die Größe des RAMs. Stellen Sie diesen unter Linux zwingend auf den maximal zulässigen Arbeitsspeicher. Warum?, dies ist auf die Linux-Architektur zurück zu führen, welche den Arbeitsspeicher permanent und vollständig im Gebrauch hält. Sollte Tomcat nun nicht wissen, wieviel Arbeitsspeicher insgesamt zur Verfügung steht, wird er diesen auch nicht „beantragen”. Ist der Arbeitsspeicher zu diesem Zeitpunkt aber voll, so kann es zu merklichen Performance-Verlusten führen, da Tomcat selbst keinen freien Speicher findet. Linux bedient sich in diesem Fall des Auslagerns (SWAP). Wenn Tomcat weiß wieviel Arbeitsspeicher Sie wirklich besitzen, so wird bei Bedarf versucht, diesen auch zu allokieren. Der Linux-Kernel weiß nun das er viel zu viel Arbeitsspeicher hält und wird alte Daten Auslagern und Tomcat den RAM zusichern der gebraucht wird.

Mit einem Start oder Neustart von Tomcat wird die so eben angelegte, beziehungsweise angepasste Datei aufgerufen und Tomcat mit den entsprechenden Einstellungen gesetzt.

1. http://tomcat.apache.org/

update-alternatives --config java

Verständlicherweise ist dies nur möglich wenn mehr als eine Java-Runtime installiert ist. Dies ist oft der Fall. Besonders bei der Server Edition¹ von Ubuntu wird von haus aus nur die GIJ (GNU Interpreter for Java) mitgeliefert. Welche sich dadurch auszeichnet, das sich diese Runtime für fast nichts tiefgründigeres einsetzen lässt. Hintergrund ist die Lizenzvereinbarung von Sun Microsystems. Durch die abgespeckte Version ist eine Bestätigung durch den Anwender nicht notwendig. Im gegensatz zu der vollwärtigen Runtime die auf jedem Linux-Betriebsystem nachinstalliert werden kann.

Mit dem oben genannten Befehl lässt sich nun eine Standard Runtime definieren die sich mittelst einer textbasierte GUI präsentiert:

Mit dieser Methodik lassen sich viele Fehler bezüglich der Java Runtime schon im Vorfeld vermeiden, in dem keine abgespeckte, sondern vollwertige Runtime genutzt wird. Oft entfallen damit auch spezielle Konfigurationen am Server. Der folgende Befehlt gibt letztendlich Aufschluss ob nun standardmäßig die richtige Runtime genutzt wird.

java -version

1. Ubuntu Server Edition - http://www.ubuntu.com/products/whatIsubuntu/serveredition

Vor einigen Jahren entwickelte ich an einer Umsetzung für die Hamming-Distanz im Bezug auf Hypercubes¹. Im Grunde geht es darum, Körper verschiedener Dimensionen zu projektieren. Worauf ich nun sehr stolz bin, ist die Tatsache das es damals diesen Algorithmus nur im Ansatz gab und sonst auch im Netz keine weiteren Erläuterungen zu finden waren. So habe ich, auf der Grundlage der Hamming-Distanz, einen Algorithmus entworfen welcher n-dimensionale Hyperwürfel zeichnen kann.

Meine Inspiration kam von Hans Walser und seinem gleichnamigen Script². Darin wird Schritt für Schritt der Aufbau erläutert und ein Ansatz für das projektieren dieser Körper beschrieben. Das Script ist zwar von 2003 aber dennoch sehr empfehlenswert. Ich habe es aber nun auch einmal ausgelassen eine 10. oder gar höhere Dimension als Bild mit einzubinden. Würfel höherer Dimensionen entnehmt Ihr dem Script auf der Seite 15. Dort werden die Dimensionen fünf bis acht grafisch dargestellt. Das Thema ist wirklich interessant, nur leider gibt es mir keine bekannte Vertiefungsmöglichkeit. Von daher war die Umsetzung eine schöne Herausforderung und das Resultat ein Blick in eine andere Dimension.

1. http://de.wikipedia.org/wiki/Hyperw%C3%BCrfel
2. http://www.math.unibas.ch/~walser/Vortraege/Vortrag39/Skript/Hyperwuerfel.pdf

Bei einem Blick hinter die Kulissen fällt sofort die neue Unterstützung für die MacOS X - Version Cocoa auf. Hier wird nun der Support für die x86- und x64-Architektur bereitgestellt, was einiges wieder sehr einfach machen wird. Experimentell wurde (erst) zum Release die s390-Architektur eingeführt. Dabei handelt es sich um eine weitere Linux-Architektur von IBM. Mittlerweile die zweite die auch von Java unterstützt wird.

Nach einem ersten Start fällt das viel schnellere Laden der Plattform auf. Dies ist einem überabeiteten Backend zu verdanken. Bei einem Update oder Installation eines zusätzlichen Plugins fällt ebenfalls die neue Routine und neuen Views auf. Hier wurde ordentlich optimiert. Dabei wurden die durchzuklickenden Dialoge reduziert. Ebenfalls wird bei der Installation von neuen Plug-ins angezeigt welche Plug-ins noch installiert werden müssen.

Mit Eclipse 3.5 kommen neben den Features für das Auge und der Steuerung auch einige Bugfixes. So ist es nun endlich möglich einen JUnit 4 Provider für Pluginübergreifende Tests einzusetzen. Durch einen Fehler bis zur Version 3.4.2 war dies leider nicht möglich und man musste sich vorerst mit JUnit 3 zufrieden geben. Diese Thematik ist sicherlich sehr interessant für die Reihe an Third-party Programme, die sich im Bereich Continuous Integration tummeln. Eine mitlerweile doch recht bekannte Plattform dafür ist Tycho.

Für umfassende Informationen der Neuerungen in Eclipse, sollte man die Eclipse 3.5 - New and Noteworthy Seite von Eclipse besuchen. Dort wird aufgezeigt an welchen neuen Errungenschaften in den letzten Monaten gearbeitet wurde.

Weiterführende Informationen:

http://www.golem.de/0906/67975.html
http://www.innenspur.de/?p=259
http://javathreads.de/2009/06/eclipse-galileo-veroeffentlicht/

Zu erst sollte man sich in Eclipse eine RCP-Anwendung¹ generien lassen oder selbst eins erstellen. Da wir später auch die Product-Konfiguration brauchen, wäre es angebracht, sich diese auch gleich bauen zu lassen und nötige Einstellungen zu treffen. Ich habe soweit alles beim Standard belassen und die Product-Datei „com.company.project.product” genannt. Wenn man die nötigen Konfigurationen für das Produkt getroffen hat lässt sich diese bereits in Eclipse über „Overview -> Launch an Eclipse application” ausführen.

Ich möchte an dieser Stelle nicht tiefer in der RCP-Entwicklung eingehen da dies ein Thema für sich ist. Wer allerdings damit nicht so zurecht kommt, sollte sich noch etwas in die RCP-Entwicklung² einlesen.

Nun erstellen wir uns eine pom.xml mit folgendem Inhalt:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.company.project</groupId>
  <artifactId>com.company.project</artifactId>
  <packaging>zip</packaging>
  <name>Project Name</name></code><code>
  <version>1.0-SNAPSHOT</version>
  ...
</project>

Unsere Anwendung heißt hier: com.company.project. Das Haupt-Plugin analog genauso: com.company.project. Es gilt nun den Inhalt ab Zeile 8 zu füllen. Da wir einen Buildprozess für eine RCP-Anwendung erstellen wollen schauen wir uns zu erst auf der Seite http://mojo.codehaus.org/pde-maven-plugin/index.html um. Dies kommt dem am nächsten was wir machen wollen. Unter Usage haben wir eine wunderbare Beschreibung wie der Konstrukt auszusehen hat:

<project>
  ...
  <packaging>zip</packaging>
  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>pde-maven-plugin</artifactId>
        <extensions>true</extensions>
        <configuration>
          <buildProperties>
          <!-- Additional PDE ant properies goes here -->
          ...
          </buildProperties>
        </configuration>
        <!-- Also bind to mvn clean -->
        <executions>
          <execution>
            <id>clean-pde</id>
            <phase>clean</phase>
            <goals>
              <goal>clean</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
  ...
</project>

Ab nun an wird es etwas knifflig. Man sollte die PDE-Version explizit angeben. Aktuell ist die Version: „1.0-SNAPSHOT”. Dies muss im besten fall unter extensions als version - Tag hinzugefügt werden. Nicht benötigte Inhalte, speziell die Kommentare haben in solch einer Konfiguration natürlich nichts verloren. Also ebenfalls raus damit. Sind diese Dinge abgearbeitet kann sich diese pom-Konfiguration schon sehen lassen. Damit ist zumindest der Grundstein gelegt. Im nächsten Teil der Storyline werden wir uns mit dem Product-Build beschäftigen und unsere erstellte Mail-Application automatisch erstellen lassen.

Weiterführend ist zu sagen, das mit dem PDE-Maven-Plugin sich nicht nur Product, sondern auch Plugins, Features und auch Updatesite automatisch builden lassen. Allerdings ist jeder dieser Bereiche ein Thema für sich und sollten trotz der einfachen Handhabung nicht unterschätzt werden. Persönlich schätze ich den Product-Build als schwierigsten ein.

1. Optional das HelloWorld-Mail RCP
2. http://wiki.eclipse.org/index.php/Rich_Client_Platform

Möchte man von haus aus mit der Maven-Konvention arbeiten, so bietet es sich an, unter Eclipse zu arbeiten und zusätzlich das Maven-Plugin¹ zu nutzen. (Es steht selbstverständlich auch ein gleichnamiges Netbeans-Plugin² zur Verfügung) Hat man dies in seiner Eclipse-Version integriert hat man die Möglichkeit, gleich ein neues Maven-Projekt anzulegen.

Nun ist es aber so, das über Eclipse hinaus, es Zusatzpakete gibt die zum Beispiel sehr viel Code für einen generieren und diese logischerweise die Java-Konvention verwenden. Hier greift das Sprichwort „Never change a running system” und man muss umdenken. In diesem Fall weisen wir dem jeweiligen Hauptprojekt eine „pom.xml” zu. Genauer gesagt, wir erstellen uns diese Datei. Macht man dies nun in Eclipse, erkennt er dies und der Designer öffnet sich. Persönlich mag ich Designer lieber als sich mit dem Quelltexten rumzuschlagen, aber in diesem Fall sollte man eine Ausnahme machen, die „pom.xml” per Hand beschreiben und später lieber die Anpassungen über den Designer erledigen.

Aufbau einer Standart pom.xml:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.company.projectr</groupId>
  <artifactId>com.company.project.application</artifactId>
  <packaging>zip</packaging>
  <name>Project Name</name>
  <version>1.0-SNAPSHOT</version>
</project>

Um den Aufbau etwas einfacher zu halten ist hier kein Doctype definiert. Dieser müßte in der ersten Zeile vollständig lauten:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

Hieraus lässt sich schon eine funktionstüchtige pom-Konfiguration erkennen. Der modelVersion-Tag beschreibt die POM-Version. Zum aktuellen Zeitpunkt wo dieser Beitrag verfasst wurde ist die Version 4.0.0 aktuell. Der groupID-Tag definiert quasi den Projektnamen. Es bietet sich hier an den root-Path zu seinem Projekt zu definieren. Allerdings wäre hier auch ein richtiger Projektname möglich, obwohl sich das in der Praxis dann nicht so gut macht. Wie sich erahnen lässt, beschreibt der artifactId-Tag den Projektnamen. In der RCP-Entwicklung wäre dies, der vollständige Name des Plugins. Der packaging-Tag definiert das Zielformat, wie das Projekt am Ende gepackt wird. Hier wäre es möglich ear, war, jar oder wie in unserem Beispiel das zip-Format anzugeben. Der name-Tag ist sicher selbsterklärend. Dieser beschreibt, wie das Projekt heißt. Zum Schluss gibt es noch ein version-Tag. Wie der Name schon sagt, definiert man hier seine Version. SNAPSHOT bedeutet in diesem Fall, das die Version, sollte sie in einem Repository installiert oder ausgelifert werden, es sich dabei um keine Release-Version handelt und ggf. im laufe der Zeit in seinen Funktionen noch geändert werden kann.

1. http://m2eclipse.codehaus.org/
2. http://maven.apache.org/netbeans-module.html

Wer seinen Buildprozess² automatisieren möchte sollte sich damit vertraut machen. So ein Maven-Projekt bringt von haus aus eine eigene Konventionen mit sich die man nach Möglichkeit auch nutzen sollte. Aber auch für Projekte die Technisch an eine bestimmte Struktur gebunden sind, gibt es Lösungsansätze. Eines sollte man über Maven wissen und sich auch immer im klaren sein, es gibt keinen Standard. Wie ein Build Lifecycle aussehen sollte, richtet sich immer nach den Projekt(en).

Maven bietet aber ein Standard Buildprozess aus folgenden Plugin an:

1. clean (Säubern)
2. validate (Validieren)
3. compile (Kompilieren)
4. test (Testen)
5. package (Verpacken)
6. integration-test (Integrations-Tests)
7. verify (Gültigkeitsprüfung)
8. install (Installieren im lokalen Repository)
9. deploy (Installieren im entfernten Repository)
10. site (Generierung der Dokumentation)

Jede Phase stellt ein Plugin dar und übernimmt verschiedene Aufgaben und definiert letztendlich den Buildprozess. Im folgenden die einzelnen Schritte im Detail:

1. Entfernt Artefakte³ von vorherigen Builds
2. Validiert⁴ das Projekt auf Korrektheit und prüft ob alle Abhängigkeiten⁵ gegeben sind
3. Kompiliert den Programmcode
4. Testet den kompilierten Programmcode mit Hilfe eines unit-testing-framework⁶. Diese Tests sollten nicht verlangen, dass der Code gepackt (packaged) oder ausgeliefert (deployed) sein muss.
5. Fasst den kompilierten Code in einem bestimmten Format zusammen, z.b. zu einer jar.
6. Integrationstests auf anderen Systemen. Es wird dabei getestet ob das Projekt auf dem Zielsystem funktionstüchtig ist.
7. Hier können sonstige Tests angestoßen werden die prüfen ob das Projekt gültig und ggf. bestimmte Qualitätskriterien erfüllt sind.
8. Installiert das Package in das lokale Repository⁷, worauf lokale Projekte in Abhängigkeit dies nutzen können.
9. Installiert das Package in ein entferntes Repository. Dies wird verwendet um stabile Versionen anderen Programmierern zu verfügung zu stellen.
10. Erstellt eine Projekt-Dokumentation. Ebenfalls ist es hier möglich JavaDocs oder Code-Duplicates anzeigen zu lassen.

Es ist für den Anfang sicher etwas viel. Wenn man sich aber etwas eingelesen hat und langsam dahinter steigt, lässt sich daraus eine Menge machen. Und darum geht es in dieser Storyline, einen automatischen Buildprozess aufzubauen.

1. http://maven.apache.org/
2. http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
3. Artefakte sind beispielsweise jar- oder zip-Pakete die durch das kompilieren erstellt werden können. Diese sind zu meist mit einer Versionierung versehen. Diese Artefakte können von anderen Projekten in Abhängigkeit genutzt und eingesetzt werden.
4. Damit prüft das Plugin durch ob im Programmcode Fehler enthaten sind. Das beste Beispiel dafür sind Errors.
5. Projekte greifen i.d.R. auf andere Resourcen zu und damit wird geprüft ob diese vorhanden sind.
6. Ein bekanntes Framework ist JUnit: http://www.junit.org/
7. Stellt ein Verzeichnis da, wo sämtliche Maven und hauseigenen Projekte verwaltet und genutzt werden können