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
Download: - openbook, ca. 21,3 MB
Buch bestellen
Ihre Meinung?
<< zurück | Galileo Computing / <openbook> / Java 7 - Mehr als eine Insel | vor >>
Java 7 - Mehr als eine Insel von Christian Ullenboom Das Handbuch zu den Java SE-Bibliotheken
Java 7 - Mehr als eine Insel Galileo Computing 1433 S., 2012, geb. 49,90 Euro, ISBN 978-3-8362-1507-7 |
| 14 JavaServer Pages und Servlets
|  | 14.1 Dynamisch generierte Webseiten
|  |  | 14.1.1 Was sind Servlets?
|  |  | 14.1.2 Was sind JavaServer Pages?
|  | 14.2 Servlets und JSPs mit Tomcat entwickeln
|  |  | 14.2.1 Servlet-Container
|  |  | 14.2.2 Entwicklung der Servlet/JSP-Spezifikationen
|  |  | 14.2.3 Webserver mit Servlet-Funktionalität
|  |  | 14.2.4 Tomcat installieren
|  |  | 14.2.5 Ablageort für eigene JSPs
|  |  | 14.2.6 Webapplikationen
|  |  | 14.2.7 Zuordnung von Webapplikationen zu physikalischen Verzeichnissen
|  |  | 14.2.8 Web-Projekt mit Eclipse IDE for Java EE Developers
|  | 14.3 Statisches und Dynamisches
|  |  | 14.3.1 Statischer Template-Code
|  |  | 14.3.2 Dynamische Inhalte
|  |  | 14.3.3 Kommentare
|  | 14.4 Die Expression Language (EL)
|  |  | 14.4.1 Operatoren der EL
|  |  | 14.4.2 Literale
|  |  | 14.4.3 Implizite EL-Objekte
|  | 14.5 Formulardaten
|  |  | 14.5.1 Einen Parameter auslesen
|  |  | 14.5.2 HTML-Formulare
|  | 14.6 Auf Beans zurückgreifen
|  |  | 14.6.1 Beans in JSPs anlegen
|  |  | 14.6.2 Properties einer Bean im EL-Ausdruck erfragen
|  |  | 14.6.3 Properties mit <jsp:setProperty> setzen
|  |  | 14.6.4 Bean-Klasse zum Testen von E-Mail-Adressen
|  |  | 14.6.5 Parameterwerte in Bean übertragen
|  | 14.7 JSP-Tag-Libraries
|  |  | 14.7.1 Standard Tag Library (JSTL)
|  | 14.8 Skripting-Elemente in JSPs
|  |  | 14.8.1 Scriptlets
|  |  | 14.8.2 JSP-Ausdrücke
|  |  | 14.8.3 JSP-Deklarationen
|  |  | 14.8.4 Quoting
|  |  | 14.8.5 Entsprechende XML-Tags
|  |  | 14.8.6 Implizite Objekte für Scriptlets und JSP-Ausdrücke
|  | 14.9 Sitzungsverfolgung (Session Tracking)
|  |  | 14.9.1 Lösungen für die Sitzungsverfolgung
|  |  | 14.9.2 Sitzungen in JSPs
|  |  | 14.9.3 Auf Session-Dateien zurückgreifen
|  | 14.10 Servlets
|  |  | 14.10.1 Servlets compilieren
|  |  | 14.10.2 Servlet-Mapping
|  |  | 14.10.3 Der Lebenszyklus eines Servlets
|  |  | 14.10.4 Mehrere Anfragen beim Servlet und die Thread-Sicherheit
|  |  | 14.10.5 Servlets und Sessions
|  |  | 14.10.6 Weiterleiten und Einbinden von Servlet-Inhalten
|  | 14.11 Zum Weiterlesen
## 14.9 Sitzungsverfolgung (Session Tracking) Jeder Auftrag an den Webserver wird unabhängig von anderen Aufträgen verwaltet. Wenn wir beispielsweise eine Seite neu laden oder einen Verweis verfolgen, weiß der Server nicht (beziehungsweise interessiert sich nicht dafür), dass die Anfrage von uns kam. Was an diesem Verhalten deutlich wird, ist das Fehlen eines Zustands. Es fehlt also die Möglichkeit, dass ein Client vom Server identifiziert wird und einem aktuellen Zustand des bidirektionalen Kommunikationsverlaufes zugeordnet werden kann. Der Zustand bezieht sich hier auf eine nicht-existente serverseitige Information. Aus diesem Grund wird HTTP auch als zustandsloses Protokoll bezeichnet. Dass dies aber nicht immer wünschenswert ist und sogar einen Nachteil darstellen kann, sehen wir an unterschiedlichen Anforderungen: Ein Warenkorb für den Einkauf: In Online-Systemen wird ein Einkaufswagen gefüllt, und unterschiedliche Webseiten informieren Kaufwillige über die Produkte. Wenn der Server die Seitenanfrage einem Client nicht zuordnen kann, ist es nicht möglich, den Warenkorb individuell zu füllen. Individualisierung: Benutzer können auf sie persönlich zugeschnittene Webseiten sehen und etwa das Wetter auf Bali auf der Startseite auswählen sowie die Fußballergebnisse von Schalke 04. Demoskopie: Das System eignet sich auch für die Benutzerüberwachung. Besucht ein Benutzer eine Seite mehrmals, kann der Betreiber dies erkennen und diese Information mit einem »Ist-beliebt-Faktor« verbinden. Diese Information lässt sich natürlich kommerziell gut nutzen. ### 14.9.1 Lösungen für die Sitzungsverfolgung Es ist also ein System gesucht, das es dem Server erlaubt, den Client zu identifizieren, auch wenn HTTP ein zustandsloses Protokoll ist. Als Lösungen bieten sich an: Cookies: Ein Cookie speichert eine Kennung, sodass der Server den Client erkennt und die Informationen für ihn speziell aufbereitet. Obwohl dies in Java durch die Cookie-Klasse einfach möglich ist, hat dieser Ansatz noch einige Schwächen. Dem Servlet fällt die Aufgabe zu, aus der Cookie-Kennung die entsprechende Sitzung herauszusuchen und die Daten zu holen. Ein weiteres Problem ergibt sich dadurch, dass Cookies zwar möglich sind, aber vom Benutzer abgelehnt werden können, da dieser seine Anonymität aufs Spiel gesetzt sieht. Schaltet der Benutzer in seinem Lieblingsbrowser die Cookies aus, können wir nichts machen. Doch auch wenn Cookies verwendet werden, bleibt die Frage, wie lange der Cookie gültig sein soll. Hier ist zu überlegen, ob die Voreinstellung, dass der »Keks« nur eine Sitzung übersteht, sinnvoll ist. URL-Rewriting: Da ein Servlet vom Aufrufer Parameter bekommen kann, ist es eine nette Idee, an die URL einen Wert anzuhängen, der die aktuelle Sitzung kennzeichnet. Diese Kennung entspricht dann genau dem Wert des Cookies. Die Lösung ist simpel und funktioniert bei allen Browsern. Der Nachteil auf der Serverseite ist wiederum, dass uns die Aufgabe zufällt, der Kennung die Sitzung zuzuordnen. Zudem ist Vorsicht geboten, da diese Kennung bei jedem Verweis wieder angehängt wird. Außerdem ist es für den Benutzer sehr unschön, diese Kennungen zu sehen, zumal sie in die Bookmarks übernommen werden. Dies führt zu dem Problem, dass eine Sitzung angesprochen werden kann, die gar nicht mehr existiert. Dies ist ein sehr schwerwiegendes Problem, da die Anhängsel ja nicht wie Cookies automatisch veralten. Versteckte Felder (engl. hidden fields): In HTML-Seiten lassen sich versteckte Informationen in Formularen anlegen, die beim Versenden automatisch mitgeschickt werden. Dies sieht etwa so aus: <input type="hidden" name="session" value="..." /> Diese versteckten Informationen können auch genutzt werden, um eine Sitzungs-ID mitzuschicken. Der Vorteil ist, dass wir wieder keine Cookies benötigen und die URL nicht länger wird; der Nachteil ist, dass die Information immer dynamisch mit eingebaut werden muss. ### 14.9.2 Sitzungen in JSPs Verbindet sich ein Browser zum ersten Mal mit einer JSP, so erzeugt der Servlet-Container automatisch eine neue Sitzung und sendet standardmäßig einen Cookie zurück. Client und Server tauschen dann bei allen weiteren Anfragen diesen Cookie aus, sodass der Server den Client wiedererkennen kann. Wenn der Benutzer Cookies ablehnt, müssen wir eine zweite Implementierung anbieten, die Sitzungsinformationen an die URL anhängt, aber das soll jetzt kein Thema sein. ### 14.9.3 Auf Session-Dateien zurückgreifen Der Cookie, den der Server automatisch generiert, enthält eine ID, und diese ID ist mit einem Assoziativspeicher verbunden. In diesen Assoziativspeicher können wir Schlüssel/Werte-Paare setzen oder Werte über die Schlüssel erfragen. Für den Assoziativspeicher gibt es in der EL die implizite Variable sessionScope – sie bietet alle Daten einer Sitzung. Zusammenfassend lässt sich festhalten, dass die unterschiedlichen impliziten EL-Objekte pageScope, requestScope, sessionScope und applicationScope alle jeweils Zugriffe auf Daten in unterschiedlichen Gültigkeitsbereichen ermöglichen.
Beispiel
Lege eine Variable über ein Scriptlet in den Session-Scope, und lies sie mit der EL wieder aus:
    <% session.setAttribute( "url", "www.tutego.com" ); %>
    Die URL in der Session was: ${sessionScope.url}.
Die erste Zeile macht deutlich, dass für das Setzen (das Gleiche gilt für das Löschen) auf Scriptlets zurückgegriffen werden muss oder auf die JSTL, mit der das Setzen so aussehen würde: <c:set var="url" value="www.tutego.com" scope="session" />. Die Variable session ist eine JSP-Variable vom Typ HttpSession und bietet Methoden wie setAttribute(), removeAttribute(). In realistischen Programmen wird eine JSP keine Daten verändern, sondern nur Servlets bzw. ein Framework.
Beispiel
Beende eine Session:
    <% session.invalidate(); %>
Beenden wir die Sitzung – etwa nach einem Logout – nicht selbst, kommt ein Timeout und sie wird automatisch beendet.
### Ihr Kommentar Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen. >> Zum Feedback-Formular
<< zurück | <top> | vor >>
Zum Katalog
Java 7 – Mehr als eine Insel Jetzt bestellen
Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen? Ihre Meinung
Buchempfehlungen
| Java und XML
| Einstieg in Eclipse 3.7
| Android 3
| NetBeans Platform 7
| Java ist auch eine Insel
| Apps entwickeln für Android 4
| Java 7
Shopping
Versandkostenfrei bestellen in Deutschland und Österreich Info

Copyright © Galileo Press 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.

[Galileo Computing]
Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de