Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Neues in Java 7
2 Threads und nebenläufige Programmierung
3 Datenstrukturen und Algorithmen
4 Raum und Zeit
5 Dateien, Verzeichnisse und Dateizugriffe
6 Datenströme
7 Die eXtensible Markup Language (XML)
8 Dateiformate
9 Grafische Oberflächen mit Swing
10 Grafikprogrammierung
11 Netzwerkprogrammierung
12 Verteilte Programmierung mit RMI
13 RESTful und SOAP Web-Services
14 JavaServer Pages und Servlets
15 Applets
16 Datenbankmanagement mit JDBC
17 Technologien für die Infrastruktur
18 Reflection und Annotationen
19 Dynamische Übersetzung und Skriptsprachen
20 Logging und Monitoring
21 Java Native Interface (JNI)
22 Sicherheitskonzepte
23 Dienstprogramme für die Java-Umgebung
Stichwort

Buch bestellen
Ihre Meinung?

Spacer
Java 7 - Mehr als eine Insel von Christian Ullenboom
Das Handbuch zu den Java SE-Bibliotheken
Buch: Java 7 - Mehr als eine Insel

Java 7 - Mehr als eine Insel
Rheinwerk Computing
1433 S., 2012, geb.
49,90 Euro, ISBN 978-3-8362-1507-7
Pfeil 14 JavaServer Pages und Servlets
Pfeil 14.1 Dynamisch generierte Webseiten
Pfeil 14.1.1 Was sind Servlets?
Pfeil 14.1.2 Was sind JavaServer Pages?
Pfeil 14.2 Servlets und JSPs mit Tomcat entwickeln
Pfeil 14.2.1 Servlet-Container
Pfeil 14.2.2 Entwicklung der Servlet/JSP-Spezifikationen
Pfeil 14.2.3 Webserver mit Servlet-Funktionalität
Pfeil 14.2.4 Tomcat installieren
Pfeil 14.2.5 Ablageort für eigene JSPs
Pfeil 14.2.6 Webapplikationen
Pfeil 14.2.7 Zuordnung von Webapplikationen zu physikalischen Verzeichnissen
Pfeil 14.2.8 Web-Projekt mit Eclipse IDE for Java EE Developers
Pfeil 14.3 Statisches und Dynamisches
Pfeil 14.3.1 Statischer Template-Code
Pfeil 14.3.2 Dynamische Inhalte
Pfeil 14.3.3 Kommentare
Pfeil 14.4 Die Expression Language (EL)
Pfeil 14.4.1 Operatoren der EL
Pfeil 14.4.2 Literale
Pfeil 14.4.3 Implizite EL-Objekte
Pfeil 14.5 Formulardaten
Pfeil 14.5.1 Einen Parameter auslesen
Pfeil 14.5.2 HTML-Formulare
Pfeil 14.6 Auf Beans zurückgreifen
Pfeil 14.6.1 Beans in JSPs anlegen
Pfeil 14.6.2 Properties einer Bean im EL-Ausdruck erfragen
Pfeil 14.6.3 Properties mit <jsp:setProperty> setzen
Pfeil 14.6.4 Bean-Klasse zum Testen von E-Mail-Adressen
Pfeil 14.6.5 Parameterwerte in Bean übertragen
Pfeil 14.7 JSP-Tag-Libraries
Pfeil 14.7.1 Standard Tag Library (JSTL)
Pfeil 14.8 Skripting-Elemente in JSPs
Pfeil 14.8.1 Scriptlets
Pfeil 14.8.2 JSP-Ausdrücke
Pfeil 14.8.3 JSP-Deklarationen
Pfeil 14.8.4 Quoting
Pfeil 14.8.5 Entsprechende XML-Tags
Pfeil 14.8.6 Implizite Objekte für Scriptlets und JSP-Ausdrücke
Pfeil 14.9 Sitzungsverfolgung (Session Tracking)
Pfeil 14.9.1 Lösungen für die Sitzungsverfolgung
Pfeil 14.9.2 Sitzungen in JSPs
Pfeil 14.9.3 Auf Session-Dateien zurückgreifen
Pfeil 14.10 Servlets
Pfeil 14.10.1 Servlets compilieren
Pfeil 14.10.2 Servlet-Mapping
Pfeil 14.10.3 Der Lebenszyklus eines Servlets
Pfeil 14.10.4 Mehrere Anfragen beim Servlet und die Thread-Sicherheit
Pfeil 14.10.5 Servlets und Sessions
Pfeil 14.10.6 Weiterleiten und Einbinden von Servlet-Inhalten
Pfeil 14.11 Zum Weiterlesen

Rheinwerk Computing - Zum Seitenanfang

14.2 Servlets und JSPs mit Tomcat entwickelnZur nächsten Überschrift

Um Servlets und JavaServer Pages entwickeln und testen zu können, benötigen wir einen Servlet-fähigen Webserver beziehungsweise einen Servlet-Container. Mittlerweile gibt es eine große Anzahl von Herstellern, deren Server Servlets verwalten, und die etablierten Lösungen sind frei.


Rheinwerk Computing - Zum Seitenanfang

14.2.1 Servlet-ContainerZur nächsten ÜberschriftZur vorigen Überschrift

Servlets und Applets sind konzeptionell ähnlich. Daher kann ein Vergleich gewagt werden: Applets werden vom Webbrowser geladen und gestartet. Den Browser können wir dabei als Container für Applets betrachten, der eine Infrastruktur wie die virtuelle Maschine oder Netzwerkeigenschaften bereitstellt. Innerhalb einer Java-Umgebung im Browser können durchaus mehrere Applets parallel eingebunden sein, die untereinander kommunizieren. Genauso verhält es sich mit Servlets. Auch hier benötigen wir einen Container, der alle Servlets verwaltet. Dieser kann entweder in einem Webserver eingebettet sein oder in einem Applikationsserver. Der Container leitet dann Anfragen an das Servlet weiter. Neben der Kommunikation nach außen verwaltet der Container den Lebenszyklus eines Servlets, genau wie ein Browser darüber wacht, ob das Applet gerade sichtbar ist oder nicht. Bei Servlets sieht ein solcher Vorgang wie folgt aus: Ein Client richtet eine HTTP-Anfrage an den Webserver. Dieser bemerkt, dass es sich um ein Servlet handelt, und gibt die Anfrage an den Container weiter. Dieser wiederum verwaltet alle Servlets, spricht genau das Servlet an, das der Benutzer nutzen wollte, und übergibt Datenströme zur Ein- und Ausgabe. Das Servlet liest über den Eingabekanal optional Formularinhalte und generiert über den Ausgabestrom eine HTML-Seite, die der Container an den Client weiterreicht.


Rheinwerk Computing - Zum Seitenanfang

14.2.2 Entwicklung der Servlet/JSP-SpezifikationenZur nächsten ÜberschriftZur vorigen Überschrift

Servlets gibt es schon seit 1995 und damit so lange wie Java selbst. JavaServer Pages kamen etwas später hinzu, haben sich jedoch genauso im Laufe der Jahre weiterentwickelt. Während am Anfang Sun alleine die Bestandteile für JSPs und Servlets spezifizierte, wurde dann ab JSP 1.2 und Servlet 2.3 alles Weitere im Java Community Process modelliert. Die JSP-Spezifikationen kamen dabei immer kurz hinter den Servlet-Spezifikationen. Elf Jahre lief der Servlet 2.x-Zweig bis Servlet 2.5, bis die Spezifikation im Dezember 2009 durch Servlet 3.0 abgelöst wurde. Im Bereich JSP ist die aktuelle Version JSP 2.2, die ein Teil der Java EE-6-Technologie ist. Doch immer noch spielen die Spezifikationen JSP 2.1 und Servlet 2.5 eine wichtige Rolle in der Praxis, da

  • Java EE 6 noch nicht groß verbreitet ist,
  • alleinstehende Servlet 3.0-Container selten sind,
  • Tomcat immer noch der Platzhirsch im Bereich der Servlet-Container ist und
  • große Unternehmen sehr zurückhaltend (konservativ) im Umgang mit neuen Technologien sind.

Rheinwerk Computing - Zum Seitenanfang

14.2.3 Webserver mit Servlet-FunktionalitätZur nächsten ÜberschriftZur vorigen Überschrift

Ein Server ist genau dann servlet-fähig, wenn er die Java-Servlet- und JSP-Spezifikation erfüllt. Drei bekannte freie Server sind:

  • Apache Tomcat: Tomcat ist ein Produkt der Apache Software Foundation und steht quelloffen unter der Apache-Lizenz. Er ist wie der Apache-Server frei und unter http://tomcat.apache.org/ zu finden. Zum Testen von Servlets und JSPs kann Tomcat entweder als Standalone-Applikation eingesetzt oder auch in den Apache-Server eingebunden werden. Tomcat 7 ist die neueste Version und implementiert die Standards Servlet 3.0, JSP 2.2 und EL 2.2. Tomcat 6 implementiert die Standards JSP 2.1, Servlet 2.5 und EL 2.1. Tomcat 5.5 ist die offizielle Referenzimplementierung der Servlet 2.4- und JSP 2.0-Spezifikation und bringt die Commons Expression Language 1.0 mit.
  • Jetty: Ein weiterer freier HTTP-Server und Servlet-Container unter der Apache-Lizenz ist Jetty (http://jetty.mortbay.org/). Jetty lässt sich leicht in eigene Programme einbauen, die Servlet/JSP-Funktionalität benötigen, um etwa Web-Services anzubieten. Jetty 6 bietet Unterstützung für den Servlet 2.5-Standard, die aktuelle Version Jetty 8 unterstützt Servlet 3.0.
  • GlassFish (https://glassfish.dev.java.net/): Die Referenzimplementierung der Java EE 7-, Java EE 6- und Java EE 5-Spezifikationen. GlassFish integriert einen Web-Container, denn das gehört zum Java EE-Standard.

Rheinwerk Computing - Zum Seitenanfang

14.2.4 Tomcat installierenZur nächsten ÜberschriftZur vorigen Überschrift

Die Webseite http://tomcat.apache.org/download-70.cgi bietet unter der Rubrik Binary Distributions diverse Downloads an. Unter dem Punkt Core lässt sich Tomcat 7 als komprimiertes Archiv (.zip oder .tar.gz) oder Installer für Windows (.exe) beziehen.

Abbildung

Abbildung 14.1: Download von Tomcat

Wir entscheiden uns zum Beispiel für das Zip-Archiv apache-tomcat-7.0.16.zip, das wir auspacken müssen – im Folgenden wird der Pfad C:\Program Files\apache-tomcat-7.0 angenommen. Im Verzeichnis von Tomcat gibt es folgende Unterordner:

Tabelle 14.1: Unterordner im Verzeichnis von Tomcat

Ordner Beschreibung

bin

Ordner mit Batch-Skripten zum Starten/Beenden des Servers

conf

Konfigurationsdateien

lib

Jar-Dateien von Tomcat und für eigene Webapplikationen

logs

Logging-Dateien

temp

Ordner für temporäre Dateien

webapps

Webapplikationen

work

Servlets, die aus JSPs generiert wurden

Tomcat definiert zwei Teilprojekte mit den Namen Catalina und Jasper. Catalina ist für Servlets zuständig, und Jasper ist der JSP-Compiler, der JavaServer Pages in Servlets übersetzt. Jasper ist selbst ein Servlet. Bei einer Installation sind beide Teile aktiv.

Starten und Beenden

Zum Starten von Tomcat befinden sich im Ordner bin die Batch-Datei startup (mit der Endung .bat für Windows und .sh für Unix-Systeme) und zum Beenden die Batch-Datei shutdown. Ein erfolgreicher Start von Tomcat setzt jedoch eine gesetzte Umgebungsvariable JAVA_HOME voraus. Die Variable über die Systemeigenschaften zu setzen ist eine Möglichkeit, um kurz die Datei catalina.bat[96](startup und shutdown greifen auf catalina zurück.) für Windows zu editieren. Die ersten Zeilen werden dann etwa diese sein:

Listing 14.3: C:\Program Files\apache-tomcat-7.0\bin\startup.bat

@echo off
rem Licensed to the Apache Software Foundation (ASF) under one or more
...
rem limitations under the License.
SET JAVA_HOME=C:\Program Files\Java\jdk1.7.0

if "%OS%" == "Windows_NT" setlocal

Jetzt lässt sich Tomcat über startup starten, und Konsolenmeldungen erscheinen. Ein Blick im Browser auf die lokale Adresse http://localhost:8080/ zeigt die Tomcat-Startseite. Hier finden sich Beispiele und die APIs für das Paket.

Abbildung

Abbildung 14.2: Willkommensbildschirm unter http://localhost:8080/

Konfiguration

Im Unterverzeichnis conf liegt die XML-Datei server.xml, die wichtigste Konfigurationsdatei für den Server. Hier lässt sich beispielsweise der Port anpassen; ohne Veränderung der Voreinstellungen installiert sich der Webserver auf dem lokalen Rechner auf Port 8080.


Rheinwerk Computing - Zum Seitenanfang

14.2.5 Ablageort für eigene JSPsZur nächsten ÜberschriftZur vorigen Überschrift

Die Hauptseite, die bei http://localhost:8080/ im Browser bezogen wird, befindet sich physikalisch unter C:\Program Files\apache-tomcat-7.0\webapps\ROOT\index.jsp.

Unsere erste JSP wollen wir zum Testen direkt unter ROOT setzen:

Listing 14.4: C:\Program Files\apache-tomcat-7.0\webapps\ROOT\date.jsp

<html><body>
Hallo Nutzer. Wir haben heute
<%= new java.util.Date() %>
.
</body></html>

Im Browser steuert die URL http://localhost:8080/date.jsp diese neue JSP an. Jasper übersetzt die JSP in ein Servlet und führt es aus, sodass der Browser etwa Folgendes anzeigt:

Hallo Nutzer. Wir haben heute Fri Aug 19 09:05:05 CEST 2012.

Dass unsere JSPs unter ROOT liegen, ist zwar praktisch, aber unprofessionell. Wir sollten sie in ein anderes Verzeichnis legen. So können wir ohne Schwierigkeiten unsere Projekte weitergeben und müssen uns auch bei einer Neuinstallation von Tomcat keine Sorgen machen. Dafür ist jedoch etwas Konfigurationsaufwand erforderlich. Vereinfachen können wir uns die Arbeit, indem wir ein Eclipse-Plugin nutzen.


Rheinwerk Computing - Zum Seitenanfang

14.2.6 WebapplikationenZur nächsten ÜberschriftZur vorigen Überschrift

Eine Webapplikation definiert die logische Struktur der Elemente, die zu einer Webanwendung gehören. Insbesondere sind diese Elemente statische Webseiten, Bilder und Medien, JSPs und Servlets, externe Bibliotheken, Tag-Libraries, Beans und Applets. Jeder Webapplikation wird ein eigenes Verzeichnis zugeordnet, in dem es eine vordefinierte Verzeichnisstruktur gibt. Von besonderer Bedeutung ist das Unterverzeichnis WEB-INF, das auch Tomcat für Beispiel-Webapplikationen nutzt:

  • C:\Program Files\apache-tomcat-7.0\webapps\examples\WEB-INF
  • C:\Program Files\apache-tomcat-7.0\webapps\ROOT\WEB-INF

In WEB-INF stehen Objekte, die der Webserver nicht nach außen freigibt, etwa Servlet-Klassen, obwohl die Servlets selbst natürlich nutzbar sind. Des Weiteren findet sich in WEB-INF eine Datei web.xml, der sogenannte Deployment-Descriptor. Unter WEB-INF können zusätzlich die Unterverzeichnisse classes und lib definiert werden, so wie Tomcat es auch für die Webapplikation examples vornimmt.

  • classes: Das Verzeichnis nimmt übersetzte Java-Klassen auf. Das können Servlets, Java-Beans oder andere Klassen sein. Der Servlet-Container nimmt die Objekte automatisch in den Suchpfad mit auf.
  • lib: Im Unterverzeichnis lib stehen Jar-Archive, die ebenfalls in den Suchpfad aufgenommen werden.

Tomcat beginnt mit der Suche nach Klassen im Verzeichnis WEB-INF/classes und sucht, falls die Klassen dort nicht zu finden waren, anschließend in WEB-INF/lib weiter. Unter dem Ordner lib direkt im Installationsverzeichnis von Tomcat können applikationsübergreifende Bibliotheken abgespeichert sein.

Beispiel

So kann die Verzeichnisstruktur einer Webapplikation aussehen:

index.jsp
login.jsp
pics/logo.gif
WEB-INF/web.xml
WEB-INF/table.tld
WEB-INF/lib/driver.jar
WEB-INF/classes/com/tutego/servlet/ChartServlet.class
WEB-INF/classes/com/tutego/beans/Customer.class


Rheinwerk Computing - Zum Seitenanfang

14.2.7 Zuordnung von Webapplikationen zu physikalischen VerzeichnissenZur nächsten ÜberschriftZur vorigen Überschrift

Um die Webapplikationen nicht unter dem Ordner webapps ablegen zu müssen, gilt es, die Datei conf/server.xml im Tomcat-Verzeichnis zu modifizieren. Dort ist ein Eintrag eingebunden, der genau den Pfad auf unser Projekt angibt, sodass Tomcat einer Webapplikation ein Verzeichnis zuordnen kann. Die Zuordnung geschieht dabei mit einem XML-Eintrag Context im Host-Element, der unter http://tomcat.apache.org/tomcat-7.0-doc/config/context.html genau beschrieben ist.

Beispiel

Mit einem neuen Eintrag in server.xml kommen die Beispiele des Buches in einen neuen Kontext:

<Context path="/web"
docBase="C:/Insel/programme/2_14_JSP_Servlets/WebContent"
reloadable="true" />

Nach der Änderung muss Tomcat neu gestartet werden. Nach dem Start befinden sich die JSPs dann unter http://localhost:8080/web/.


Rheinwerk Computing - Zum Seitenanfang

14.2.8 Web-Projekt mit Eclipse IDE for Java EE DevelopersZur nächsten ÜberschriftZur vorigen Überschrift

Mit der Eclipse IDE for Java EE Developers ist die Entwicklung von JSPs und Servlets sehr komfortabel; das Gleiche gilt für die NetBeans-IDE.

Einen Server anmelden

Zuerst soll Tomcat als Web-Container angemeldet werden. Wir wählen dazu unter WindowPreferences... im Baum unter Server den Eintrag Server Runtime Environments. Unter Add... öffnet sich ein neuer Dialog, wo wir im Baum Apache dann Apache Tomcat v7.0 auswählen und mit Next einen weiteren Dialog bekommen. Dort ist der Installationsort von Tomcat einzutragen, etwa C:\Program Files\apache-tomcat-7.0. Finish beendet den kleinen Dialog, und anschließend ist auch im Dialog Preferences der Tomcat-Server eingetragen.

Jetzt kann Eclipse grundsätzlich etwas mit Tomcat anfangen, aber die Tomcat-Instanz soll in einer eigenen Eclipse-Ansicht angezeigt und verwaltet werden (die Ansicht ist in der Java EE-Perspektive automatisch eingeblendet). Falls die Ansicht nicht sichtbar ist, aktivieren wir sie unter WindowShow View und wählen dann unter Server den Punkt Servers. In der neuen Ansicht ist – falls noch nicht eingetragen – im Kontextmenü unter NewServer der Tomcat v7.0 Server auszuwählen und mit Finish zu übertragen.

Ein neues Web-Projekt

Nach dem Bekanntmachen des Servers können wir das Web-Projekt anlegen. (Ohne es verschweigen zu wollen: Auch dort lässt sich noch der Server anlegen.)

  1. Wir wählen dazu FileNewOther..., dann unter Web den Eintrag Dynamic Web Project.
  2. Im neuen Dialog New Dynamic Web Project geben wir bei Project name einen Projektnamen an. Für mein Kapitel wähle ich 14_JSPServlets.
  3. Unter Target Runtime ist unser Apache Tomcat ausgewählt. Bei mehreren Servern oder Servern, die vorher unter den Einstellungen nicht angemeldet wurden, kann jetzt noch schnell ein Server bestimmt werden.
  4. Finish würde das Projekt schon jetzt abschließen, doch wir wollen noch den Namen der Context Root anpassen. Im nächsten Dialog unter Next vergibt das WTP als Standardnamen den Namen des Projekts. Den möchte ich in »web« ändern. Jetzt darf Finish den Wizard abschließen und das WTP unser Projekt aufbauen.

Die logische Verzeichnisstruktur ist wie folgt:

  • Unter Java Sources: src befinden sich Java-Quellen für Servlets, Beans, Tag-Implementierungen und ganz allgemeine Quellcodeklassen.
  • Das Verzeichnis WebContent bildet das Dokumenten-Wurzelverzeichnis mit den üblichen Webapplikationsverzeichnissen WEB-INF und META-INF sowie der zentralen Datei web.xml.

Eine neue HTML/JSP-Seite

Ist im Projektbaum WebContent selektiert, finden sich im Kontextmenü unter New die Einträge HTML und JSP. In beiden Fällen ist der Dateiname anzugeben – ohne Dateiendung. Ein Ende mit Finish liefert eine Seite mit Standard-Vorlage; wählen wir Next, können wir eine Vorlage auswählen.

Ist eine JSP oder HTML-Seite angelegt, kann mit gestartetem Tomcat-Server einfach der interne Webbrowser über das Kontextmenü Run AsRun on ServerFinish die Seite anzeigen.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück
  Zum Katalog
Neuauflage: Java SE 8 Standard-Bibliothek
Neuauflage: Java SE 8 Standard-Bibliothek
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Professionell entwickeln mit Java EE 7






 Professionell
 entwickeln mit
 Java EE 7


Zum Katalog: Java ist auch eine Insel






 Java ist auch
 eine Insel


Zum Katalog: Einstieg in Eclipse






 Einstieg in Eclipse


Zum Katalog: Einstieg in Java






 Einstieg in Java


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2012
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de