wtp+tomcat – Tutorial #2: Status-Servlet

In Teil 1 des wtp+tomcat – Tutorials ging es in erster Linie darum, die Umgebung in Gang zu bringen, ein leeres Projekt zu erzeugen und mittels einer einfachen JSP-Datei zu demonstrieren, daß die Dinge so zusammenspielen, wie sie sollen. Vermutlich läßt sich, mit diesen Technologien bewaffnet, schon eine große Menge der Anwendungsfälle prinzipiell abdecken. Ob das allerdings immer besonders elegant und/oder sinnvoll ist, steht auf einem anderen Blatt. Dafür hat die JEE in der Web-Schicht noch mehr interessante Dinge zu bieten…

… wie zum Beispiel Servlets. Ohne allzu sehr in die Details der Technologie selbst einzutauchen zu wollen, liegt die folgende Analogie nahe: Während JSPs im Wesentlichen (ähnlich dem, was leider mit PHP arg weit verbreitet ist) (X)HTML-Dateien potentiell durchsetzt mit Java-Code sind, stellen Servlet im Wesentlichen Java-Klassen dar, vermengt schlimmstenfalls mit XHTML-Markup zur Ausgabe von Inhalten. Das Erzeugen und Publizieren von Servlet-Klassen erfordert prinzipbedingt einen geringen Mehraufwand, der aber auch mit den Webtools recht gut handhabbar wird.

Voraussetzungen

… erweiternd zu den Dingen, die schon in Teil 1 angemerkt wurden:

  • Es wird auf die Projektstruktur des ersten Teils weiter aufgebaut. Alternativ darf es auch ein leeres neues Web-Projekt sein.
  • Für den weiteren Umgang mit Servlets sollten die Begrifflichkeiten und Konzepte von HTTP bekannt sein, der entsprechende wikipedia-Eintrag läßt diesbezüglich kaum Wünsche offen.
  • Um in die Tiefe zu gehen und mit Servlets „richtig“ zu arbeiten, sollte man die javadocs der Servlet-API lokal installiert und strukturell überflogen haben.

Analog dem „Hallo-Welt“ – Paradigma wollen wir ein erstes Servlet erzeugen, welches, durch einen Client gerufen, den Nutzer erst einmal nur wissen läßt, daß es existiert und arbeitet. Als denn…

Erzeugung des Servlets

Der Einfachheit halber wird ausgegangen vom Projekt foobar aus dem ersten Teil des Tutorials. Es sind verschiedene Möglichkeiten denkbar, eine Java-Klasse (die ein Servlet letztlich ja ist) neu zu erzeugen; wir wollen sinnvollerweise die Werkzeuge des WTP benutzen. Mithin: Rechtsklick auf „foobar“ -> „New“ -> „Servlet:

Servlet-Neu

Der darauf folgende Dialog erlaubt uns sehr viel mehr Eingaben als dereinst bei der Erzeugung einer JSP; wir wollen uns zunächst auf die wesentlichen Informationen beschränken, einen Paketnamen (wtp.tut) und den obligatorischen Klassen-Namen für das Servlet (StatusServlet – im Grunde kann der Name frei gewählt werden, indes schadet es auch nicht, sich an die in den Java-Blueprints definierten Naming-Conventions zu halten, die für Servlet-Klassen den Suffix „Servlet“ im Klassen-Namen wünschen) vergeben und die Erzeugung der Klasse mit „Finish“ abschließen:

Servlet-Neu-Parameter

Alle anderen Einstellungen sollten dabei unverändert übernommen werden. Danach greift wiederum das WTP-Tooling, findet sich im Workspace die neue Servlet-Klasse sowohl als Eintrag im Project Explorer (als Eintrag im Deployment Descriptor bzw. als Java-Klasse) als auch als geöffneter Editor:

Servlet-Workspace

Status-Code
Wir werden mit einem Browser auf das Servlet zugreifen, erwarten mithin, daß das Servlet seine Ausgabe als Antwort auf eine HTTP-GET – Anfrage schickt, und wissen somit, daß unser (wieder relativ knapp bemessener) Test-Code in die Funktion doGet in der Servlet-Klasse gehört:

Servlet-Get

Zur Erinnerung (bzw. Einführung, je nach Standpunkt): Innerhalb der do... – Methoden in der Servlet-Klasse stehen zwei Objekte als Input-Parameter zur Verfügung – der HttpServletRequest request, der die Client-Anfrage an den Server (einschließlich aller Parameter, Header, …) beinhaltet, und HttpServletResponse response, analog beinhaltend die Antwort, die vom Server an den Client zurückgeliefert wird. Für das Demo-Servlet fügen wir innerhalb von doGet die Zeile response.getWriter().write("alive and well on "+request.getServerName()); ein, die beide Objekte zur Erzeugung unseres Status verwendet:

Servlet-Get

Damit sind wir eigentlich schon durch und können das Projekt (analog Teil 1) auf dem Tomcat-Server ausführen lassen. Nach dem Start des Servers wird der integrierte Web-Browser uns zunächst die Start-Seite (index.jsp ... des Projektes anzeigen; erst wenn wir der URL den Namen unseres Servlets anhängen (http://localhost:8080/foobar/StatusServlet), sehen wir das, was wir von unserem Status-Servlet erwartet haben:

Servlet-Ausfuehren

Mappings
Hier könnte man es im Grunde belassen – automatisch generiert, ist das Servlet über die URL http://'server'[:port]/'projekt'/'Klasse'Servlet erreich- und damit verwendbar. Aber das ist noch nicht sonderlich hübsch – jeder, der gängige Web-Anwendungen auf JEE-Systemen (auf welchem Web-Server eine Anwendung ruht, läßt sich übrigens mit der Firefox-Erweiterung ServerSpy recht einfach feststellen …) kennt, weiß, daß die URLs doch meistens „griffiger“, einprägsamer als die unsere sind.

JEE kennt hierfür das Konzept des Servlet-Mappings. Über diese werden eingehende Anfragen an Servlets weitergeleitet basierend auf vorkonfigurierten URL-Mustern, auf die der Anfrage-String paßt (oder auch nicht). Dies finden wir in der Datei web.xml, die wir im Projekt in „WebContent/WEB-INF/“ finden:

Servlet-Mapping

Wir sehen:

  • Zunächst ist innerhalb der XML-Datei ein servlet – Element definiert, welches die Klasse unseres Status-Servlets (wtp.tut.StatusServlet) dem Namen StatusServlet zuordnet.
  • Danach findet sich ein servlet-mapping – Element (hervorgehoben). Innerhalb desselben wird das StatusServlet an das URL-Muster /StatusServlet gebunden, welches wir im ersten Testlauf ausgeführt haben.

Wir wollen nun, daß unser Servlet statt der etwas „klobigen“ URL lieber auf das „elegantere“ (…) http://localhost:8080/foobar/status/ reagiert. Dafür ändern wir die Mapping-Deklaration in web.xml entsprechend ab:

Servlet-Mapping 2

Nach Abspeichern von web.xml und Neustart des Servers sollte sich der erwartete Effekt herbeiführen lassen:

Servlet-Start 2

Statt die Servlet-Mappings im Nachgang händisch zu ändern, hätten wir dies übrigens auch gleich im Rahmen der Erzeugung definieren können, so wir denn nicht gleich nach Definition des Servlet-Klassennamens mit „Finish“ den kurzen Weg gewählt, sondern den langen gegangen und sämtliche noch kommenden Fragen beantwortet hätten. Aber im Sinne der Erklärung halte ich den gegangenen Weg für den ersten Versuch für geeigneter.

Fazit und Ausblick
Wir wissen nun, wie man in Eclipse in einem Web-Projekt ein Servlet einfügt und die URL, auf die dieses reagiert, konfiguriert. Zudem haben wir kurz gesehen, wie aus einem Servlet heraus Text ausgegeben werden kann, was potentiell auch für die Ausgabe ganzer HTML-Dokumente verwendet werden könnte, aber nicht sollte. Im nächsten Teil werden wir uns einen eleganteren Weg ansehen, Informationen in einem Servlet bereitzustellen und über eine JSP zur Anzeige zu bringen, und dabei auch Einsicht nehmen in die Art und Weise, wie in Eclipse/WTP zusätzliche Java-Klassen (etwa in *.jar-Dateien) in ein Web-Projekt eingebunden werden. More to come.

Lesestoff

  • etwas älteres, aber empfehlenswertes Tutorial zur Servlet-Technologie auf dem Server der Uni Hannover (den Part, in dem massiv Inline-HTML erzeugt wird, sollte man geflissentlich überfliegen);
  • ein ebenfalls schon etwas älteres, aber für einen groben Einstieg sehr geeignetes (zudem deutsches) Papier zum Thema im Webspace der TU Chemnitz,
  • ‚Servlet Essentials‘, ein vollständig online lesbares, ebenfalls schon betagtes (1999) eBook zu Servlets, lesenswert insbesondere wegen des knappen Architektur-Abrisses von Servlets im Kontext von HTTP und CGI,
  • ‚Servlet Basics‘-Kursunterlagen im J2EE-Teil von javapassion.com

3 Replies to “wtp+tomcat – Tutorial #2: Status-Servlet”

  1. D B Ekanayake sagt:

    please translate this into English and publish in your site

    Thank You

    DB

  2. pierre sagt:

    Ya bitte ! Teil 1 ist auf english, und Deutsche Sprache, schwere Sprache !

  3. Aldjinn sagt:

    Was ist das für ein „graphischer“ XML Editor in den letzten Screenshots?

Comments are closed.