Zur Übersicht

Die impliziten Objekte

Im vorigen Beitrag wurde gezeigt, wie man mittels Skiptlets Javacode in JSPs einbetten kann, um so bspw. dynamisch auf Nutzereingaben reagieren zu können. Dazu benötigt man aber über die Möglichkeit, Java zu benutzen, hinaus noch den Zugriff auf Informationen, die die derzeit gültige Session, die Anwendung, den Request oder auch die zu erzeugende Response betreffen. Dazu dienen die impliziten Objekte, auf die man aus Skriptlets heraus zugreifen kann.
Insgesamt stehen neun Objekte zur Verfügung, die in den nächsten Abschnitten detailliert beschrieben werden. Die folgende Übersicht zeigt zunächst einmal die Namen der Objekte und von welchem Typ diese sind. Es lohnt sich, die verfügbaren Methoden dieser Objekte in der API der Java 2 Enterprise Edition anzusehen, da man sie häufig brauchen wird und hier nur die wichtigsten Methoden beschrieben werden. Im Übrigen braucht man Objekte dieser Interfaces/Klassen auch dann häufig, wenn man mit einem FrontController-Ansatz arbeitet.

Name Interface bzw. Klasse
request javax.servlet.http.HttpServletRequest
response javax.servlet.http.HttpServletResponse
session javax.servlet.http.HttpSession
pageContext javax.servlet.jsp.PageContext
application javax.servlet.ServletContext
config javax.servlet.ServletConfig
out javax.servlet.jsp.JspWriter
exception java.lang.Throwable

Das Objekt request

Das Objekt request, ist vermutlich das meistgenutzte implizite Objekt. Das heißt, dass es zu jeder Anfrage auch immer genau ein request-Objekt gibt. Mit Hilfe der request Methoden kannst du auf alle Informationen zu dem jeweiligen Request zugreifen.  Das kann der HTTP-Header sein, oder auch die Request-Parametern (GET-Parameter oder Formular-Eingaben) sein. Das können Cookies sein oder auch die IP Adresse des Client Die wichtigsten Methoden sind in der folgenden Übersicht zu finden.

Methode Rückgabewert Kurze Beschreibung Beispiel
getCookies() Cookie[ ] Mit dieser Methode werden alle Cookies des Nutzers als ein Cookie-Array zurückgegeben.
getHeader(String) String Gibt den benannten Header zurück. z.B.. den Browser mit „user-agent“.
.....
<% 
    out.print(request.getHeader("user-agent"));
 %>
.....

Gibt bei einem Opera Browser  und Windows 10 folgendes in der Web Seite aus:

    Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36 OPR/50.0.2762.58
getParameter(String) String Gibt den Wert des request Parameter zurück. Dabei ist es egal ob die Get oder die Post Methode für das Request benutzt wurde.
.....
<% 
    out.print(request.getParameter("name"));
 %>
.....

Gibt die den Wert der zuvor in einem Html Formularelements mit dem Namen „name“ eingegeben wurde, im darauf folgenden Response aus.

getMethod() String Gibt die HTTP-Methode (bspw. POST oder GET) zurück.
getQueryString() String Der Anfrage-String des Clients, der in der Adresszeile des Browsers an die URL angehängt wurde, oder der die Anfrage eines mit der GET-Methode abgesandten Formulars enthält.
getRequestURL() String Die URL die für die Anfrage genutzt wurde. Etwaige Anfrage-Parameter, die an die URL im Browser angehängt wurden, müssen aber mit der oben beschriebenen Methode „getQueryString()“ geholt werden.
getSession() HttpSession Mit dieser Methode sehen Sie das das request Objekt auch in der Lage ist das session Objekt zurück zu geben. Wird in Servlets oder auch Filter gerne gemacht, da dort die impliziten Objekte nicht vorliegen, sondern immer nur das request und das response Objekt..

Das Objekt response

Das response-Objekt ist das Gegenstück zum request-Objekt. In diesem Objekt werden alle Informationen für das HTTP-Response abgelegt, auch hier wieder für das aktuelle. Das response Objekt wird vor allem genutzt, um den Content-Type festzulegen und Response-Header zu erweitern oder um Cookies auf den Client zu setzen.
Auch hier wieder eine Übersicht der wichtigsten Methoden:

Methode Rückgabewert Kurze Beschreibung
addCookie(Cookie cookie) void Fügt den übergebenen Cookie der Response hinzu. Ob der Client diesen akzeptiert hat, lässt sich natürlich erst beim nächsten Request feststellen.
addDateHeader(String name, long date) void Formatiert einen Datums-String entsprechend der HTTP-Spezifikation und fügt diesen unter dem angegebenen Namen den Http-Headern hinzu
addHeader(String name, String value) void Fügt einen Header unter dem angegebenen Namen hinzu
addIntHeader(String name, int value) void Unter dem angegebenen Header-Namen wird ein Ganzzahl-Wert hinzugefügt
encodeURL(String url) String Bereinigt die URL von Sonderzeichen, Leerzeichen und dergleichen in einer URL nicht zugelassenen Zeichen und gibt diesen bereinigten String zurück.
encodeRedirectURL(String url) String Bereinigt die URL von Sonderzeichen, Leerzeichen und dergleichen in einer URL nicht zugelassenen Zeichen und gibt diesen bereinigten String zurück. Jede Redirect-Adresse sollte zuvor durch diese Methode gegangen sein
sendError(String sc) void Löscht den Puffer, setzt den Fehlercode und sendet die Response ab.
sendError(String sc, String message) void Löscht den Puffer, setzt den Fehlercode und sendet die Response ab. Zudem wird als Erklärung für den Client der angegebene Text mitgegeben.
setDateHeader(String name, long date) void Wie oben bei addHeader(name, date), nur dass hier ein schon zuvor gesetzter Wert überschrieben wird
setHeader(String name, Strng value) void Setzt einen Header unter dem Namen mit dem angegebenen Wert. Evtl. zuvor gesetzte header mit diesem Namen werden überschrieben
setIntHeader(String name, int value) void Der int-Wert wird unter diesem Namen in den Http-Headern gesetzt. Ggf. zuvor gesetzte header dieses Namens werden überschrieben
setStatus(int sc) void Setzt den Statuscode für die Antwort. In JSPs eine untypische Aktion, in Servlets aber durchaus geläufig, wenn die Bearbeitung vom Normalfall abweicht. Im Fehlerfall hingegen kommt eher die Methode setError zur Anwendung

Das Objekt session

Beim session Objekt die häufig genutzten Methoden:

Methode Rückgabewert Kurze Beschreibung
getAttribute(String name) Object Die wohl meist genutzte Methode des session-Objekts. Mit dieser kann man Objekte aus der Session auslesen, die zu einem beliebigen anderen Zeitpunkt der Session hinzugefügt wurden.
getAttributeNames() Enumeration Eigentlich nur sinnvoll zum Debuggen. Hiermit holt man sich eine Enumeration aller Attributnamen der Session. Über diese könnte man nun iterieren, um eine Liste aller Attribute der Session auszugeben.
getCreationTime() long Wenn man wissen will, wann die Session erzeugt wurde, kann man diese Methode nutzen.
getId() String Gibt die eindeutige ID der Session zurück.
getMaxInactiveInterval() int Ermittelt die Zeit, die höchstens vergehen darf, bevor die Session verworfen wird.
getServletContext() ServletContext Der ServletContext, dem diese Session angehört, kann hier abgerufen werden. Damit ist auch klar, dass eine Session immer an eine deployte Applikation gebunden ist und sich nicht über mehrere Anwendungen erstrecken kann.
invalidate() void Beendet diese Session. Eine sehr wichtige Methode! Jede Session kostet Speicherplatz. Sind sehr viele Session gleichzeitig geöffnet, so kann dies bei umfangreicheren Objekten in der Session schnell zu Speicherproblemen führen. invalidate() kann helfen, indem man nicht mehr genutzte Session mittels eines Logout-Vorgangs beendet.
removeAttribut(String name) void Entfernt ein zuvor hinzugefügtes Objekt wieder aus der Session. Als Parameter wird der Attributname angegeben
setAttribute(String name, Object object) void Legt ein Objekt in der Session ab. Zusammen mit getAttribute() die wichtigste Methode der Session.

Das HTTP-Protokoll ist ein sogenanntes zustand loses Protokoll. Das heißt, dass der Server keine Daten über den Nutzer vorrätig hält und diesen sozusagen unmittelbar nach erfolgreicher Absendung seiner Antwort auf die Anfrage des Clients vergisst. Dies ist natürlich für die meisten Web-Anwendungen völlig inakzeptabel. Daher wurden Möglichkeiten gefunden, diese Beschränkung des HTTP-Protokolls zu umgehen und sogenannte Sessions zu ermöglichen. Sessions können einen kompletten Besuch eines Anwenders auf einer Website über alle von ihm aufgesuchten Seiten abbilden. Somit können bspw. Login-Informationen gespeichert werden, oder auch Warenkorb Inhalte.
Das JSP/Servlet-Modell bietet eine umfassende Unterstützung von Sessions einer Benutzerin über eine Abfolge von Seiten. Dafür stellt der Servlet-Container das session Objekt bereit, das vor allem zur Aufnahme von Session-relevanten Informationen genutzt wird. Beliebige Objekte können mittels der o.g. Methode setAttribute() im Session Scope gespeichert und mittels getAttribute(attributnahme) wieder abgerufen werden.

Das Objekt pageContext

Das pageContext Objekt bietet Zugriff auf Informationen, die die aktuelle JSP-Seite betreffen. Es bietet vor allem die Methode, die den bequemen Zugriff auf alle Objekte in jedem Gültigkeitsbereich erlaubt. Das Konzept der Gültigkeitsbereiche (engl. scope) wird im Beitrag Gültigkeitsbereiche ausführlich erläutert. Ansonsten wird das Objekt vor allem bei der Generierung des aus der JSP erzeugten Servlets genutzt.

Das Objekt application

Das application Objekt enthält wenig Methoden, die man von einer JSP aus nutzen würde. Am ehesten sind noch die setAttribute Methode sinnvoll, die Objekte in dem Gültigkeitsbereich Application abgelegt. Im Application Scope können alle, derzeit auf dem Server, befindliche Benutzer zugreifen. Dort könnten z.b. Der Produktkatalog einer Shop Anwendung optimal abgelegt werden, da der Entwickler Systemressourcen(Arbeitsspeicher, Datenbankzugriffe etc.) einspart

Das Objekt config

Das config Objekt ist vom Typ javax.servlet.ServletConfig. Es dient vor allem dazu, auf Initialisierungs-Parameter zuzugreifen. Es ist in der Praxis absolut unbedeutend. Initialisierungs Parameter werden nahezu ausschließlich für Servlets verwandt. Dennoch ist es auch für JSPs möglich, solche Parameter in der Datei web.xml anzulegen. Die wesentliche Methoden sind daher die getInitParameter() Methode, die einen definierten und benannten Initialisierungs Parameter zurückgibt und die getInitParameterNames() Methode, die eine Enumeration mit allen Namen der definierten Initialisierungs-Parameter zurückgibt.
Ein Beispiel für einen definierten Parameter in einer web.xml-Datei:

<?xml version="1.0" encoding="utf-8"?>

<web-app xmlns= ... >

<!-- andere Konfigurationselemente -->

<servlet>
  <servlet-name>ExampleConfigJsp</servlet-name>
  <jsp-file>/newjsp.jsp</jsp-file>
  <init-param>
   <param-name>sampleParm</param-name>
   <param-value>Just a sample value.</param-value>
 </init-param>
 </servlet>

<servlet-mapping>
   <servlet-name>ExampleConfigJsp</servlet-name>
   <url-pattern>/newjsp.jsp</url-pattern>
 </servlet-mapping>

<!-- weitere konfigurationselemente ... -->

</web-app>

Und so kann man diesen in einer JSP auslesen:

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html> 
 <head>
    <title>Config Parameter auslesen config</title>
 </head> 
 <body> 
   <h3>"config"</h3> 
   <p>init-parameter:</p>
   <table border="0" cellspacing="0" style="margin-top:10px; margin-bottom:10px;"> 
 
      <tr> <td><b>sampleParm</b></td><td> </td> <td>
     <%=config.getInitParameter("sampleParm") %></td> 
     </tr> 
   </table> 
</body> 
</html>

Das Objekt out

Das out Objekt kann bis auf einige Ausnahmen eine Expression ersetzen. Du erinnerst dich, das waren die Ausgaben innerhalb eines Skriptlets. Will man innerhalb von Skriptlets Ausgaben erzeugen, so stehen mit dem out Objekt diverse print Methoden zur Verfügung. Die Ausgabe wird dabei zunächst stets gepuffert, um ggf. bei Fehlern den Puffer löschen zu können und bspw. spezielle Ausgaben für den Fehlerfall ausgeben zu können. Ein Forwarding(siehe Actions) oder ein Redirect ist nur möglich, solange der Puffer oder Teile des Puffers noch nicht mittels flush() tatsächlich weggeschrieben wurde.

Methode Rückgabewert Kurze Beschreibung
flush() String schreibt den Puffer in den Outputstream des Response.
print(String) String für die Ausgabe des angegebenen Strings
println() int für die Ausgabe des angegebenen Strings mit
clearBuffer() Throwable Liefert den Fehler, der dafür verantwortlich ist, dass die Fehlerseite angezeigt wird. Damit stehen auch alle Methoden dieses Objekts der JSP zur Verfügung.

Insofern sind neben den diversen print()-Methoden noch die Methoden clear(), bzw. clearBuffer() und flush() wichtig. Letztere schreibt den Pufferinhalt in den Ausgabestrom, wohingegen die beiden ersten den Puffer löschen. Ist bereits ein Teil des Puffers geflusht worden, so wirft die erste Methode eine IOException,während clearBuffer() einfach den gegenwärtigen Pufferinhalt löscht. Die Größe des Puffers setzt man mittels dem Attribut buffer der Page-Direktive.

Das Objekt exception

Dieses Objekt steht nur auf speziellen Fehlerseiten zur Verfügung. Fehlerseiten sind all die Seiten, bei denen das Attribut isErrorPage der page Direktive auf „true“ gesetzt ist.
Diese Seiten dienen dazu, spezielle Antwortseiten für diverse mögliche Fehlerfälle bereitzustellen. Welche Seite aufgerufen wird, bestimmt sich entweder aus dem errorPage Attribut der Page-Direktive oder aus der Konfiguration, die im Deployment-Deskriptor web.xml festgelegt wurde.
Im Falle eines Fehlers wird dann der Request zur passenden Fehler-Seite weitergeleitet und dort kann mittels des exception Objekts auf die Informationen der Exception zugegriffen werden, die zuvor aufgetreten ist. So kann man für die Nutzerin der Seite klare Fehlermeldungen generieren und erspart ihr den ansonsten üblichen Stacktrace. Genaueres zur Fehlerbehandlung und welche Konfigurationen man dazu im Deployment-Deskriptor vornehmen kann, findet sich im Kapitel Fehler- und Ausnahmenbehandlung.
Folgende Methoden des exception Objekts stehen auf einer Fehlerseite zur Verfügung:

Methode Rückgabewert Kurze Beschreibung
getRequestURI() String Gibt den Request-URI des abgesetzten Requests zurück. Wichtig, um festzustellen, wo der Fehler auftrat.
getServletName() String Eine nur mäßig wichtige Methode. Der Servlet-Name ist im Falle einer JSP meist unschön anzuzeigen und u.U. auch zur Auswertung nicht zu gebrauchen, da er auf jedem Fall vom Container ggf. aber zudem sogar vom Zustand zur Zeit der Transformation der JSP in ein Servlet abhängt.
getStatusCode() int Wichtige Methode, um den HTTP-Statuscode zu ermitteln. Sowohl zur Anzeige an die Nutzerin, als auch zur flexiblen Reaktion auf diesen Code gut brauchbar.
getThrowable() Throwable Liefert den Fehler, der dafür verantwortlich ist, dass die Fehlerseite angezeigt wird. Damit stehen auch alle Methoden dieses Objekts der JSP zur Verfügung.

Ein kleines Beispiel: Beachte die page Direktive in beiden jsp Seiten.

<%-- Die jsp hat den Namen handleError.jsp --%>
<%@ page isErrorPage="true" %>

<%-- Zur einfacherer Ausgabe importieren Sie 'PrintWriter' --%>
<%@ page import="java.io.PrintWriter" %>

<html>
<body>
<%-- Hier verwenden Sie die zusätzliche Variable --%>
Es ist zu folgender Ausnahme gekommen: <%= exception %> <br/>
<a href="produceError.jsp"> Erneut versuchen ?! </a> <hr/>

<%-- Zur Ausgabe des Stacktrace in die JSP verwenden Sie
auch hier die vordefinierte Variable 'out'. --%>
Der Stacktrace lautet:
<% exception.printStackTrace(new PrintWriter(out)); %>

</body>
</html>

 

Die Seite die den Fehler provoziert bei Eingabe eines nicht numerischen Werts:

<%-- Hier legen Sie die Fehlerseite fest 
der Name dieser Seite hat den Namen produceError.jsp--%>
<%@ page errorPage="handleError.jsp" %>

<%
// Dieser Code ist fehleranfällig für Falscheingaben
if (request.getParameter("number") != null) {
Double myDouble = new Double(request.getParameter("number"));
}
%>
<!DOCTYPE html>
<html>
 <body>

<!-- Dieses Formular verweist auf sich selbst -->
   <form action="produceError.jsp">
   <p>
     Wenn Sie in das Feld keine Zahl eingeben,
     provozieren Sie einen Fehler:
     </p>

  Eingabe: <input type="text" name="number" />
          <input type="submit" value="Absenden" />
   </form>
 </body>
</html>

0 Kommentare

Schreibe einen Kommentar

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