1. Allgemeines

Die PDF des Dokuments ist verfügbar |HIER|.

1.1. Ziele

Hier soll eine Entwicklungsmethode namens STRUTS vorgestellt werden. Jakarta Struts ist ein Projekt der Apache Software Foundation (www.apache.org), dessen Ziel es ist, ein Standard-Entwicklungsframework für Webanwendungen in Java bereitzustellen, das der sogenannten MVC-Architektur (Model-View-Controller) entspricht.

1.2. Das MVC-Modell

Das MVC-Modell zielt darauf ab, die Schichten Präsentation, Verarbeitung und Datenzugriff voneinander zu trennen. Eine Webanwendung, die diesem Modell entspricht, ist wie folgt aufgebaut:

Eine solche Architektur wird als 3-Tier- oder 3-Schichten-Architektur bezeichnet:

Die Benutzeroberfläche ist das V (die Ansicht)
die Anwendungslogik ist das C (der Controller)
die Datenquellen sind das M (Modell)

Die Benutzeroberfläche ist häufig ein Webbrowser, es kann sich jedoch auch um eine eigenständige Anwendung handeln, die über das Netzwerk Anfragen an den Webdienst sendet und die von diesem zurückgesendeten Ergebnisse aufbereitet. Die Anwendungslogik besteht aus Skripten, die die Anfragen des Benutzers verarbeiten. Die Datenquelle ist oft eine Datenbank, es können aber auch einfache Textdateien, ein Verzeichnis LDAP, ein entfernter Webdienst usw. sein. Der Entwickler sollte darauf achten, eine weitgehende Unabhängigkeit zwischen diesen drei Komponenten zu wahren, damit bei einer Änderung an einer Komponente die beiden anderen nicht oder nur in geringem Umfang angepasst werden müssen.

Versucht man, dieses Modell mit Servlets und JSP-Seiten umzusetzen, ergibt sich folgende Architektur:

Im Block [Logique Applicative] unterscheidet man

das Servlet, das als Einstiegspunkt der Anwendung dient und auch als Controller bezeichnet wird,
den Block [Classes métier], der die für die Anwendungslogik erforderlichen Java-Klassen enthält.
den Block [Classes d'accès aux données], der Java-Klassen enthält, die erforderlich sind, um die für das Servlet notwendigen Daten abzurufen – häufig persistente Daten (BD, Dateien, Dienst WEB, …)
der Block der Seiten JSP, der die Ansichten der Anwendung bildet.

1.3. Ein Entwicklungsansatz MVC unter Verwendung von Servlets und Seiten JSP

Wir haben einen Ansatz für die Entwicklung von Java-Webanwendungen definiert, der dem oben genannten Modell MVC entspricht. Wir möchten ihn hier noch einmal zusammenfassen.

Zunächst werden alle Ansichten der Anwendung definiert. Dabei handelt es sich um die Webseiten, die dem Benutzer angezeigt werden. Bei der Gestaltung der Ansichten versetzen wir uns daher in die Perspektive des Benutzers. Man unterscheidet drei Arten von Ansichten:
- das Eingabeformular, das dazu dient, Informationen vom Benutzer zu erfassen. Dieses verfügt in der Regel über eine Schaltfläche, um die eingegebenen Informationen an den Server zu senden.
- die Antwortseite, die ausschließlich dazu dient, dem Benutzer Informationen zu liefern. Diese verfügt oft über einen Link, über den der Benutzer die Anwendung mit einer anderen Seite fortsetzen kann.
- die gemischte Seite: Das Servlet hat dem Client eine Seite mit von ihm generierten Informationen gesendet. Diese Seite dient dem Client dazu, dem Servlet weitere Informationen zur Verfügung zu stellen.

Jede Ansicht erzeugt eine Seite mit der Bezeichnung JSP. Für jede dieser Seiten:
- wird das Erscheinungsbild der Seite gestaltet
- wird festgelegt, welche Teile davon dynamisch sind:
  - die für den Benutzer bestimmten Informationen, die vom Servlet als Parameter an die Ansicht JSP übergeben werden müssen
  - die Eingabedaten, die zur Verarbeitung an das Servlet übermittelt werden müssen. Diese müssen Teil eines Formulars HTML sein.

Man kann die Ein- und Ausgänge jeder Ansicht schematisch darstellen

Die Eingaben sind die Daten, die das Servlet der Seite JSP bereitstellen muss, entweder in der Anfrage (Request) oder in der Sitzung (Session).
Die Ausgänge sind die Daten, die die Seite JSP an das Servlet übergeben muss. Sie sind Teil eines Formulars HTML, und das Servlet ruft sie über eine Operation vom Typ request.getparameter(...) ab.

Wir schreiben den Java-Code/JSP für jede Ansicht. Er hat meist die folgende Form:

<%@ page ... %>    // häufigste Klassenimporte
<%!
     // Instanzvariablen der Seite JSP (=globale Variablen)
     // nur erforderlich, wenn die Seite JSP Methoden enthält, die Variablen gemeinsam nutzen (selten)     
    ...    
%>
<%
     // Abruf der vom Servlet gesendeten Daten
     // entweder in der Anfrage (Request) oder in der Sitzung (Session)
    ...
%>

<html>
...
         // Hier wird versucht, den Java-Code zu minimieren
</html>

Nun können die ersten Tests durchgeführt werden. Die im Folgenden erläuterte Bereitstellungsmethode gilt speziell für den Tomcat-Server:

Der Anwendungskontext muss in der Tomcat-Datei „server.xml“ angelegt werden. Man kann zunächst diesen Kontext testen. Sei C dieser Kontext und „DC“ der zugehörige Ordner. Wir erstellen eine statische Datei test.html, die wir im Ordner DC ablegen. Nach dem Start von Tomcat rufen wir mit einem Browser die Seite URL unter http://localhost:8080/DC/test.html auf.
Jede Seite JSP kann getestet werden. Wenn eine Seite JSP den Namen formulaire.jsp trägt, wird mit einem Browser die Seite URL unter http://localhost:8080/DC/formulaire.jsp aufgerufen. Die Seite JSP erwartet Werte von dem Servlet, das sie aufruft. Da wir sie hier direkt aufrufen, erhält sie die erwarteten Parameter nicht. Damit die Tests dennoch möglich sind, initialisieren wir die erwarteten Parameter auf der Seite JSP selbst mit Konstanten. Diese ersten Tests ermöglichen es, zu überprüfen, ob die Seiten JSP syntaktisch korrekt sind.

Anschließend schreiben wir den Code für das Servlet. Dieses verfügt über zwei klar voneinander getrennte Methoden:

die Methode „init“, die dazu dient:
- das Abrufen der Konfigurationsparameter der Anwendung aus der Datei web.xml
- gegebenenfalls Instanzen von Geschäftsklassen zu erstellen, die sie später verwenden wird
- eine eventuelle Liste von Initialisierungsfehlern zu verwalten, die an zukünftige Nutzer der Anwendung zurückgemeldet wird. Diese Fehlerbehandlung kann bis zum Versand einer E-Mail an den Administrator der Anwendung reichen, um ihn über eine Fehlfunktion zu informieren
die Methode doGet oder doPost, je nachdem, wie das Servlet seine Parameter von den Clients erhält. Wenn das Servlet mehrere Formulare verarbeitet, ist es sinnvoll, dass jedes davon eine Information übermittelt, die es eindeutig identifiziert. Dies kann mithilfe eines versteckten Attributs im Formular vom Typ <input type="hidden" name="action" value="..."> erfolgen. Das Servlet kann zunächst den Wert dieses Parameters auslesen und anschließend die Bearbeitung der Anfrage an eine interne, private Methode delegieren, die für die Bearbeitung dieser Art von Anfragen zuständig ist.
Man sollte es so weit wie möglich vermeiden, Geschäftslogik in das Servlet zu schreiben. Dafür ist es nicht vorgesehen. Das Servlet ist eine Art Teamleiter (Controller), der Anfragen von seinen Kunden (Web-Clients) entgegennimmt und diese von den am besten geeigneten Personen (den Geschäftsklassen) ausführen lässt. Beim Schreiben des Servlets wird die Schnittstelle der zu erstellenden Geschäftsklassen festgelegt (Konstruktoren, Methoden). Dies gilt, sofern diese Geschäftsklassen erst erstellt werden müssen. Sind sie bereits vorhanden, muss sich das Servlet an die bestehende Schnittstelle anpassen.
Der Code des Servlets wird kompiliert.

Das Grundgerüst der für das Servlet erforderlichen Geschäftsklassen wird erstellt. Wenn das Servlet beispielsweise ein Objekt vom Typ proxyArticles verwendet und diese Klasse eine Methode getCodes haben muss, die eine Liste (ArrayList) von Zeichenketten zurückgibt, reicht es zunächst aus, Folgendes zu schreiben:

public ArrayList getCodes(){
    String[] codes= {"code1","code2","code3"};
    ArrayList aCodes=new ArrayList();
    for(int i=0;i<codes.length;i++){
        aCodes.add(codes[i]);
    }
        return aCodes;
}

Nun können wir mit den Tests des Servlets fortfahren.

Die Konfigurationsdatei web.xml der Anwendung muss angelegt werden. Sie muss alle Informationen enthalten, die von der init-Methode des Servlets erwartet werden (<init-param>). Außerdem wird das URL festgelegt, über das das Haupt-Servlet erreicht wird (<servlet-mapping>).
Alle erforderlichen Klassen (Servlet, Fachklassen) werden in WEB-INF/classes abgelegt.
Alle erforderlichen Klassenbibliotheken (.jar) werden im Verzeichnis WEB-INF/lib abgelegt. Diese Bibliotheken können Fachklassen, Treiber JDBC usw. enthalten.
Die Ansichten JSP werden im Stammverzeichnis der Anwendung oder in einem eigenen Ordner abgelegt. Gleiches gilt für die anderen Ressourcen (HTML, Bilder, Audio, Videos, …)
Anschließend wird die Anwendung getestet und erste Fehler behoben. Am Ende dieser Phase ist die Architektur der Anwendung betriebsbereit. Diese Testphase kann schwierig sein, da es für Tomcat kein Debugging-Tool gibt. Dazu müsste Tomcat selbst in ein Entwicklungstool (JBuilder Developer, Sun One Studio, …) integriert sein. Man kann sich dabei der Anweisungen System.out.println("....") bedienen, die in das Tomcat-Fenster schreiben. Als Erstes muss überprüft werden, ob die Methode „init“ alle Daten aus der Datei web.xml korrekt abruft. Dazu kann man deren Werte in das Tomcat-Fenster ausgeben. Auf die gleiche Weise überprüft man, ob die Methoden doGet und doPost die Parameter der verschiedenen Formulare HTML der Anwendung korrekt abrufen.

Man schreibt die Fachklassen, die das Servlet benötigt. Dabei handelt es sich in der Regel um die klassische Entwicklung einer Java-Klasse, die meist unabhängig von einer Webanwendung ist. Diese wird zunächst außerhalb dieser Umgebung getestet, beispielsweise mit einer Konsolenanwendung. Sobald eine Fachklasse geschrieben wurde, kann man sie in die Bereitstellungsarchitektur der Webanwendung integrieren und ihre korrekte Einbindung darin testen. Auf diese Weise wird für jede Fachklasse vorgegangen.

1.4. Der Entwicklungsansatz STRUTS

Die Entwickler der Methodik STRUTS haben versucht, eine Standard-Entwicklungsmethode zu definieren, die die Architektur MVC für in Java geschriebene Webanwendungen berücksichtigt. Das Projekt STRUTS umfasst zwei Aspekte:

die Entwicklungsmethode. Wir werden sehen, dass sie der oben für Servlets und Seiten beschriebenen Methode recht ähnlich ist JSP
die Werkzeuge, mit denen wir diese Entwicklungsmethode anwenden können. Dabei handelt es sich um Java-Klassenbibliotheken, die auf der Website der Apache-Stiftung (www.apache.org) zu finden sind.

1.4.1. Die Entwicklungsmethode

Die von STRUTS verwendete Architektur MVC sieht wie folgt aus:

Der Controller ist das Herzstück der Anwendung. Alle Anfragen des Clients laufen über ihn. Es handelt sich um ein generisches Servlet, das von STRUTS bereitgestellt wird. In bestimmten Fällen kann es erforderlich sein, dieses Servlet zu ableiten. In einfachen Fällen ist dies jedoch nicht notwendig. Dieses generische Servlet bezieht die benötigten Informationen aus einer Datei, die meist den Namen struts-config.xml trägt.
Enthält die Anfrage des Kunden Formularparameter, werden diese in ein Bean-Objekt übertragen. Eine Klasse wird als Bean-Klasse bezeichnet, wenn sie bestimmte Konstruktionsregeln befolgt, auf die wir später noch eingehen werden. Die im Laufe der Zeit so erstellten Bean-Objekte werden in der Sitzung oder der Anfrage des Kunden gespeichert. Dieser Punkt ist konfigurierbar. Sie müssen nicht neu erstellt werden, wenn sie bereits vorhanden sind.
In der Konfigurationsdatei struts-config.html werden jedem URL, das programmgesteuert verarbeitet werden soll (und somit keiner JSP-Ansicht entspricht, die direkt angefordert werden könnte), bestimmte Informationen zugeordnet:
- den Namen der Action-Klasse, die für die Bearbeitung der Anfrage zuständig ist. Auch hier kann das instanziierte Action-Objekt in der Sitzung oder der Anfrage gespeichert werden.
- Wenn die angeforderte URL parametrisiert ist (z. B. beim Absenden eines Formulars an den Controller), wird der Name des Beans angegeben, das für die Speicherung der Formularinformationen zuständig ist.
Ausgestattet mit diesen Informationen aus seiner Konfigurationsdatei kann der Controller beim Empfang einer Anfrage nach URL durch einen Client feststellen, ob und welche Bean erstellt werden muss. Nach der Instanziierung kann die Bean überprüfen, ob die von ihr gespeicherten Daten, die aus dem Formular stammen, gültig sind oder nicht. Eine Methode der Bean namens „validate“ wird automatisch vom Controller aufgerufen. Die Bean wird vom Entwickler erstellt. Dieser fügt daher in die Methode „validate“ den Code ein, der die Gültigkeit der Formulardaten überprüft. Erweisen sich die Daten als ungültig, fährt der Controller nicht fort. Er übergibt die Kontrolle an eine Ansicht, deren Namen er in seiner Konfigurationsdatei findet. Der Austausch ist damit beendet. Es ist zu beachten, dass der Entwickler festlegen kann, dass die Gültigkeit des Formulars nicht überprüft wird. Dies tut er ebenfalls in der Datei „struts-config.html“. In diesem Fall ruft der Controller die Methode „validate“ der Bean nicht auf.
Sind die Daten des Beans korrekt, findet keine Überprüfung statt oder ist kein Bean vorhanden, übergibt der Controller die Kontrolle an das Action-Objekt, das mit der Datei URL verknüpft ist. Dies geschieht, indem er die Ausführung der Methode `execute` dieses Objekts anfordert und dabei die Referenz der Bean übergibt, die er gegebenenfalls erstellt hat. An dieser Stelle führt der Entwickler die erforderlichen Schritte aus: Er muss gegebenenfalls auf Geschäftsklassen oder Datenzugriffsklassen zurückgreifen. Am Ende der Verarbeitung übergibt das Action-Objekt dem Controller den Namen der Ansicht, die er als Antwort an den Client senden soll.
Der Controller sendet diese Antwort. Der Austausch mit dem Client ist beendet.

Die Entwicklungsmethodik STRUTS nimmt Gestalt an:

die Definition der Ansichten. Man unterscheidet zwischen Ansichten, die Formulare sind, und den übrigen.
- Jede Formularansicht führt zu einer Definition in der Datei struts-config.xml. Dort werden folgende Informationen definiert:
  - den Namen der Bean-Klasse, die die Formulardaten enthält, sowie die Angabe, ob die Daten überprüft werden sollen oder nicht. Wenn sie überprüft werden sollen und sich als ungültig erweisen, muss in diesem Fall die Ansicht angegeben werden, die als Antwort an den Client gesendet werden soll.
  - den Namen der Action-Klasse, die für die Verarbeitung des Formulars zuständig ist.
  - den Namen aller Ansichten, die nach der Verarbeitung der Anfrage als Antwort an den Client gesendet werden können. Die Action-Klasse wählt je nach Ergebnis der Verarbeitung eine davon aus.
- Jede Ansicht ist Gegenstand einer Seite JSP. Wir werden sehen, dass in den Ansichten – insbesondere in den Formularansichten – manchmal eine Struts-spezifische Tag-Bibliothek verwendet wird.
Das Schreiben der JavaBean-Klassen, die den Formularansichten entsprechen
das Erstellen der Action-Klassen, die für die Verarbeitung der Formulare zuständig sind
das Erstellen eventueller Fach- oder Datenzugriffsklassen

1.4.2. Die Entwicklungswerkzeuge STRUTS

Das Projekt STRUTS ist eines der Projekte der Apache Software Foundation. Mehrere dieser Projekte sind unter dem Namen Jakarta zusammengefasst und stehen unter der Adresse URL http://jakarta.apache.org zur Verfügung:

Es empfiehlt sich, diese Seite zu lesen. Viele dieser Projekte sind für Java-Entwickler von Interesse. Wenn wir dem obigen Link zu Struts folgen, gelangen wir zur Startseite des Projekts:

Auch hier empfiehlt es sich, die Startseite zu lesen. Um die Java-Bibliotheken von Struts herunterzuladen, folgen wir dem oben angegebenen Link „Binaries“:

Für Windows verwenden wir den Link „1.1.zip“ und für Unix den Link „1.1.tar.gz“ (Nov. 2003). Nach dem Entpacken der Datei „1.1.zip“ erhalten wir folgende Verzeichnisstruktur:

In dieser Verzeichnisstruktur befinden sich die für die Entwicklung erforderlichen Java-Klassenbibliotheken STRUTS. Diese liegen in .jar- oder .war-Dateien vor, die mit .zip-Dateien vergleichbar sind. Sie können mit denselben Dienstprogrammen geöffnet werden. Die meisten der benötigten Bibliotheken befinden sich im oben genannten Ordner „lib“:

Neben den .jar-Klassenbibliotheken befinden sich .dtd-Dateien (Document Type Definition), die Gültigkeitsregeln für XML-Dateien enthalten. Eine XML-Datei kann in ihrem Inhalt auf eine solche DTD-Datei verweisen. Das Programm (als Parser bezeichnet), das den Inhalt der Datei XML analysiert, verwendet die in der referenzierten Datei DTD enthaltenen Gültigkeitsregeln, um festzustellen, ob die Datei XML syntaktisch korrekt ist. So legt beispielsweise die Datei „struts-config_1_1.dtd“ die Regeln für den Aufbau der Konfigurationsdatei „struts-config.xml“ für die Struts-Version 1.1 fest.

Sehen wir uns nun an, wo die verschiedenen Elemente der Struts-Verzeichnisstruktur platziert werden müssen, um eine Struts-Anwendung auf dem Tomcat-Server bereitzustellen.

1.5. Bereitstellung einer Struts-Anwendung

Eine Struts-Anwendung ist eine Webanwendung wie jede andere. Sie folgt daher den Bereitstellungsregeln des Containers, in dem sie ausgeführt wird. Hier wird eine Anwendung, die wir „strutspersonne“ nennen, von einem Tomcat-Server der Version 4.x ausgeführt. Im Anhang finden Sie die Vorgehensweise für die Bereitstellung unter Tomcat Version 5.x. Wir befolgen hier die Bereitstellungsregeln von Tomcat 4.x:

Wir definieren den Kontext „strutspersonne“ in der Tomcat-Konfigurationsdatei server.xml:

                <Context path="/strutspersonne" docBase="e:/data/serge/web/struts/personne" />

Anschließend starten wir Tomcat gegebenenfalls neu, damit der neue Kontext berücksichtigt wird. Wir können die Gültigkeit des Kontexts überprüfen, indem wir die Seite URL http://localhost:8080/strutspersonne aufrufen:

Wenn keine Fehlerseite angezeigt wird, ist der Kontext korrekt.

Wir erstellen im physischen Ordner, der dem Kontext „strutspersonne“ zugeordnet ist, den Unterordner „WEB-INF“.
Im Ordner „WEB-INF“ der Anwendung definieren wir die Konfigurationsdatei „web.xml“ der Anwendung:

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE web-app
    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
    "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>
    <servlet>
      <servlet-name>action</servlet-name>
    <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
    <init-param>
        <param-name>config</param-name>
      <param-value>/WEB-INF/struts-config.xml</param-value>
    </init-param>
  </servlet>

  <servlet-mapping>
      <servlet-name>action</servlet-name>
    <url-pattern>*.do</url-pattern>
  </servlet-mapping>

</web-app>

Die Controller-Klasse (Servlet) der Anwendung ist eine vordefinierte Stuts-Klasse namens ActionServlet. Sie befindet sich in der Datei struts.jar. Damit Tomcat diese Klasse finden kann, legen wir die Datei struts.jar im Ordner <tomcat>\common\lib ab, der zu den Ordnern gehört, die Tomcat bei der Suche nach Klassen durchsucht. Tatsächlich werden wir dort alle .jar-Dateien ablegen, die sich im Ordner <struts>\lib befinden, wobei <struts> das Stammverzeichnis der Struts-Verzeichnisstruktur ist.

Außerdem werden die Dateien struts-el.jar und jstl.jar aus dem Ordner <struts>\contrib\struts-el\lib dort abgelegt:

Hier haben wir Zugriff auf den Webserver. Das ist jedoch nicht immer der Fall. Wenn eine Web-/Java-Anwendung in einem Webcontainer bereitgestellt wird, den man nicht selbst verwaltet, ist es ratsam, dass die Anwendung alle benötigten Bibliotheken mitbringt. Diese müssen dann in den Ordner WEB-INF/lib abgelegt werden, der zuvor angelegt werden muss.
Wir haben darauf hingewiesen, dass der Controller eine Reihe von Informationen benötigt, die er normalerweise in einer Datei namens struts-config.xml findet, die sich im selben Ordner wie web.xml befindet. Tatsächlich ist der Name dieser Datei konfigurierbar. Der oben genannte Parameter „config“ legt diesen Namen fest.
Das Tag <servlet-mapping> gibt an, dass der Controller über alle URL-Dateien erreicht wird, die mit der Endung .do enden. Diese Zuordnung wird von Struts benötigt. Diese URL-Dateien werden anschließend vom Controller gefiltert, der nur die URL-Dateien akzeptiert, die in seiner Konfigurationsdatei struts-config.xml deklariert sind.

Vorerst reicht unsere Datei web.xml aus.

Wir werden die URL /main.do von der Anwendung „strutspersonne“ anfordern. Gemäß der vorherigen Datei web.xml wird diese URL daher an das Servlet org.apache.struts.action weitergeleitet. Die Klasse ActionServlet wird instanziiert und ihre Methode „init“ aufgerufen. Diese versucht, die durch den Parameter „config“ definierte Konfigurationsdatei zu lesen. Diese muss also vorhanden sein. Wir erstellen die folgende Datei struts-config.xml:

<?xml version="1.0" encoding="ISO-8859-1" ?>

<!DOCTYPE struts-config PUBLIC
          "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN"
          "http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">

<struts-config>
    <action-mappings>
      <action
          path="/main"
          parameter="/main.html"
          type="org.apache.struts.actions.ForwardAction"
      />
    </action-mappings>
</struts-config>

Beachten Sie, dass die Datei „DTD“ von „struts-config.xml“ nicht mit der Datei „web.xml“ identisch ist, was darauf hindeutet, dass sie nicht dieselbe Struktur aufweisen. Für jede URL, die der Controller verarbeiten soll, müssen wir ein <action>-Tag definieren. Dieses dient dazu, dem Controller mitzuteilen, was er tun soll, wenn er nach dieser URL gefragt wird. Hier geben wir folgende Elemente an:

path="/main": Definiert den Namen der durch das <action>-Tag konfigurierten URL. Das Suffix .do ist implizit.
type="org.apache.struts.actions.ForwardAction": Definiert den Namen der Action-Klasse, die die Anfrage bearbeiten soll. Hier wird eine in Struts vordefinierte Action-Klasse verwendet. Sie führt selbst keine Aktion aus, sondern leitet die Anfrage des Clients an die im Attribut „parameter“ angegebene URL weiter.
parameter="/main.html": Der Name der URL, an die die Anfrage weitergeleitet werden soll. Hier handelt es sich um eine statische HTML-Datei.

Zusammenfassend lässt sich sagen: Wenn der Benutzer die Datei URL /main.do anfordert, erhält er die Datei URL /main.html.

Die Datei main.html sieht wie folgt aus:

<html>
    <head>
      <title>Application strutspersonne</title>
  </head>
  <body>
      Application strutspersonne active ....
  </body>
</html>

Diese Datei befindet sich im Ordner „strutspersonne/vues“ der Anwendung:

Sie kann direkt über die Funktion URL http://localhost:8080/strutspersonne/main.html abgerufen werden:

Hier ist der Struts-Controller der Anwendung nicht eingegriffen, da er nur dann aktiv wird, wenn die URL vom Typ *.do angefordert wird. Hier wurde jedoch die URL /vues/main.html angefordert.

Die zuvor erstellte Datei „struts-config.xml“ muss in denselben Ordner „WEB-INF“ wie die Datei „web.xml“ verschoben werden:

Wir werden nun die ordnungsgemäße Funktion des Controllers der Anwendung „strutspersonne“ überprüfen, indem wir die Dateien URL und main.do aufrufen, nachdem wir Tomcat gegebenenfalls neu gestartet haben.

Hier ist der Struts-Controller zum Einsatz gekommen, da wir eine URL vom Typ *.do angefordert haben. Wir haben tatsächlich die erwartete Seite (main.html) erhalten. Wir verfügen somit über die grundlegenden Elemente für den Betrieb unserer Anwendung: den Struts-Kontext „strutspersonne“, die Konfigurationsdateien web.xml und struts-config.xml sowie die Struts-Bibliotheken.

Was wäre passiert, wenn wir eine URL vom Typ /toto.do angefordert hätten? Laut der Konfigurationsdatei web.xml der Anwendung „strutspersonne“ wird in diesem Fall der Struts-Controller aufgerufen, um die Anfrage zu bearbeiten. Dieser überprüft daraufhin seine Konfigurationsdatei struts-config.html und findet keine Konfiguration für den Typ URL /toto. Was macht er dann? Versuchen wir es:

Wir erhalten eine Fehlerseite, was normal erscheint. Nun können wir uns mit dem Schreiben einer Anwendung befassen.