SEP SS 2021
Tutorial

Einleitung

Im Folgenden bekommen Sie einen kurzen Überblick über die speziellen Technologien, mit denen Sie sich im Rahmen des SE-Praktikums auseinandersetzen werden. Details und weiterführende Informationen finden Sie bei den angegebenen Links.

HTTP

HTTP steht für Hypertext Transfer Protocol und bezeichnet das Netzwerk-Protokoll, das dem WWW zu Grunde liegt. Es handelt sich um ein einfach aufgebautes Klartext-Protokoll. Im Normalfall erfolgt die Kommunikation zwischen Server und Client über TCP/IP Sockets. Über HTTP können beinahe beliebige Resourcen übertragen werden. Diese Ressourcen werden dabei über URLs identifiziert. Im Allgemeinen hat eine solche URL die Form

http://rechnername.domain.tld:Port/pfad/ressource-name

TLD steht dabei für Top-Level Domain (also de, com, org etc.) und Port für eine Zahl zwischen 1 und 32167. Ein Webserver erwartet Anfragen von Clients normalerweise auf Port 80, kann aber auf einen beliebigen anderen (freien) Port umkonfiguriert werden. Wichtig für die Entwicklung von Web-Anwendungen ist die Tatsache, dass es sich bei HTTP um ein verbindungsloses Protokoll handelt. Clients stellen Anfragen an den Server nach verschiedenen Ressourcen (HTML-Seite, darin enthaltene Bilder etc.) Diese Anfragen lassen sich für eine Web-Anwendung nicht ohne weiteres einem einzelnen Client eindeutig zuweisen. Es ist also zusätzlicher Aufwand nötig, um Informationen über Authentifizierung, Kontexte etc. zu erhalten. Weitere Informationen dazu im Abschnitt Session Tracking.

http://www.w3.org/Protocols/

Was sind Servlets?

Java Servlets stellen den Ansatz der Firma Oracle (vormals Sun) dar, Java als Ersatz für CGI-Skripte zu etablieren. Oracle selbst definiert das so: "A servlet can almost be thought of as an applet that runs on the server side - without a face." Es handelt sich also um eine Technologie, mit der in Java geschriebene Programme Anfragen von Clients über HTTP empfangen, verarbeiten und beantworten können. Die Ausführung der Java-Programme und die Bereitstellung der Verbindung zum Client etc. erfolgt dabei durch einen sogenannten Servlet-Container, und weitgehend transparent für den Programmierer. Vorraussetzung dabei ist, dass selbst programmierte Servlets immer Unterklasse einer der von Oracle bereitgestellten Servletklassen sein müssen, hier HttpServlet. Die Vorteile gegenüber anderen Ansätzen sind dabei klar: Zugriff auf das komplette Java API und viele Java-Bibliotheken von Drittherstellern, die weitgehende Plattformunabhängigkeit und die Existenz von ausgereiften Entwicklungsumgebungen. Ein einfaches Beispiel-Servlet finden Sie hier.

Java Servlets
Java 7 - Mehr als eine Insel
Java Servlets Tutorial
Java Servlets 5.0 API Dokumentation

Was ist Jakarta Server Faces?

Jakarta Server Faces (JSF) ist der neue Name für JavaServer Faces (JSF). Diese Technologie erlaubt die eine ähnlich strukturierte Programmierung von Webanwendungen wie Java Swing für normale graphische Oberflächen. Mit Facelets gibt es eine zu XHTML sehr ähnliche Sprache, die das erstellen einer Oberfläche in XML erlaubt. Wie bei Swing gibt es Listener (Java Methoden), die bei den verschiedenen JSF-Komponenten (z.B. einem Knopf) registriert werden können und dann bei einem Ereignis (Drücken des Knopfs) Aktionen ausführen. Genauso wie bei Swing wird so die Verwendung von MVC automatisch erzwungen, im Gegensatz zu der Verwendung von Servlets und JSP. In der Regel wird pro Dialog- (= Web-) Seite oder pro Formular ein sog. Backing Bean bereitgestellt, das alle Listener und Datenproperties (z.B. für Eingabefelder) für die Seite enthält.
Bei der Verwendung von Jakarta Server Faces arbeitet man eine Abstraktionsebene höher als mit Serlvets und JSP, kommt also in der Regel mit diesen Technologien nicht direkt in Berührung. Oracle empfiehlt zur Anwendungsentwicklung Jakarta Server Faces anstatt Servlets und JSP zu verwenden.

Bernd Müller, Java Server Faces 2.0, 2. Auflage, Hanser, 2010, 80/ST 253 J35 M9(2)
Michael Kurz, Martin Marinschek, JavaServer Faces 2.2, 3. Auflage, Dpunkt, 2014, 80/ST 253 J35 K9(3)
Bauke Scholz, Arjan Tijms, The Definitive Guide to JSF in Java EE 8: Building Web Applications with JavaServer Faces, Apress, 2018 (für fortgeschrittene Leser), 80/ST 250 J35 S36
Jakarta Server Faces im Jakarta EE Tutorial
Java Server Faces 3.0 API Dokumentation
Java Server Faces 3.0 Faclets Tag Documentation

Bitte beachten Sie, dass die obigen Jakarta Server Faces Tutorials meistens davon ausgehen, dass die Jakarta-Server-Faces-Library (Mojarra) bereits im Applikationserver enthalten ist. Bei Tomcat ist dies jedoch nicht der Fall. Man kann sie aber leicht pro Applikation nachrüsten, indem man die entsprechende(n) jar-Dateien in das Verzeichnis WebContent\WEB-INF\lib kopiert. Sie brauchen die Jakarta-Server-Faces-Referenzimplementierung Mojarra. Links dazu finden sie hier. Da die Demo Applikation die Biliothek und ihre Abhängigkeiten bereits enthält, läuft sie ohne weiteres Zutun unter Tomcat.

Ab JSF 2 ist das parallel entwickelte Context and Dependency Injection CDI integriert. De Facto werden dadurch proprietäre Annotationen wie z.B. @ManagedBean oder @ManagedProperty durch die entsprechenden von CDI (hier @Named und @Inject) ersetzt. Ab JSF 2.2 werden die nicht-CDI Annotationen als deprecated betrachtet und ab JSF 2.3 auch als solche markiert, d.h. der Compiler gibt damit Warnmeldungen bei deren Verwendung an. Leider betrachtet obige/gängige Literatur hautpsächlich noch die alte Notation. Ab Jakarta EE 9, JSF 3.0, CDI 4.0 wird aus Markenrechtsansprüchen seitens Oracle der Namensbereich javax (Package- und Variablennamen) durchgängig durch jakarta ausgetauscht. Hier finden Sie die CDI-Version der Demo Applikation und (nur zur Illustrationswecken) das deprecated Pendant. Ersteres benutzt die CDI-Referenzimplementierung Weld , welche sich in Form der (all-in-one) Library weld-servlet-shaded.jar im Ordner WebContent\WEB-INF\lib der Applikation befindet. Letzteres ist mittlerweile wegen o.g. Package-Umbenennung nur noch unter Tomcat 9.0.x lauffähig. Da die Implementierung im Praktikum auf CDI basieren muss, soll CDI auch in der Einführungsaufgabe verwendet werden.

Session Tracking

Als Session Tracking bezeichnet man das Speichern von Kontext-Informationen über einen Client, beim Zugriff über mehrere Seiten einer Web-Applikation. Beispiele hierfür sind z.B. Informationen über den Authentifizierungsstatus eines Benutzers (angemeldet etc.).
Session Tracking wird in der aktuellen Servlet API direkt durch entsprechende Methoden unterstützt. Standardmässig werden die Session-Informationen dabei in Cookies abgelegt. Da Ihre Webanwendung jedoch auch lauffähig sein muss, wenn der Benutzer die Speicherung von Cookies unterbindet, müssen Sie auf einen alternativen Weg der Speicherung zurückgreifen:

Solange die Jakarta-Server-Faces-Welt nicht verlassen wird, kümmert sich Jakarta Server Faces bei Bedarf automatisch um das URL-Rewriting.

Beispielinstallation Tomcat 10.0.x im CIP-Pool

Tomcat ist ein Servlet-API 5.0 kompatibler Servlet-Container. Tomcat kann entweder in Verbindung mit einem bestehenden Webserver arbeiten, oder aber eigenständig. Für das SE-Praktikum sollten Sie Tomcat als eigenständigen Webserver+Servlet-Container installieren. Sie haben dann völlige Kontrolle über den Server und können ihn beenden und neustarten.

  1. Tomcat Binaries Core runterladen
    Neuste Version 10.0.x: http://tomcat.apache.org/download-10.cgi
  2. Archiv auspacken
    tar xvzf apache-tomcat-10.0.x.tar.gz
    Es entsteht ein neues Verzeichnis apache-tomcat-10.0.x. Das Verzeichnis können Sie nach belieben umbenennen oder an eine andere Stelle verschieben.
  3. Environment-Variablen setzen / kontrollieren
    export CATALINA_HOME=/home/cip/<login>/apache-tomcat-10.0.x bzw. den Pfad Namen Ihres Tomcat-Verzeichnisses. Zusätzlich sollte natürlich auch der CLASSPATH für Java richtig gesetzt sein. Z.B. muss zum manuellen kompilieren Ihrer Servlets (nicht zum Ausführen) im CLASSPATH die Datei $CATALINA_HOME/lib/servlet-api.jar (also das Archiv mit den Servlet-Klassen) enthalten sein.
  4. Tomcat konfigurieren
    Im Verzeichnis <CATALINA_HOME>/conf finden Sie die Datei server.xml. Hier stellen Sie die globalen Konfigurations-Optionen von Tomcat ein. Im Bereich <Service name="Catalina"> sollten Sie den Port, auf dem der Webserver antwortet von 8080 auf einen neuen Wert setzen. Achtung: Die Portnummer muss > 1023 und noch nicht vergeben sein. Am besten verwenden Sie ein Schema der Form 80<Gruppennummer>. Beachten Sie, auf diese Ports kann man nur lokal im CIP-Pool zugreifen. Nur ein aktiver VPN-Tunnel hilft dabei nicht. Sie können sich aber eine Portweiterleitung per SSH einrichten. Auch den Port 8005 sollten Sie verändern. Solange alle Gruppen auf unterschiedlichen Workstations Ihre Tomcats starten, sollte es keine Probleme geben. Mit eindeutigen Portnummern sind Sie aber auf jeden Fall auf der sicheren Seite. Genauere Informationen zu den Konfigurations-Optionen etc. finden Sie im Tomcat-Handbuch Version 10.0.x.
  5. Anlegen einer Web-Applikation
    Als Web-Applikation bezeichnet man eine Servlet-Anwendung. Diese kann dabei auch aus mehreren Servlets, Facelets, sowie statischen HTML-Seiten und auch JSP-Seiten bestehen. Um eine Web-Applikation einfach portabel und installierbar zu halten, werden alle Daten zu einer Web-Applikation nach einem einheitlichen Schema unterhalb eines eigenen Hauptverzeichnisses abgelegt. Im Einzelnen verläuft das so:
    1. Erstellen eines Verzeichnisses unter <CATALINA_HOME>/webapps/ z.B. jsfdemo
    2. Erstellen der folgenden Hierarchie unterhalb dieses Verzeichnisses:
      ...jsfdemo/ressources
      ...jsfdemo/view
      ...jsfdemo/META-INF
      ...jsfdemo/WEB-INF
      ...jsfdemo/WEB-INF/classes
      ...jsfdemo/WEB-INF/lib
       Die (kompilierten) Java-Klassen kommen später ins Verzeichnis classes, z.B. Managed Beans, und ins Verzeichnis lib sollten zusätzliche von Ihnen verwendete Java-Bibliotheken in Form von JAR-Files kommen, wie z.B. die Jakarta Server Faces und Weld Libraries. Ins Verzeichnis view kommen die Facelet-Dateien mit der Endung .xhtml, wie z.B. login.xhtml
    3. Erstellen der Datei ...WEB-INF/web.xml mit mindestens folgendem Inhalt:
      Rote Kommentare bitte weglassen.

      <?xml version="1.0" encoding="UTF-8"?>
<web-app id="jsfdemo" version="5.0"
         xmlns="https://jakarta.ee/xml/ns/jakartaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
                             https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd">

  <display-name>Jakarta Server Faces Demo</display-name>

  <servlet>                                     <!-- JSF Controller-Servlet -->
    <servlet-name>facesServlet</servlet-name>   <!-- Interne ID des Servlets -->
    <servlet-class>                             <!-- Name der Servlet-Klasse -->
      jakarta.faces.webapp.FacesServlet
    </servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>
  <servlet-mapping>                             <!-- Verknüpfung Servlet - URL -->
    <servlet-name>facesServlet</servlet-name>   <!-- Servlet ID -->
    <url-pattern>/faces/*</url-pattern>         <!-- URL Pattern unter der das Servlet erreichbar sein soll -->
  </servlet-mapping>

  <context-param>                               <!-- JSF Debug Ausgaben auf Webseiten sichtbar -->
    <param-name>jakarta.faces.PROJECT_STAGE</param-name>
    <param-value>Development</param-value>
  </context-param>

  <welcome-file-list>
    <welcome-file>faces/view/newCourse.xhtml</welcome-file>  <!-- Facelet, das bei Aufruf der Webapp
                                                                  als erstes aufgerufen wird -->
  </welcome-file-list>
    
  <resource-env-ref>                            <!-- Weld needs this -->
    <description>Object factory for the CDI Bean Manager</description>
    <resource-env-ref-name>BeanManager</resource-env-ref-name>
    <resource-env-ref-type>
      jakarta.enterprise.inject.spi.BeanManager
    </resource-env-ref-type>
  </resource-env-ref>

</web-app>

      Ein Faclet ist dann unter http://<rechnername>:<Port>/<Web-App Name>/ (default) bzw. http://<rechnername>:<Port>/<Web-App Name>/faces/view/<faclet-name.xhtml> erreichbar.
      Genauere Informationen zu den Konfigurations-Optionen etc. finden Sie im Tomcat-Handbuch, u.A. können Sie hier bestimmte URLs durch den Container (Tomcat) mit Passwörtern schützen lassen und andere Sicherheitseinstellungen treffen. Als Vorlage für Ihr Programm kann Ihnen auch die Konfigurationsdatei des unten genannten Beispiels dienen.
    4. Entpacken + Installieren des Jakarta Server Faces Demos
      Die restlichen Dateien müssen nur in die entsprechenden Verzeichnisse kopiert werden. Eine war-Datei ist nichts anderes als ein zip-Archiv mit anderer Endung. Dateien mit Endung .war packt Tomcat in der Grundeinstellung beim Start auch automatisch aus, wenn man sie in <CATALINA_HOME>/webapps/ legt.) Vergessen Sie nicht die für Weld/CDI wichtigen Dateien ...META-INF/context.xml, bean.xml und faces-config.xml zu übernehmen. Dann müssen Sie ggf./bei Änderungen noch den Java-Code kompilieren und Tomcat stoppen + neustarten. Danach sollten Sie über http://<rechnername>:<Port>/jsfdemo auf die Applikation zugreifen können.
  6. Tomcat starten / stoppen
    Im Verzeichnis <CATALINA_HOME>/bin einfach startup.sh aufrufen. Tomcat gibt ein paar Meldungen aus, und wenn alles richtig war können Sie unter http://<rechnername>:<Port> auf die Tomcat-Startseite zugreifen.
    Beendet wird Tomcat mit <CATALINA_HOME>/bin/shutdown.sh.

Hier wurde der manuelle Weg eine Web-Applikation zu erstellen im Detail gezeigt. Unter Eclipse können Sie war-Dateien direkt importieren und per Mausklick auf dem Server laufen lassen.