GAE mit Maven, JSF und Spring – Teil 1


Tjo, mittlerweile ist der Hype um die Google App Engine schon wieder verflogen. Grund genug mich damit auseinanderzusetzen! Wenn das keinen Sinn ergibt ist das ok so, denn eigentlich spiele ich schon lange mit dem Gedanken mich mit der GAE zu beschäftigen. In Ermangelung des richtigen Projekts, zu vieler richtiger Projekte und zu vieler anderer Projekte, habe ich das aber immer wieder nach hinten verschoben. Bis heute! Denn ich brauche ein kleines Webinterface für eine Java Bibliothek die ich im Sinn habe. Und woher einen Servletcontainer nehmen wenn nicht stehlen? Nun z.B. über die Google App Engine.

Da ich auch meine Erfahrungen mit Spring weiter vertiefen möchte, bietet sich hierfür nun eine Kombination dieser beiden Technologien an. Damit das ganze dann auch noch hübsch aussieht möchte ich ich das ganze um eine gehobene JSF GUI Bibliothek erweitern: PrimeFaces. In dieser Riehe von Blogposts möchte ich nun dokumentieren welche Schritte notwendig waren um die berühmtesten Worte der Software-Development-Geschichte auf die Google App Engine unter Einsatz dieser Technologien zu zaubern: Hello World!

Und wo kämen wir hin wenn wir nicht die Abhängigkeiten sauber verwalten würden? Maven muss her! Als ran ans eingemachte: http://lmgtfy.com/?q=spring+maven+primefaces+google+app+engine

HALT!

Unsere BaugrubeWir wollen ja dabei eigentlich was lernen und nicht Fehler in irgendwelchen Blogeinträgen nachrennen, die die Hälfte von dem, was sie machen, auch erklären. (Daran sind frühere schnelle GAE Versuche mit PrimeFaces gescheitert, ich weiß also wovon ich spreche).

In der Hoffnung es mit meiner eigenen Blogreihe besser zu machen solls nun auch gleich losgehen.

Zuerst eine kurze Zusammenfassung der Zielsetzung

Eine Webanwendung unter Einsatz folgender Technologien:

  • Maven als Buildmanagement
  • Google App Engine als Servlet Container, Persistenz Schicht und schlicht zum Hosten
  • Spring als Mörtel zwischen meinen Java Klassen Ziegel
  • PrimeFaces als Verputz, damit das ganze am Schluss auch etwas gleichschaut.

Damit habe ich auch gleich eine gewisse Reihenfolge vorgegeben, wie Schritt für Schritt die Anwendung zusammengebastelt werden soll.

Als Erstes starten wir mit einem simplen Maven-GAE Projekt. Ich arbeite übrigends mit Maven 3.0.4 und der neuesten Version von Java 1.7

Damit sich Maven und die GAE gut vertragen nutzt man das maven-gae-plugin, auf Google Code bzw. Github, welches zum Zeitpunkt dieses Blogeintrags in der Version 0.9.4 vorliegt.

Damit erzeugen wir uns ein ganz frisches Maven Projekt:

mvn archetype:create\
-DarchetypeGroupId=net.kindleit\
-DarchetypeArtifactId=gae-archetype-jsf\
-DarchetypeVersion=0.9.4\
-DgroupId=your.groupId\
-DartifactId=your-artifactId

Danach haben wir ein gut dokumentiertes POM.xml erhalten, welches sich im Grunde selbst erklärt. Daumen hoch für die Entwickler!

Naja fast, es gibt da so ein paar Kleinigkeiten die fehlen, welche bekommen wir gleich angezeigt mittels

$ maven install

Es fehlt die GAE Versionsnummer
${gaeVersion}
sowie die Gae Plugin Versionsnummer
${gaePluginVersion}

Hätte man durchaus ins Template aufnehmen können mit einem „Huhu hier bearbeiten Kommentar!“, dem aufmerksamen Leser stach es beim Betrachten der POM aber bereits ins Auge.
Beide Einträge ersetzen wir durch die von uns genutzte Version, durch setzen eines entsprechenden Properties

Für die Properties gibt es bereits einen Eintrag
<gae.version>1.7.3</gae.version>

Für das Plugin schreiben wir selbst ein Property

<!--
Specify the Gae Maven Plugin Version
-->
<gaePluginVersion>0.9.4</gaePluginVersion>

 

Brick Wall in Philadelphia

Will man nun das Projekt erneut zum laufen kriegen bekommt man neben so einigen MegaByte App-Engine-Jar Files auch einen kleinen Stolperstein. (Im Gegensatz zu Version 0.9.2 hat das Plugin einiges dazugelernt und so sind einige Fehlerkorrekturen mit falschen Abhängigkeiten nicht mehr notwendig)

Wie gesagt ein Stolperstein ist noch vorhanden. Das maven-war-plugin meldet sich zu Wort, denn das Template hat zwar das POM erzeugt aber keinerlei Verzeichnisse

Diese sind flott nachgezogen, hier der Aufbau:
src
src/main
src/main/resources
src/main/webapp
src/main/webapp/WEB-INF
src/main/java
src/main/java/your.grouID.artefactId
src/test
src/test/resoruces
src/test/java
src/test/java/your.grouID.artefactId

Wir bekommen nun eindeutig Fahrwasser! Das nächste Problem dass uns ein

$ mvn install

offenbart ist eine fehlende web.xml! Und da drinnen wird schon die Anwendung konfiguriert. Das ist nun der Punkt an dem wir das erste Google App Engine Beispiel auf der Herstellerseite für Maven adaptieren.

Als erstes wird ein Servlet erstellt, dazu legen wir in unserem src/main/java ein entprechendes Java File an (Die Servletklasse des Tutorials)

Als nächstes ergänzen wir das Projekt um die web.xml und hinterlegen diese unter src/main/webapp/WEB-INF, ebenfalls wie im Tutorial

Abschließend noch die Konfigurationsdatei, wie im Tutorial, für die App Engine: appengine-web.xml welche wir ebenfalls unter src/main/webapp/WEB-INF ablegen

So frohlockend wie es nun voranging, so schnell laufen wir auch wieder auf Sand:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.1-bet
a-1:war (default-war) on project wls: Execution default-war of goal org.apache.m
aven.plugins:maven-war-plugin:2.1-beta-1:war failed: Cannot construct org.apache
.maven.plugin.war.util.WebappStructure as it does not have a no-args constructor
: Cannot construct org.apache.maven.plugin.war.util.WebappStructure as it does
not have a no-args constructor

Hier hat uns das das Alter des Templates einen Streich gespielt, da es noch nicht mit Java 7 umgehen kann. Erhöht man die Version des maven-war-plugin auf 2.1.1 hat man auch dieses Problem behoben.

Jetzt sollten wir in der Lage sein das Google App Engine Projekt zum laufen zu kriegen. Zuerst laden wir das SDK in unser Maven Repository

$ mvn gae:unpack

nun noch ein schnelles

mvn gae:run

und es sollte laufen.

Schön wär’s gewesen, würde alles funktionieren. Aber das Tutorial von Google hat in der appengine-web.xml scheinbar einen Punkt übersehen. So ist es wohl mittlerweile notwendig die Konfiguration für die Threadsicherheit zu hinterlegen. Wir holen dies mit

<threadsafe>false</threadsafe>

nach.

Nun nochmal

mvn gae:run

Und unter http://localhost:8080 steht auf einem Jetty Server unser GAE Hallo World bereit! Naja genauer unter http://localhost:8080/guestbook wenn ihr die GettingStarted Dateien eins zu eins übernommen habt.

Win Win Win!

Und im nächsten Blogeintrag werden wir das ganze um JSF erweitern!

Greets!

Ähnliche Artikel:

2 Kommentare

  1. Hi Thomas,
    schöner Eintrag!
    Da ich gerade auch versuche GAE in Verbindung mit primefaces zum Laufen zu bringen würde ich mich riesig auf Teil 2 freuen… ich scheiter im Moment wohl genauso wie du in deinen „frühen, schnellen Versuchen“. ;)
    Ich schätze du kamst noch nicht zum nächsten Anlauf? In jedem Fall freue ich mich mehr von dir darüber zu lesen ;)

    1. Danke und ja, du hast mich ertappt, den nächsten Beitrag bin ich noch schuldig. :)
      Ich hab sogar schon so einige Stunden in die weiteren Beiträge investiert, aber so richtig glücklich war ich mit den Ergebnissen nicht. Vorallem die JSF Integration mit der GAE hat einige Restriktionen die ich damals nur mit dirty Hacks halbherzig lösen konnte. Vielleicht nehme ich mit dem aber nochmal an.
      Schöne Grüße!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*