Einführung in die Beispielanwendung Directory Listing

Diese Seite ist der Ausgangspunkt der Informationen zur Beispielanwendung Directory Listing. Die Einführung ist in folgende Abschnitte untergliedert:

Übersicht

Die Beispielanwendung Directory Listing wurde erstellt, um die Verwendung des Speichers "dojox.data.FileStore" aus Dojo Toolkit for JavaScript zu erweitern. Die Beispielanwendung Directory Listing demonstriert, wie eine JAX-RS-REST-Anwendung (Representational State Transfer) entwickelt wird, die Anforderungen, die vom Datenspeicher "dojox.data.FileStore" stammen, empfangen und auf diese reagieren kann.

Der Datenspeicher "dojox.data.FileStore" ist eine schlanke JavaScript-Implementierung für den Zugriff auf die Details eines fernen Dateisystems. Dieser Datenspeicher und die serverseitige JAX-RS-Ressource blähen die Hierarchie des angeforderten Dateisystempfads nicht auf. Auf diese Weise können Informationen für den angeforderten Pfad schnell zurückgegeben und gleichzeitig Hooks für das verzögerte Laden der Unterverzeichnisse bereitgestellt werden. Dieses Beispiel veranschaulicht, wie ein Dojo-Datenspeicher verzögerte Ladeoperationen durchführen kann und wie die JAX-RS-Ressource erstellt wird, die den Erwartungen von dojox.data.FileStore entspricht.

Primärer Zweck der Beispielanwendung Directory Listing ist, die Einfachheit und Leistungsfähigkeit der JAX-RS-Ressourcenklasse zu demonstrieren. Um diese Einfachheit vollständig zu demonstrieren, wird der Datenspeicher "dojox.data.FileStore" jedoch in eine größere Dojo-Anwendung eingeschlossen. Ein Beispiel finden Sie im Abschnitt zum Schreiben der Anwendung Directory Listing.

Voraussetzungen

Vorausgesetztes Produkt Version
Java Technology Edition 5.0 und höher
Java-EE-Anwendungsserver (Java Platform, Enterprise Edition) der Version 5 und höher

WebSphere Application Server Version 6.1.0.x und höher

WebSphere Application Server Community Edition Version 2.X.

Web-Browser Jeder moderne Web-Browser wie Internet Explorer 7 und höher, Mozilla Firefox 3.x und höher, Google Chrome, Safari, Opera
Integrierte Entwicklungsumgebung (optional) Eclipse Version 3.X

Einschränkungen

Die Beispielanwendung Directory Listing ist jedoch nicht für die Entwicklung auf Produktionsservern bestimmt. Sie ist lediglich für Entwicklungs- und Lernzwecke bestimmt.

Der gesamte Quellcode für die JAX-RS-Anwendung, die Ressource und die Webseiten wird Ihnen kostenlos "AS-IS" zur Verfügung gestellt. Sie können den Quellcode verwenden, kopieren und ändern, wenn Sie Anwendungen entwickeln, die mit WebSphere-Software ausgeführt wird. Sie können den Beispielcode für die interne Nutzung verwenden oder als Teil einer Anwendung oder in Ihren Produkten verteilen.

Beispielanwendung Directory Listing schreiben

Das Design der Beispielanwendung Directory Listing demonstriert, wie Ajax-basierte Anwendungen mit Dojo Toolkit in einer Java-EE-Umgebung entwickelt werden. Um diese Ziele zu erreichen, wurden die beiden Teile einer Java-EE-Anwendung, die Clientseite und die Serverseite, in einfachen Operationen organisiert, die trotzdem eine sinnvolle Funktion ausführen. Dem liegt das einfache Muster zugrunde, dass Java-EE-Anwendungen verwenden, wenn Ajax-Technologien verwendet werden.

Voraussetzungen

In den folgenden Abschnitten wird vorausgesetzt, dass Sie mit dem JavaScript-Framework für Dojo vertraut sind. Die Dojo-Beispielclientanwendung und der verwendete Dojo-Datenspeicher "dojox.data.FileStore" werden nicht detailliert beschrieben.

Client

Der Client ist die Webseite, die dem Browser bereitgestellt wird. Auf der Webseite wird der Datenspeicher "dojox.data.FileStore" instanziiert und als Speicher für ein dijit.tree.ForestStoreModel deklariert, das als Modell für ein dijit.Tree-Widget deklariert ist. Das Widget "dijit.Tree" unterstützt die visuelle Darstellung der Dateisystemhierarchie. Neben den Verzeichnissen in der Baumstruktur werden Plus- und Minussymbole angezeigt, auf die der Benutzer klicken kann, um das jeweilige Verzeichnis ein- bzw. auszublenden. Wenn der Benutzer auf das Plussymbol klickt, wird der angeforderte Pfad vom Datenspeicher "dojox.data.FileStore" an die JAX-RS-Ressource übergeben und das Feature für verzögertes Laden gestartet. Weitere ausführliche Informationen zum clientseitigen Design finden Sie in der Beschreibung des clientseitigen Designs der Beispielanwendung Directory Listing.

Server

Der Server stellt die Infrastruktur für die Verarbeitung von Services und die Bereitstellung von Webseiten bereit. In dieser Anwendung ist die Serverseite eine JAX-RS-Ressourcenklasse, die GET-Abfragen vom Datenspeicher "dojox.data.FileStore" empfängt und verarbeitet und entsprechend den Anforderungen dieses Datenspeichers und der übergeordneten Dojo-Anwendung antwortet. Weitere ausführliche Informationen zum serverseitigen Design finden Sie in der Beschreibung des serverseitigen Designs der Beispielanwendung Directory Listing.

Beispielanwendung Directory Listing für den Client

Die Beispielanwendung Directory Listing verwendet den Datenspeicher "dojox.data.FileStore", um Informationen zu einem Pfad im Dateisystem des Servers von der JAX-RS-Ressource abzufragen. Das dojox.data.FileStore-Objekt wird mit einer Optionszeichenfolge, einem URL des Service, und dem Flag "pathAsQueryParam" konfiguriert, um anzuzeigen, dass der angeforderte Pfad als Abfrageparameter "?path=/der/Pfad" gesendet werden muss. Wenn dieses Flag nicht angegeben wird, wird die Anforderung als Anhang des URL gesendet.

Die um den Datenspeicher "dojox.data.FileStore" herum erstellte Anwendung, Modell und Baumstruktur, enthält dojo.form.CheckBox-Widgets, um die Unterstützung für einzelne Features des Datenspeichers "dojox.data.FileStore" zu aktivieren oder zu inaktivieren. Sie sind in die Anwendung integriert, um die Funktionalität des Datenspeichers zu demonstrieren. Für das Aktivieren bzw. Inaktivieren eines Features durch Anklicken eines Kontrollkästchens muss der Datenspeicher die anfängliche Anforderung erneut an den Server senden und das Modell und die Baumstruktur aktualisieren, was Sie feststellen werden, wenn Sie diese Features testen.

Die Suchfunktionen von dojox.data.FileStore werden ebenfalls in der Anwendung verarbeitet. Sie können ein Dateiattribut in einer Dropdown-Liste zusammen mit Text (einschließlich Platzhalterzeichen) für den Abgleich auswählen. Die Suche kann weiter eingegrenzt werden, indem "Ignore capitalization" oder "Deep search" ausgewählt wird. Zum Einschränken bzw. Steuern der in der Suche zurückgegebenen Einträge kann der Startindex zusammen mit der maximalen Anzahl zurückzugebender Einträge angegeben werden.

Zusätzlich zu den erwarteten Features eines Dojo-Standarddatenspeichers, Modell und Baumstruktur, ruft die Anwendung ein spezielles Feature der JAX-RS-Ressource auf, um eine Verzeichnisstruktur vorab so zu füllen, dass der Client eine hilfreiche Datenmenge wiedergibt. Die Anwendung verwendet dojo.xhrPut, um eine PUT-Anforderung an die JAX-RS-Ressource zu senden, in der die JAX-RS-Ressource angewiesen wird, eine Verzeichnishierarchie für die Beispielanwendung zu füllen.

Primärer Zweck dieser Beispielsanwendung Directory Listing ist zu demonstrieren, wie einfach das Abrufen einer entwickelten JAX-RS-Ressource ist, die Abfragen von dojox.data.FileStore empfangen und verarbeiten kann. Deshalb muss sich der Benutzer mit dem Client und dessen Codierung vertraut machen. Beachten Sie jedoch, dass dieser Client so geschrieben ist, dass die Dojo-Features über das Programm verwendet werden, um alle Features von dojox.data.FileStore zu demonstrieren und zu verhindern, dass eine Dateisystemhierarchie manuell erstellt werden muss. Das visuelle Widget "dijit.Tree" und dessen Einschluss des Modells und des Speichers können auch deklarativ mit ein paar kurzen HTML-Codezeilen geschrieben werden, wie im Folgenden gezeigt wird:

<div dojoType="dojox.data.FileStore"
     jsId="myStore" url="rest/directorylisting" pathAsQueryParam="true"></div>
<div dojoType="dijit.tree.ForestStoreModel"
     jsId="myModel" store="myStore" rootId="myfiles" rootLabel="Files" childrenAttrs="children"></div>
<div dojoType="dijit.Tree"
     id="mytree" model="myModel"></div>

Weitere Informationen zur Verwendung der Clientseite finden Sie im Anwendungsquellcode. Jeder Abschnitt im HTML-Dokument enthält Kommentare, in denen der Zweck des Codeblocks erläutert ist.

Beispielanwendung Directory Listing für den Server

Die Beispielanwendung Directory Listing für den Server muss mindestens in der Lage sein, eine GET-Anforderung mit einem Pfad zu empfangen, der an den Pfad angefügt ist, der auf die Anforderung oder einen Abfrageparameter "?path=/myPath" wartet, der der GET-Anforderung zugeordnet ist. Um das Setup der Beispielanwendung so komfortabel wie möglich zu machen, enthält die JAX-RS-Ressource eine Methode, die auf PUT-Abfragen wartet, die eine Systemverzeichnishierarchie so füllen, dass der Dojo-Client diese vor der Demonstration der dojox.data.FileStore-Features abrufen kann. Damit entfällt das manuelle Erstellen einer Dateisystemhierarchie.

Die JAX-RS-Laufzeitumgebung besitzt integrierte Funktionen für die Aufteilung der Abfrageparameter in ihre Name/Wert-Paare und deren Übergabe als Parameter an die Java-Methode, die die GET-Anforderung empfängt.

JAX-RS-Ressourcenklasse für den Empfang der HTTP-Anforderungen erstellen

package com.ibm.websphere.mobile.appsvcs.sample.directorylisting.resources;

import javax.ws.rs.Path; // Es wird nicht die vollständige Importliste gezeigt.

@Path("/directorylisting")
public class DirectoryListingService
{
   // ...
}

In dieser JAX-RS-Ressourcenklasse muss ein URL-Segment "/directorylisting" deklariert werden. Diese Ressourcenklasse verarbeitet Anforderungen, die für "http://<Server>:<Port>/<Kontextstammverzeichnis>/<URI-Zuordnung>/directorylisting" bestimmt sind.

Das Kontextstammverzeichnis wird von der Datei "application.xml" definiert, wenn Ihre Webarchivdatei (.war) in eine Unternehmensarchivdatei (.ear) gepackt ist. Wenn die WAR-Datei eigenständig installiert wird, wird das Kontextstammverzeichnis vom Benutzer während der Installation definiert. Die URI-Zuordnung wird in der Datei "WEB-INF/web.xml" in der WAR-Datei definiert.

JAX-RS-Ressourcenmethoden erstellen

Der Datenspeicher "dojox.data.FileStore" sendet GET-Anforderungen. Im Client wurde konfiguriert, dass der gewünschte Pfad als Abfrageparameter und ein Teil der diversen optionalen Argument, die in dojox.data.FileStore beschrieben sind, einschließlich des Abfrageprotokolls "dojo.data.api.Read", gesendet werden. Der Datenspeicher "dojox.data.FileStore" kann beispielsweise eine GET-Anforderung wie folgt senden: http://<Server>:<Port>/<Kontextstammverzeichnis>/<URI-Zuordnung>/directorylisting?path=/der/Pfad. Da der Pfad als Teil des URL und alternativ als Abfrageparameter behandelt werden muss, gibt es für die beiden Fälle jeweils eine JAX-RS-Ressourcenmethode. Beide Ressourcenmethoden rufen eine allgemeine Methode auf, die die Logik des Service verarbeitet.

// Abfrageparameter und -werte
private static final String QUERY_OPTIONS = "Optionen";
private static final String QUERY_PATH = "Pfad";
private static final String QUERY_QUERY = "Abfrage";
private static final String QUERY_QUERYOPTIONS = "Abfrageoptionen";
private static final String QUERY_START = "Anfang";
private static final String QUERY_COUNT = "Zähler";

// Standardwert für Abfrageparameter start und count.
private static final String NO_VALUE_STRING = "-1";
private static final int NO_VALUE_INT = -1;

@GET
@Produces(MediaType.APPLICATION_JSON)
public JSONObject getFileListWithPathInParam(
        @Context ServletConfig servletConfig,
        @Context HttpHeaders httpHeaders,
        // Note, the path is obtained with @QueryParam.
        @QueryParam(QUERY_PATH) String path,
        @QueryParam(QUERY_OPTIONS) String options,
        @QueryParam(QUERY_QUERY) String query,
        @QueryParam(QUERY_QUERYOPTIONS) String queryOptions,
        @DefaultValue(NO_VALUE_STRING) @QueryParam(QUERY_START) String startParam,
        @DefaultValue(NO_VALUE_STRING) @QueryParam(QUERY_COUNT) String countParam)
{
    return getFileListCommon(servletConfig, path, options, query, queryOptions, startParam, countParam);
}

@GET
// JAX-RS ruft diese Methode auf, wenn der URL mehr als den Stammverzeichnispfad enthält.
@Path("{path:.*}")
@Produces(MediaType.APPLICATION_JSON)
public JSONObject getFileListWithPathInUri(
        @Context ServletConfig servletConfig,
        @Context HttpHeaders httpHeaders,
        // Note, the path is obtained with @PathParam.
        @PathParam(QUERY_PATH) String path,
        @QueryParam(QUERY_OPTIONS) String options,
        @QueryParam(QUERY_QUERY) String query,
        @QueryParam(QUERY_QUERYOPTIONS) String queryOptions,
        @DefaultValue(NO_VALUE_STRING) @QueryParam(QUERY_START) String startParam,
        @DefaultValue(NO_VALUE_STRING) @QueryParam(QUERY_COUNT) String countParam)
{
    return getFileListCommon(servletConfig, path, options, query, queryOptions, startParam, countParam);
}

Die erste Annotation @GET deklariert, dass die Methode HTTP-GET-Anforderungen an dem URL, der mit "directorylisting" endet, basierend auf der Klassenannotation @Path empfängt. Beachten Sie die Verwendung der Annotation @QueryParam für den Zugriff auf den angeforderten Pfad im Service.

Die zweite Annotation @GET qualifiziert @Path mit dem regulären Ausdruck "{path:.*}" näher, der mit allen Zeichen abgeglichen wird, die der Klassenannotation @Path folgen. Wenn die zweite Methode aufgerufen wird, wird deshalb erwartet, das der Pfad im URL enthalten ist. Beachten Sie die Verwendung der Annotation @PathParam für den Zugriff auf den angeforderten Wert des Pfads im Service.

Bei Methoden enthalten die Annotation "@Produces". Dies hilft der JAX-RS-Laufzeitumgebung, die eingehende Nachricht der Java-Methode zuzuordnen. Die JAX-RS-Laufzeitumgebung versucht, den Header "Accept" der eingehenden Nachricht dem @Produces-Wert zuzuordnen. Außerdem informiert Sie die JAX-RS-Laufzeitumgebung über das erwartete Format der Antwort.

JAX-RS-Kernanwendungsklasse erstellen

Jetzt ist eine weitere Klasse für die Ausführung der Anwendung erforderlich. JAX-RS initialisiert eine Anwendung und deren Ressourcen und Provider über die Klasse, die javax.ws.rs.core.Application erweitert. Erstellen Sie deshalb die folgende Klasse.

package com.ibm.websphere.mobile.appsvcs.sample.directorylisting;

import java.util.HashSet;
import java.util.Set;
import javax.ws.rs.core.Application;

public class DirectoryListingApplication extends Application
{
   @Override
   public Set<Class<?>> getClasses()
   {
      Set<Class<?>> classes = new HashSet<Class<?>>();
      classes.add(DirectoryListingService.class);
      return classes;
   }
}

JAX-RS-Anwendung in der Datei "web.xml" aktivieren

Im Folgenden sehen Sie die kritischen Teile, mit denen diese JAX-RS-Anwendung aktiviert wird.

...
<servlet-name>JAXRSServlet</servlet-name>
<servlet-class>com.ibm.websphere.jaxrs.server.IBMRestServlet</servlet-class>
<init-param>
   <param-name>javax.ws.rs.Application</param-name>
   <param-value>com.ibm.websphere.mobile.appsvcs.sample.directorylisting.DirectoryListingApplication</param-value>
</init-param>
...
<servlet-mapping>
   <servlet-name>JAXRSServlet</servlet-name>
   <url-pattern>/rest/*</url-pattern>
</servlet-mapping>
...

Beachten Sie die Servletklasse (servlet-class) und die Initialisierungsparameter mit dem Parameternamen "javax.ws.rs.Application". Dies ist die Standardmethode für die Deklaration der Servletimplementierung und die Übergabe der Referenz dieser Klasse, die javax.ws.rs.core.Application erweitert, an die JAX-RS-Laufzeitumgebung.

Mit dem Einschluss der Datei "WEB-INF/web.xml", der kompilierten Anwendung und den richten Bibliotheksdateien im Verzeichnis "WEB-INF/lib/" der WAR-Datei kann die Anwendung in einem Anwendungsserver installiert werden. Sehen Sie sich den Inhalt des eingeschlossenen Beispiels an, wenn Sie sich über die Liste der erforderlichen Bibliotheken informieren möchten. Die eingeschlossene Beispielanwendung hat die Form einer WAR-Datei, die in eine EAR-Datei gepackt ist. In der EAR-Datei befindet sich die Standarddatei "application.xml", die das URL-Kontextstammverzeichnis "/appsvcs-directorylisting" spezifiziert. Somit ist der URL der Datei "index.html" http://<Server>:<Port>/appsvcs-directorylisting/. Beachten Sie, dass der in der Datei "index.html" in der Beispielanwendung angegebene URL "rest/directorylisting" ist, der relativ zur Position der Datei "index.html" ist und das Ergebnis der Verkettung des URL-Musters aus der Datei "web.xml" und der Annotation "@Path" in der JAX-RS-Ressourcenklasse ist.

Implementierung der GET-Methode

Die Methode "getFileListCommon" wird von jeder der beiden zuvor beschriebenen JAX-RS-Ressourcenmethoden aufgerufen. Die einzelnen Parameter sind in der folgenden Liste beschrieben. Format und Inhalt der Parameter entsprechen der Dokumentation für dojox.data.FileStore. Die ersten beiden Parameter werden vom zugrunde liegenden Servletcontainer immer bereitgestellt. Die verbleibenden Parameter sind optional. Deshalb können Sie null angeben oder die Standardwerte akzeptieren.

protected JSONObject getFileListCommon(
        ServletConfig servletConfig,
        HttpHeaders httpHeaders,
        String path,         // Pfad der Anforderung aus dem URL oder einem HTTP-Parameter
        String options,      // JSON-Array; kann expand, showHiddenFiles, dirsOnly enthalten
        String query,        // JSON-Array von Name/Wert-Paaren für eine gefilterte Suche
        String queryOptions, // JSON-Array von Einstellungen für eine tiefe Suche und/oder ignoreCase
        String startParam,   // Index der Anfangsergebnisse in der zurückgegebenen Liste
        String countParam)   // Anzahl der in der Ergebnisliste zurückzugebenden Einträge
{
    // ...
}

Es sind Methoden im Quellcode vorhanden, mit denen die Parameter validiert und in manchen Fällen in ein Formular gestellt werden können, das sich später einfach abfragen lässt. Beschreibungen dieser Parameter finden Sie in der Dokumentation zu dojox.data.FileStore.

Jetzt haben Sie die Anforderung erfolgreich vom Datenspeicher "dojox.data.FileStore" empfangen. Er erwartet eine Antwort im JSON-Format, die mithilfe von Informationen aus dem angeforderten Pfad in einem JSONObject erstellt werden kann. Das folgende Codebeispiel zeigt, wie die JSON-formatierte Antwort erstellt wird.

 // Attributnamen
 private static final String ATTRIB_ITEMS = "items";
 private static final String ATTRIB_NAME = "name";
 private static final String ATTRIB_PATH = "path";
 private static final String ATTRIB_PARENTDIR = "parentDir";
 private static final String ATTRIB_SIZE = "size";
 private static final String ATTRIB_DIRECTORY = "directory";
 private static final String ATTRIB_CHILDREN = "children";
 private static final String ATTRIB_MODIFIED = "modified";

...
// Angenommen, Sie haben die gewünschte Datei bereits gefunden und
// als Java-Datei in der Variablen "file" instanziiert.
JSONArray fileList = new JSONArray();
if (path.equals("/") && file.isDirectory()) {
    // Abfrageparameter "path" wurde nicht übergeben, war leer oder "/"
    File[] children = file.listFiles();
    if (children != null && children.length > 0) {
        for (int i = 0; i < children.length; i++) {
            // Allgemeinen Code aufrufen, um die Liste anzufügen, falls die Datei gültig ist.
            // Sucht ggf. auch rekursiv.
            appendFileList(children[i], fileList);
        }
    }
    JSONObject items = new JSONObject();
    items.put(ATTRIB_ITEMS, fileList);
    logger.exit();
    return items;
} else {
    // Einzige ID-Suche für einen bestimmten Pfad.
    // JSONObject, das die zurückgegebene Datei darstellt.
    JSONObject jsonFile = appendFileList(file, null);
    if (jsonFile == null) {
        // Handle error
        ...
    } else {
        logger.exit();
        return jsonFile;
    }
}
...

...
private JSONObject appendFileList(File file, JSONArray fileList) {
   ...
   JSONObject item = new JSONObject();

   if (file != null) {
      item.put(ATTRIB_NAME, file.getName());
      item.put(ATTRIB_MODIFIED, new Long(file.lastModified()));
      item.put(ATTRIB_SIZE, new Long(file.length()));
      item.put(ATTRIB_PATH, getFileAttribute(ATTRIB_PATH, file));
      item.put(ATTRIB_PARENTDIR, getFileAttribute(ATTRIB_PARENTDIR, file));
      item.put(ATTRIB_DIRECTORY, new Boolean(file.isDirectory()));
      // Details zum Traversieren der Verzeichnisstrukturen der Dateien
      ...
      // Der Liste einen weiteren Eintrag hinzufügen.
      fileList.add(item);

   }
   ...
}

Jetzt haben Sie eine JAX-RS-Serviceressource, die in der Lage ist, die Erwartungen des Datenspeichers "dojox.data.FileStore" zu erfüllen und auf diese zu antworten. Die Implementierungsdetails für die Traversierung des Dateisystems, die Verwaltung der Optionen aus dem Abfrageparameter "options" und die Konfiguration des Stammverzeichnisses können Sie dem Quellcode entnehmen.

Quellcode der Beispielanwendung Directory Listing anzeigen

Der Quellcode der Beispielanwendung Directory Listing wird in der Webmoduldatei mit der Erweiterung ".war" in der Datei "appsvcs-directorylisting.ear" bereitgestellt. Für die Anzeige des Quellcodes stehen zwei Methoden zur Verfügung. Sie können den Quellcode über eine Eclipse-basierte integrierte Entwicklungsumgebung (IDE, Integrated Development Environment) oder durch Dekomprimieren der Datei appsvcs-directorylisting.ear und anschließende Dekomprimierung der darin enthaltenen WAR-Datei anzeigen.

EAR-Datei suchen

Wenn Sie den Quellcode anzeigen möchten, müssen Sie zuerst die Datei "DirectoryListing.ear" suchen. Wenn Sie IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile installiert haben, können Sie die EAR-Datei in Ihrer Installationsstruktur finden.

Angenommen, Sie haben das Feature-Pack im folgenden Verzeichnis installiert:

Linux und UNIX: /opt/WebSphere/AppServer
z/OS-Mountpunkt: <Installationsstammverzeichnis>
Windows: c:\WebSphere\AppServer

In diesem Fall finden Sie die EAR-Datei im folgenden Verzeichnis:

Linux und UNIX: /opt/WebSphere/AppServer/web2mobilefep_1.1/samples/directorylisting/appsvcs-directorylisting.ear
z/OS: <Installationsstammverzeichnis>/web2mobilefep_1.1/samples/directorylisting/appsvcs-directorylisting.ear
Windows: c:\WebSphere\AppServer\web2mobilefep_1.1\samples\directorylisting\appsvcs-directorylisting.ear

Quellcode in einer Eclipse-basierten integrierten Entwicklungsumgebung anzeigen

Die Verwendung einer Eclipse-basierten integrierten Entwicklungsumgebung ist die einfachste Methode für die Untersuchung des Quellcodes der WAR-Datei. Verwenden Sie für die Ausführung der folgenden Schritte Eclipse 3.2.X oder 3.3.X mit Web Tools Project 2.5 oder höher oder Rational Application Developer Version 7.0 oder höher, um die WAR-Datei zu importieren:

  1. Klicken Sie auf die Datei "appsvcs-directorylisting.ear".
  2. Wählen Sie im Eclipse-IDE-Menü File > Import aus.
  3. Klicken Sie in der daraufhin erscheinenden Anzeige auf die Option Web. Wählen Sie WAR file aus, und klicken Sie anschließend auf Next.
  4. Klicken Sie im Eingabefeld WAR File auf Browse, und wählen Sie die zuvor gesuchte Datei aus.
  5. Übernehmen Sie die Standardwerte für den Projektnamen, wenn Sie akzeptabel sind, und klicken Sie auf Finish.

Nach Abschluss des Importprozesses ist ein neues Projekt, DirectoryListing, im Eclipse-Arbeitsbereich vorhanden. Der Quellcode der Anwendung kann über das Projekt DirectoryListing aufgerufen werden. Für den Zugriff auf den Client- oder Servercode verwenden Sie die folgende Tabelle, in der die Positionen der Quellcodes in der Struktur des Eclipse-Projekts "DirectoryListing" aufgelistet sind.

Quellcode Position
Clientseite (Web-Browser) WebContent/index.html: Enthält die Dojo-Widget-Definitionen und die Clientscriptfunktionen. Diese Datei lädt das nicht optimierte Dojo-Profil.
Serverseite Java-Ressourcen: src/com.ibm.websphere.mobile.appsvcs.sample.directorylisting/ DirectoryListingApplication.java: Klicken Sie doppelt auf diese Datei, um den Quellcode zu laden.
Java-Ressourcen: src/com.ibm.websphere.mobile.appsvcs.sample.directorylisting. resources/DirectoryListingService.java: Klicken Sie doppelt auf diese Datei, um den Quellcode zu laden.

Quellcode durch Extrahieren der WAR-Datei anzeigen

Webanwendungsarchive (WAR, Web Application Archive) sind Dateiarchive, die mit dem ZIP-Algorithmus komprimiert werden. Deshalb kann die Archivdatei mit einer Reihe von Dekomprimierungstools, einschließlich des Programms JAR (Java Archive), dekomprimiert werden. In den folgenden Schritten wird angenommen, dass der Benutzer sein bevorzugtes Tool für die Erstellung komprimierter Dateien auswählt.

  1. Dekomprimieren Sie die Datei "DirectoryListing.ear", die Sie zuvor gesucht haben, mit dem von Ihnen bevorzugten ZIP-Komprimierungstool in einem Verzeichnis auf Ihrem System. In den folgenden Schritten wird angenommen, dass EXPAND_DIR/DirectoryListing die korrekte Position ist.
  2. Listen Sie die Dateien im Verzeichnis EXPAND_DIR/DirectoryListing auf, in dem Sie die Datei "DirectoryListing.ear" dekomprimiert haben.

Nachdem Sie den Inhalt der EAR-Datei extrahiert haben, müssen Sie auch den Inhalt der WAR-Datei extrahieren. Anschließend können Sie auf den Quellcode zugreifen. Für den Zugriff auf den Client- oder Servercode verwenden Sie die folgende Tabelle, in der die Positionen der Quellcodes im Verzeichnis EXPAND_DIR/DirectoryListing aufgelistet sind.

Quellcode Position
Clientseite (Web-Browser) index.html: Enthält die Dojo-Widget-Definitionen und die Clientscriptfunktionen.
Serverseite WEB-INF/classes/com/ibm/websphere/mobile/appsvcs/sample/directorylisting/ DirectoryListingApplication.java
WEB-INF/classes/com/ibm/websphere/mobile/appsvcs/sample/directorylisting/ resources/DirectoryListingService.java

Beispielanwendung Directory Listing installieren

Lesen Sie die folgenden versionsspezifischen Installationsanweisungen:

Anweisungen für die Installation in WebSphere Application Server

In diesem Abschnitt wird die Prozedur zum Installieren der Beispielanwendung Directory Listing in Version 6.1.0.X und höher von IBM WebSphere Application Server beschrieben. Es wird vorausgesetzt, dass Sie sich mit der Installation und Verwaltung von Anwendungen im Anwendungsserver auskennen.

Vorbereitungen

Suchen Sie die EAR-Datei der Beispielanwendung Directory Listing, die mit der Produktinstallation bereitgestellt wird. Sie finden die EAR-Datei in der Installationsstruktur, in der Sie IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile installiert haben. Angenommen, Sie haben das Feature-Pack im folgenden Verzeichnis installiert:

Linux und UNIX: /opt/WebSphere/AppServer
z/OS-Mountpunkt: <Installationsstammverzeichnis>
Windows: c:\WebSphere\AppServer

In diesem Fall finden Sie die EAR-Datei im folgenden Verzeichnis:

Linux und UNIX: /opt/WebSphere/AppServer/web2mobilefep_1.1/samples/application_services/directorylisting/appsvcs-directorylisting.ear
z/OS: <Installationsstammverzeichnis>/web2mobilefep_1.1/samples/application_services/directorylisting/appsvcs-directorylisting.ear
Windows: c:\WebSphere\AppServer\web2mobilefep_1.1\samples\application_services\directorylisting\appsvcs-directorylisting.ear

Beispielanwendung Directory Listing über die Administrationskonsole installieren

  1. Melden Sie sich bei der Administrationskonsole des Anwendungsservers an.
  2. Klicken Sie auf Anwendungen > Neue Anwendung. (Anmerkung: In WebSphere Application Server Version 6.1 wählen Sie Neue Anwendung installieren aus.)
  3. Wählen Sie Neue Unternehmensanwendung aus. (Anmerkung: In WebSphere Application Server Version 6.1 überspringen Sie diesen Schritt.)
  4. Durchsuchen Sie Ihr Dateisystem, und wählen Sie die Datei "appsvcs-graphics.ear" aus, die Sie zuvor gesucht haben. Klicken Sie auf Weiter.
  5. Klicken Sie auf Weiter, um die Anwendungsinstallation vorzubereiten. (Anmerkung: In WebSphere Application Server Version 6.1 überspringen Sie diesen Schritt.)
  6. Klicken Sie auf Weiter, um die Standardinstallationsoptionen zu akzeptieren.
  7. Klicken Sie auf Weiter, um die Standardoptionen für die Zuordnung von Modulen zu Servern zu akzeptieren.
  8. Klicken Sie auf Weiter, um die Standardoptionen für die Metadaten für Module zu akzeptieren. (Anmerkung: In den WebSphere Application Server Versionen 6.1 und 7 überspringen Sie diesen Schritt.)
  9. Klicken Sie auf Weiter, um die Standardoptionen für die Zuordnung virtueller Hosts zu Webmodulen zu akzeptieren.
  10. Überprüfen Sie die Zusammenfassung der Installationsoptionen.
  11. Klicken Sie auf Fertig stellen.
  12. Klicken Sie auf In Masterkonfiguration speichern.
  13. Klicken Sie auf Anwendungen > Anwendungstypen > WebSphere-Unternehmensanwendungen. (Anmerkung: In WebSphere Application Server Version 6.1 klicken Sie auf Anwendungen > Enterprise-Anwendungen.)
  14. Wählen Sie IBM WebSphere Application Server - Directory Listing sample application aus, und klicken Sie anschließend auf Starten.

Zugriff auf den installierten Anwendungsdemoclient

Rufen Sie in Ihrem Web-Browser Ihre Anwendungsserverinstallation auf: http://<Hostname_des_Anwendungsservers>:<Port>/appsvcs-directorylisting/

Der Hostname des Anwendungsservers und der Port sind Angaben, die für Ihre Anwendungsserverinstallation spezifisch sind. Ein Webcontainerport die Standardinstallation eines Anwendungsservers ist 9080. Wenn Sie Ihren Web-Browser auf derselben Workstation wie Ihre Anwendungsserverinstallation ausführen und alle Standardwerte übernommen haben, verwenden Sie den folgenden URL: http://localhost:9080/appsvcs-directorylisting/.

Installationsanweisungen für WebSphere Application Server Community Edition Version 2.X

In diesem Abschnitt wird die Vorgehensweise bei der Installation der Beispielanwendung Directory Listing in Version 2.X von IBM WebSphere Application Server Community Edition beschrieben. Es wird vorausgesetzt, dass Sie sich mit der Installation und Verwaltung von Anwendungen im Anwendungsserver auskennen.

Vorbereitungen

Suchen Sie die EAR-Datei der Beispielanwendung Directory Listing, die mit der Produktinstallation bereitgestellt wird. Sie finden die EAR-Datei in der Installationsstruktur, in der Sie IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile installiert haben. Angenommen, Sie haben das Feature-Pack im folgenden Verzeichnis installiert:

Linux und UNIX: /opt/WebSphere/AppServerCommunityEdition
Windows: c:\WebSphere\AppServerCommunityEdition

In diesem Fall finden Sie die EAR-Dateien und Bibliotheksdateien an folgender Position:

Linux und UNIX: /opt/WebSphere/AppServerCommunityEdition/web2mobilefep_1.1/AppServices/samples/directorylisting/appsvcs-directorylisting.ear
Windows: c:\WebSphere\AppServerCommunityEdition\web2mobilefep_1.1\AppServices\samples\directorylisting\appsvcs-directorylisting.ear

Installation über die Administrationskonsole

Melden Sie sich bei der Administrationskonsole des Anwendungsservers an.

  1. Klicken Sie im linken Menü auf Anwendungen > Deployer. (Anmerkung: In WebSphere Application Server Community Edition Version 2.0 klicken Sie auf Anwendungen > Neue Anwendung implementieren.)
  2. Suchen Sie über das Feld Archiv in Ihrem Dateisystem die Datei "appsvcs-directorylisting.ear", und wählen Sie sie aus. Lassen Sie das Feld Plan leer und die Standardoptionen ausgewählt. Klicken Sie anschließend auf Installieren.

Die Anwendung wird automatisch gestartet, und die Installation ist damit abgeschlossen.

Zugriff auf den installierten Anwendungsdemoclient

Rufen Sie in Ihrem Web-Browser Ihre Anwendungsserverinstallation auf: http://<Hostname_des_Anwendungsservers>:<Port>/appsvcs-directorylisting/.

Der Hostname des Anwendungsservers und der Port sind Angaben, die für Ihre Anwendungsserverinstallation spezifisch sind. Ein Webcontainerport die Standardinstallation von WebSphere Application Server Community Edition ist 8080. Wenn Sie Ihren Browser auf derselben Workstation wie Ihre Anwendungsserverinstallation ausführen und alle Standardwerte übernommen haben, verwenden Sie den folgenden URL:

http://localhost:8080/appsvcs-directorylisting/