next-lvl-jee

Begleitprojekte zum Vortrag "Migration von JEE-Anwendungen auf Quarkus"

Im Verzeichnis std-jee liegt eine kleine Beispiel-Anwendung für ein klassisches JEE-Deployment als war-File. Der Zielserver benötigt eine Datasource mit dem JNDI-Namen java:/jdbc/showcase.

Im Folgenden wird eine PostgreSQL-DB genutzt, die mit dem Script scripts/postgres.sh als Docker-Container gestartet werden kann.

In std-jee/pom.xml ist das wildfly-jar-maven-plugin eingetragen, mit dessen Hilfe ein passend konfigurierter WildFly als sog. Bootable JAR bereitgestellt wird. Darin kann die Anwendung dann hochgefahren werden:

mvn clean package wildfly-jar:package
java -jar target/wildfly-bootable.jar --deployments=target/std-jee.war

Im Verzeichnis quarkus wird im Vortrag eine äquivalente Anwendung auf Basis von Quarkus aufgebaut, und zwar mit den folgenden Schritten:

1. Bootstrap des Projekts, Prod Mode, Dev Mode

   siehe Skript scripts/bootstrap.sh

   1. Build mit mvn package

   2. Normaler Start mit java -jar target/quarkus-app/quarkus-run.jar

      Stopp mit Ctrl-C

   3. Dev mode starten mit mvn quarkus:dev

      REST Call curl localhost:8080/hello

      Quellcode (z. B. von GreetingResource) ändern und erneuten REST Call ausführen

      Stopp mit q

2. Verwaltung von Personen ergänzen (JPA, REST)

   1. Extension für JPA, Hibernate und PostgreSQL ergänzen

      siehe Skript scripts/add-extensions.sh.

      Wir verwenden Lombok zum Erzeugen von Gettern, Settern etc. Dazu muss die entsprechende Dependency in pom.xml hinzugefügt werden - s. sniplets/lombok.txt.

      Wir lassen die DB-Tabellen automatisch erzeugen. Dazu bitte in src/main/resources/application.properties diese Zeile eintragen:

      quarkus.hibernate-orm.database.generation=update

      Es kann auch schon die gesamte Datei aus scripts übernommen werden. Die anderen Einstellungen sind aber (noch)´ nicht wichtig.

   2. Klassen (unverändert) übernehmen:

      • de.gedoplan.showcase.domain.Person

      • de.gedoplan.showcase.persistence.PersonRepository

      • de.gedoplan.showcase.service.PersonService

      • de.gedoplan.showcase.rest.PersonResource

      • de.gedoplan.showcase.rest.RestApplication

   3. Anwendung wieder im Dev Mode starten: mvn quarkus:dev.

   4. Einige curl-Aufrufe zum Ausprobieren:

      curl -X POST localhost:8080/api/persons \
        -H 'content-type: application/json' \
        -d '{"name": "Dagobert Duck", "birthDay": "1905-12-05"}'

      curl -X POST localhost:8080/api/persons \
        -H 'content-type: application/json' \
        -d '{"name": "Donald Duck", "birthDay": "1931-03-13"}'

      curl -X POST localhost:8080/api/persons \
        -H 'content-type: application/json' \
        -d '{"name": "Tick Duck", "birthDay": "1940-08-17"}'

      curl localhost:8080/api/persons

      curl localhost:8080/api/persons/avgAge

3. Erstellen von Container Images

   Mit den Scripts scripts/build_jvm.sh und scripts/build_native.sh können Docker Images für den Betrieb als 'normale' Java-Anwendung bzw. als Native-Anwendung erstellt werden.

   Warning

   Der Native Build dauert recht lange.

   Note	Das Erstellen des Native Image funktioniert nicht mit dem später ergänzten JSF-Anteil.

   Die Anwendung kann mit Hilfe der Scripts scripts/run_jvm.sh bzw. scripts/run_native.sh als Container gestartet werden.

4. Test-Unterstützung

   In sniplets/src/test befinden sich einige Test-Klassen, die als Projekt-Sourcen übernommen werden können.

   Start der Tests * in der IDE * per Maven (mvn test) * mittels Continuous Testing im Dev Mode (r).

5. Web-UI auf Basis von JSF

   1. Dependencies für MyFaces und PrimeFaces ergänzen

      siehe sniplets/myfaces_primefaces.txt.

   2. UI-Code aus klassischer Anwendung (unverändert) übernehmen

      • Paket de.gedoplan.showcase.webui mit Klasse PersonPresenter

      • Descriptor web.xml aus src/main/webapp nach `src/main/resources/META-INF

      • Web-Dateien aus src/main/webapp nach src/main/resources/META-INF/resources