Diese Seite ist der Ausgangspunkt der Informationen zur Beispielanwendung File Uploader. Dieser Abschnitt beschäftigt sich mit folgenden Themen:
Die Beispielanwendung File Uploader wurde erstellt, um die Verwendung der Widgets "dojox.form.FileUploader" und "dojox.form.Uploader" aus Dojo Toolkit for JavaScript zu ergänzen. Die Beispielanwendung File Uploader veranschaulicht, wie eine JAX-RS-REST-Anwendung (Representational State Transfer) entwickelt wird, die Uploads empfangen und auf Uploads reagieren kann, die von den Widgets "dojox.form.FileUploader" und "dojox.form.Uploader" in Dojo Toolkit stammen.
Die Widgets "dojox.form.FileUploader" und "dojox.form.Uploader" laden Dateien auf traditionelle Weise wie ein HTML-Formular in einem Web-Browser hoch. Sie verwenden eine HTTP-Nachricht mit der Codierung multipart/form-data. Die JAX-RS-Ressource empfängt die übergebenen Formulardaten, die bereits in die einzelnen Teile geparst wurden. Dieser Prozess vereinfacht die Implementierung des Servercodes erheblich. Die JAX-RS-Ressourcenklasse muss lediglich über die Teile iterieren und die Daten entsprechend verarbeiten.
Primärer Zweck der Beispielanwendung File Uploader ist, die Einfachheit und Leistungsfähigkeit der JAX-RS-Ressourcenklasse zu demonstrieren. Um diese Einfachheit vollständig zu demonstrieren, wird jedoch das Widget "dojox.form.Uploader" als Komponente in eine größere Dojo-Anwendung eingeschlossen. Ein Beispiel finden Sie im Abschnitt zum Schreiben der Anwendung File Uploader.
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 |
Die Beispielanwendung File Uploader ist jedoch nicht für die Implementierung auf Produktionsservern, sondern 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 werden. Sie können den Beispielcode für die interne Nutzung verwenden oder als Teil einer Anwendung bzw. in Ihren Produkten verteilen.
Das Design der Beispielanwendung File Uploader demonstriert, wie die Entwicklung einer AJAX-basierten Anwendung mit Dojo Toolkit in einer Java-EE-Umgebung durchgeführt wird, die die Anforderungen der Dojo-Widgets "dojox.form.FileUploader" und "dojox.form.Uploader" erfüllt. 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, das Java-EE-Anwendungen beim Einsatz von AJAX-Technologien verwenden.
In den folgenden Abschnitten wird vorausgesetzt, dass Sie mit dem JavaScript-Framework für Dojo vertraut sind. Die Dojo-Beispielclientanwendung und das verwendete Widget "dojox.form.Uploader" werden nicht detailliert beschrieben.
Der Client ist die Webseite, die dem Browser bereitgestellt wird. In der Webseite wird das Widget "dojox.form.Uploader" instanziiert, und Browserereignisse werden mit diesem Widget verbunden. Das Durchsuchen des Dateisystems wird von Shockwave Flash oder direkt vom JavaScript-Framework für Dojo gesteuert. Das Widget "dojox.form.Uploader" verwendet HTML5, wenn der verwendete Browser HTML5 unterstützt, und greift je nach Leistungsspektrum auf Shockwave Flash bzw. normales HTML zurück. Es lässt die Auswahl mehrerer Dateien gleichzeitig zu und übergibt die Dateiuploads über HTML5 oder einen verdeckten HTML-iframe. Diese Verwendung eines verdeckten iframe für die Durchführung des Uploads ist wegen des gesendeten multipart/form-data-Inhaltstyps erforderlich. Die Antwort bewirkt dann Teilseitenaktualisierungen. Dieser Prozess wird, sofern Sie mit einem HTML5-fähigen Browser oder Shockwave Flash arbeiten, ohne ein vollständiges Neuladen der Seite ausgeführt. Das Widget "dojox.form.FileUploader" ist in Dojo 1.6 veraltet und wird voraussichtlich in Dojo 2.0 nicht mehr angeboten. Es wurde durch "dojox.form.Uploader" ersetzt. Der Beispielservice ist jedoch in der Lage, die Anforderungen dieser beiden Widgets zu erkennen und entsprechend zu reagieren. Ausführlichere Informationen zum Clientdesign finden Sie unter Beispielanwendung File Uploader für den Client.
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 POST-Abfragen mit der Codierung multipart/form-data von den Dojo-Widgets "dojox.form.FileUploader" und "dojox.form.Uploader" empfängt und verarbeitet und auf die Anforderungen dieser Widgets sowie der übergeordneten Dojo-Anwendung entsprechend reagiert. Beim Widget "dojox.form.FileUploader" ist die Antwort vom Benutzeragenten (Browser oder Shockwave Flash) abhängig, der die POST-Abfrage einleitet. Beim Widget "dojox.form.Uploader" ist die Antwort vom Feld "name" im Header multipart/form-data "part" abhängig, der die Nutzdaten der Datei enthält. Für Transaktionen, die von einem Browser ohne HTML5-Unterstützung eingeleitet werden, wird JavaScript Object Notation (JSON) in einem HTML-Tag "textarea" zurückgegeben. Für Transaktionen, die über HTML5 eingeleitet werden, wird JSON zurückgegeben. Wird eine Transaktion von Shockwave Flash eingeleitet, wird eine angepasste Zeichenfolge zurückgegeben. Der Inhalt der JSON oder angepassten Zeichenfolge wird auf der Basis der Anforderungen der Anwendung erstellt, die die Widgets "dojox.form.FileUploader" und "dojox.form.Uploader" nutzt. Ausführlichere Informationen zum serverseitigen Design finden Sie unter Die Beispielanwendung File Uploader für den Server.
Die Beispielanwendung File Uploader verwendet das Widget "dojox.form.Uploader", um die Anzeigesteuerung für das lokale Dateisystem des Benutzers für die Dateiauswahl zu aktivieren, und stellt die Steuerung für die Übergabe der Daten beim Anklicken der Schaltfläche "Übergeben" des Widgets bereit. Die Anzeigesteuerung von "dojox.form.Uploader" wird vom Widget selbst über die Eingabe in einer Standardformulardatei oder durch Aktivieren der Shockwave-Flash-Anwendung aktiviert, wenn im Browser das Plug-in für Shockwave Flash installiert ist. Beim Durchsuchen des lokalen Dateisystems mit den HTML5-Steuerelementen des Browsers kann der Benutzer mehrere Dateien gleichzeitig auswählen. Bei Verwendung des Shockwave-Flash-Plug-ins kann der Benutzer beim Durchsuchen des lokalen Dateisystems ebenfalls mehrere Dateien gleichzeitig auswählen. In Browsern, die HTML5 nicht unterstützen, kann beim Durchsuchen des lokalen Dateisystems nur eine einzige Datei ausgewählt werden, aber es können mehrere Dateien zum Upload in eine Warteschlange eingereiht werden, bevor sie übergeben werden.
Die um das Widget "dojox.form.Uploader" herum erstellte Anwendung enthält Links zum Aktivieren und Inaktivieren der Unterstützung einzelner Features des Widgets "dojox.form.Uploader". Sie sind in die Anwendung integriert, um die Funktionalität des Widgets zu demonstrieren.
Außerdem empfängt die Anwendung über das Widget "dojox.form.Uploader" Antwortdaten vom Server, die sie verwendet, um die kürzlich hochgeladenen Dateien anzuzeigen, sofern dies möglich ist. Außerdem verwaltet die Anwendung eine Liste der Dateien in einem Array, über die die Dateien vom Server gelöscht werden können, wenn Sie auf die Schaltfläche "Delete All Uploaded Files from Server" klicken. Diese Schaltfläche startet die Funktion "deletePreviousUploads" in der Anwendung, die die Dateien aus der angezeigten Liste entfernt und Dojo-AJAX-Abfragen "xhrDelete" verwendet, um an den Server die Anforderung zum Löschen der kürzlich hochgeladenen Dateiressourcen zu senden.
Wenn Sie mit "dojox.form.Uploader" vertraut sind, erkennen Sie möglicherweise, dass diese Anwendung einem der Tests gleicht, die mit "dojox.form.Uploader" in Dojo Toolkit 1.6 bereitgestellt werden. Diese Clientbeispielanwendung basiert primär auf diesem Test, weist aber einen wichtigen Unterschied auf. Die meisten HTTP-Server unterstützen die HTTP-Methode DELETE nicht, und deshalb enthält der ursprüngliche Test keine solche Funktion. Die Dojo-Clientanwendung unterstützt die Methode DELETE jedoch.
Primärer Zweck der Beispielanwendung File Uploader ist, die Einfachheit des Abrufs einer entwickelten JAX-RS-Ressource zu demonstrieren, die Übergaben von "dojox.form.Uploader" empfängt, so dass sich der Leser um das weitere Verständnis und die Codierung des Clients kümmern kann.
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.
Die Beispielanwendung File Uploader für den Server muss in der Lage sein, eine POST-Abfrage mit dem Inhaltstyp multipart/form-data zu empfangen. Damit sind die Voraussetzungen des Widgets "dojox.form.Uploader" erfüllt. Die Dojo-Clientbeispielanwendung, die "dojox.form.Uploader" enthält, ist in der Lage, die kürzlich hochgeladenen Dateien anzuzeigen. Das bedeutet, dass Ihre JAX-RS-Ressource Daten an den Client zurückgeben muss, die den URL der soeben hochgeladenen Datei enthalten müssen, und auf eine GET-Abfrage für diese kürzlich hochgeladene Datei antworten kann. Außerdem soll der Client in der Lage sein, das Löschen der kürzlich hochgeladenen Dateiressourcen anzufordern. Dies bedeutet, dass die JAX-RS-Ressource ebenfalls eine Methode haben muss, die Löschanforderungen empfangen kann.
Die JAX-RS-Laufzeitumgebung hat eine integrierte Funktion für das Parsen der Nutzdaten des Headers multipart/form-data und die Übergabe dieser Daten in einer Objektinstanz vom Typ org.apache.wink.common.model.multipart.BufferedInMultiPart an die Methode der JAX-RS-Ressourcenklasse.
package com.ibm.websphere.mobile.appsvcs.fileuploader.resources; import javax.ws.rs.Path; import javax.ws.rs.Consumes; import javax.ws.rs.Produces; import org.apache.wink.common.model.multipart.BufferedInMultiPart; @Path("upload") public class MultiFileUploadDataService { // ... }
In dieser JAX-RS-Ressourcenklasse muss ein URL-Segment "upload" deklariert werden. Diese Ressourcenklasse verarbeitet Anforderungen, die für "http://<Server>:<Port>/<Kontextstammverzeichnis>/<URI-Zuordnung>/upload" 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.
Das Widget "dojox.form.Uploader" übergibt den Upload wie ein Browser - als HTTP-POST-Anforderung mit einem Content-Type-Header multipart/form-data. Diese Informationen werden zusammen mit dem Ziel-URL von der JAX-RS-Laufzeitumgebung verwendet, um die eingehende Nachricht der Java-Methode zuzuordnen, die sie empfängt. Implementieren Sie deshalb eine Methode in der JAX-RS-Ressourcenklasse, um die Nachricht zu akzeptieren.
@POST @Consumes(MediaType.MULTIPART_FORM_DATA) public String upload(BufferedInMultiPart bimp) { // ... }
Die Annotation @POST deklariert, dass diese Methode HTTP-POST-Anforderungen unter dem URL empfängt, der mit "upload" endet. Beachten Sie auch, dass @Consumes deklariert ist. Dies hilft der JAX-RS-Laufzeitumgebung, die eingehende Nachricht der Java-Methode zuzuordnen. Die JAX-RS-Laufzeitumgebung versucht, den Content-Type-Header der eingehenden Nachricht dem @Consumes-Wert zuzuordnen.
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.fileuploader.resources; import java.util.HashSet; import java.util.Set; import javax.ws.rs.core.Application; public class FileUploaderApplication extends Application { @Override public Set<Class<?>> getClasses() { Set<Class<?>> classes = new HashSet<Class<?>>(); classes.add(MultiFileUploadDataService.class); return classes; } }
Jetzt müssen Sie alle Teile in der Datei "web.xml" zusammenführen. 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.fileuploader.FileUploaderApplication</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 (init-param) mit dem Parameternamen (param-name) "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 richtigen 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-fileuploader" spezifiziert. Somit ist der URL der Datei "index.html" http://<Server>:<Port>/appsvcs-fileuploader/. Beachten Sie, dass der in der Datei "index.html" in der Beispielanwendung angegebene URL "rest/upload" 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.
Weitere Einzelheiten zur Implementierung der Methode, die die multipart/form-data-Nachrichtennutzdaten empfängt und verarbeitet, erhalten Sie, indem Sie sich den Quellcode ansehen oder weiterlesen.
Die Uploadmethode empfängt ein BufferedInMultiPart-Objekt, das die bereits geparsten multipart/form-data-Nachrichtennutzdaten enthält. Für jeden Teil werden Aktionen ausgeführt.
@POST @Consumes(MediaType.MULTIPART_FORM_DATA) public String upload(BufferedInMultiPart bimp) { List<InPart> parts = bimp.getParts(); for (int i = 0; i < parts.size(); i++) { if (parts.get(i).getHeaders().containsKey("Content-Disposition")) { ArrayList<String> list = (ArrayList<String>)parts.get(i) .getHeaders().get("Content-Disposition"); // Es ist nur ein einziger Content-Disposition-Header pro Teil vorhanden. // Deshalb ist es sicher, list.get(0) zu verwenden: Map<String, String> cdHeaderMap = parseContentDispositionHeader(list.get(0)); String filename = cdHeaderMap.get("filename"); if (filename != null) { // Dieser Teil ist eine Datei. byte[] bytes = readInputStream(parts.get(i).getInputStream()); // Bytes bearbeiten: in das Dateisystem schreiben oder // an einen Dateihandler übergeben. // ... } } } // ... }
Andere Teile der BufferedInMultiPart-Formularübergabe können Eingabefelder mit regulärem HTML-Texttyp oder Kontrollkästchen sein. Die Verarbeitung dieser Teile wurde in dieser Beispielanwendung weggelassen.
Die Dateiteile, die vom Dojo-Widget "dojox.form.Uploader" übergeben wurden, wurden erfolgreich empfangen und verarbeitet.
Die JAX-RS-Anwendung, die Sie bisher erstellt haben, reicht für den Empfang und die Verarbeitung der multipart/form-data-Nachrichtennutzdaten aus, die von "dojox.form.Uploader" übergeben werden. Jetzt müssen Sie die Antwort, die "dojox.form.Uploader" erwartet, bzw. die Besonderheiten dieser Antwort, die von der größeren übergeordneten Clientanwendung gefordert wird, verstehen. Die Dokumentation zu "dojox.form.Uploader" beschreibt, dass die Antwort einen Content-Type-Header "text/html" enthalten muss. In einer JAX-RS-Ressourcenklasse lässt sich dies einfach deklarieren. Sie müssen lediglich den Inhaltstyp in einer Annotation "@Produces" auf Methodenebene deklarieren. Die JAX-RS-Laufzeitumgebung ordnet den entsprechenden HTTP-Header zu, z. B.:
@POST @Consumes(MediaType.MULTIPART_FORM_DATA) @Produces(MediaType.TEXT_HTML) public String upload(BufferedInMultiPart bimp) { // ... }
Außerdem beschreibt die Dokumentation zu "dojox.form.Uploader", dass die Antwort ein JSON-Array sein muss, das in ein Tag <textarea> eingeschlossen werden muss, wenn dem Benutzeragenten des Browsers über einen Browser, der HTML5 nicht unterstützt, geantwortet wird. Bis auf Weiteres wird angenommen, dass der Standardbenutzeragent ein Browser ist, der HTML5 nicht unterstützt, der kein HTML5-Browser und nicht Shockwave Flash ist. Basierend auf der vorherigen Implementierung und dem Import von com.ibm.json.java.JSONArray und com.ibm.json.java.JSONObject können Sie das zurückgegebene JSON-Array mit dem Inhalt, der von der Dojo-Beispielclientanwendung benötigt wird, bereitstellen.
@POST @Consumes(MediaType.MULTIPART_FORM_DATA) @Produces(MediaType.TEXT_HTML) public String upload(@Context UriInfo uriInfo, BufferedInMultiPart bimp) { JSONArray jsonArray = new JSONArray(); List<InPart> parts = bimp.getParts(); for (int i = 0; i < parts.size(); i++) { if (parts.get(i).getHeaders().containsKey("Content-Disposition")) { ArrayList<String> list = (ArrayList<String>)parts.get(i) .getHeaders().get("Content-Disposition"); // Es ist nur ein einziger Content-Disposition-Header pro Teil vorhanden. // Deshalb ist es sicher, list.get(0) zu verwenden: Map<String, String> cdHeaderMap = parseContentDispositionHeader(list.get(0)); String filename = cdHeaderMap.get("filename"); if (filename != null) { //Dieser Teil ist eine Datei. byte[] bytes = readInputStream(parts.get(i).getInputStream()); // Bytes bearbeiten: in das Dateisystem schreiben oder // an einen Dateihandler übergeben. // ... // Rückgabeobjekt erstellen, das von dem Dojo-Beispielclient benötigt wird. JSONObject jsonObject = new JSONObject(); jsonObject.put("uri", getFileURL(uriInfo, filename)); jsonObject.put("name", filename); jsonArray.add(jsonObject); } } } // Beispiel für die Rückgabe: // <textarea>[{"uri":"/fileuploader/rest/upload/uploadedfile.jpg", // "name":"uploadedfile.jpg"}] // </textarea> return "<textarea>" + jsonArray.toString() + "</textarea>"; }
Die Dokumentation zum Widget "dojox.form.FileUploader" beschreibt, dass der Header "User-Agent" das Format der Antwort bestimmt. Außerdem beschreibt die Dokumentation zum Widget "dojox.form.Uploader", dass der Service, der die Uploads empfängt, das Feld "name" von multipart/form-data "parts" verwenden muss, um den Absender der Daten zu bestimmen und entsprechend zu antworten. Das folgende Beispiel enthält den Namen und die Teile.
// Verschiedene Clients, die hochladen, erfordern unterschiedliche Antworten. // "dojox.form.FileUploader" und "dojox.form.Uploader" müssen verarbeitet werden. enum UPLOAD_TYPE { HTML5, HTML, FLASH }; UPLOAD_TYPE uploadType; @POST @Consumes(MediaType.MULTIPART_FORM_DATA) @Produces(MediaType.TEXT_HTML) public String upload(@Context ServletConfig servletConfig, @Context HttpHeaders httpHeaders, @Context UriInfo uriInfo, BufferedInMultiPart bimp) throws IOException { // Reguläres HTML-Formular annehmen uploadType = UPLOAD_TYPE.HTML; JSONArray jsonArray = new JSONArray(); List<InPart> parts = bimp.getParts(); for (int i = 0; i < parts.size(); i++) { if (parts.get(i).getHeaders().containsKey("Content-Disposition")) { ArrayList<String> list = (ArrayList<String>) parts.get(i) .getHeaders().get("Content-Disposition"); // Es ist nur ein einziger Content-Disposition-Header pro Teil vorhanden. // Deshalb ist es sicher, list.get(0) zu verwenden: Map<String, String> cdHeaderMap = parseContentDispositionHeader(list.get(0)); String name = cdHeaderMap.get("name"); // Clienttyp bestimmen. Siehe die Dokumentation zu "dojox.form.Uploader". if (name != null && name.contains("s[]")) { uploadType = UPLOAD_TYPE.HTML5; } else if (name != null && name.equals("uploadedfilesFlash")) { uploadType = UPLOAD_TYPE.FLASH; } String filename = cdHeaderMap.get("filename"); if (filename != null) { // this Part is a file byte[] bytes = readInputStream(parts.get(i).getInputStream()); // Bytes bearbeiten: in das Dateisystem schreiben oder // an einen Dateihandler übergeben. // ... // Rückgabezeichenfolge erstellen, die von dem Dojo-Beispielclient benötigt wird. JSONObject jsonObject = new JSONObject(); jsonObject.put("uri", getFileURL(uriInfo, filename)); jsonObject.put("name", filename); jsonArray.add(jsonObject); } } } List<String> userAgentHeaders = httpHeaders .getRequestHeader(HttpHeaders.USER_AGENT); // Es ist nur ein einziger User-Agent-Header vorhanden. Deshalb ist es sicher, get(0) zu verwenden. String userAgent = userAgentHeaders == null ? null : userAgentHeaders.get(0); // Wenn der Flash-Client verwendet wurde, sind spezielle Nutzdaten für // das Antwortformat erforderlich, nicht JSON if (uploadType == UPLOAD_TYPE.FLASH || "Shockwave Flash".equals(userAgent)) { String flashString = ""; for (int i = 0; i < jsonArray.size(); i++) { JSONObject jsonObject = ((JSONObject) jsonArray.get(i)); Set<String> set = (Set<String>) jsonObject.keySet(); for (Iterator<String> it = set.iterator(); it.hasNext();) { String key = it.next(); flashString += key + "=" + jsonObject.get(key) + ","; } } // Abschließendes Komma entfernen. flashString = flashString.substring(0, flashString.length() - 1); return flashString; } else if (uploadType == UPLOAD_TYPE.HTML5) { return jsonArray.toString(); } String result = "<textarea>" + jsonArray.toString() + "</textarea>"; // Temporärer iframe, der zum Senden der AJAX-Abfrage verwendet wird, erfordert, dass die // zurückgegebenen Daten in einen Textbereich eingeschlossen werden. Dies ist für // "dojox.form.FileUploader" und "dojox.form.Uploader" bei Browsern ohne HTML5-Unterstützung erforderlich. // Weitere Informationen finden Sie in der Dokumentation zu "dojox.form.Uploader". return result; }
Sie sehen, dass die Uploadmethode jetzt einen weiteren Parameter akzeptiert: @Context UriInfo uriInfo. Die Annotation @Context weist die JAX-RS-Laufzeitumgebung an, eine Instanz des deklarierten Typs in die Aufrufparameter der Uploadmethode zu injizieren. Der Lebenszyklus dieser injizierten Instanz ist auf eine einzige HTTP-Anforderung beschränkt. Diese injizierte UriInfo-Instanz muss den URL erkennen, der zum Aufrufen der Upload-Methode verwendet wurde. Sobald Sie diese Informationen haben, können Sie sie verwenden, um den Ressourcen-URL der soeben hochgeladenen Dateien zurückzugeben, so dass die Dojo-Clientanwendung die HTTP-GET-Anforderung aufrufen kann, die die Dateiressource hochgeladen hat. Dies entspricht den bewährten Verfahren von REST-Schnittstellen.
Jetzt empfängt das Widget "dojox.form.Uploader" die erforderliche Antwort und übergibt die formatierten Daten als JavaScript-Objekt zurück an die Dojo-Clientanwendung, die diese verwendet, um die kürzlich hochgeladene Dateiressource anzufordern.
Die Dienstprogrammmethoden, die über Ihre Uploadmethodenimplementierung aufgerufen werden, wie z. B. parseContentDispositionHeader, readInputStream und getFileURL, sind hier nicht beschrieben, können aber im eingeschlossenen Beispielquellcode untersucht werden.
Die Dojo-Clientanwendung möchte die soeben hochgeladene Datei unmittelbar nach dem Empfang der Antwort von der POST-Anforderung anzeigen. Die Antwort der POST-Anforderung enthält einen URI zu den hochgeladenen Dateien, der im Attribut "src" eines generierten Tags <img> verwendet wird. Deshalb muss die JAX-RS-Ressourcenklasse eine von zwei Aktionen ausführen:
- Hochgeladene Datei an einer über das Web zugänglichen Position speichern und den statischen URL an die Datei zurückgeben
- Hochgeladene Datei an einer bekannten Position speichern und einen URL an die Java-Methode zurückgeben, die eine HTTP-GET-Abfrage verarbeiten kann
Das folgende Beispiel demonstriert die zweite Aktion, bei der die Java-Methode der JAX-RS-Ressourcenklasse hinzugefügt wird:
@GET @Path("{filename}") public Response getImage(@PathParam("filename") String filename) throws FileNotFoundException { File file = new File(rootPath + "/" + filename); if (file.exists()) { String fileNameExtension = file.toString().substring(0, file.toString().lastIndexOf('.')); // Standard für Browser MediaType mediaType = MediaType.APPLICATION_OCTET_STREAM_TYPE; if (fileNameExtension.equals("jpg")) { mediaType = new MediaType("image", "jpeg"); } else if (fileNameExtension.equals("gif")) { mediaType = new MediaType("image", "gif"); } else if (fileNameExtension.equals("png")) { mediaType = new MediaType("image", "png"); } else if (fileNameExtension.equals("zip")) { mediaType = new MediaType("image", "zip"); } return Response.ok() .type(mediaType) .entity(new FileInputStream(file)) .build(); } // Die angeforderte Ressource ist nicht vorhanden. Fehler 404 zurückgeben. throw new WebApplicationException(Response.Status.NOT_FOUND); }
Zu dieser Java-Methode sind verschiedene Aspekte zu beachten. Die in der Annotation "@Path" deklarierte Zeichenfolge wird in geschweiften Klammern deklariert, so dass sie als Parameter an die Methode "getImage" übergeben wird. Das bedeutet, dass der Anforderungs-URL für diese Java-Methode, die die GET-HTTP-Methode unterstützt, http://<Server>:<Port>/fileuploader/rest/upload/uploadedfile.jpg ist. Das von dieser Methode "getImage" zurückgegebene Objekt ist ein JAX-RS-Antwortobjekt (Response). Dies gibt Ihnen mehr Kontrolle über die Besonderheiten der Antwort, als es mit JAX-RS-Annotationen möglich ist. Deklarieren Sie den Inhaltstyp der Antwort, und übergeben Sie den unaufbereiteten Dateieingabedatenstrom zurück an die JAX-RS-Laufzeitumgebung. Der Browser kann über den URL, der in der Antwort der POST-Abfrage angegeben ist, auf die kürzlich hochgeladene Dateiressource zugreifen. Die eigentliche Java-Datei kann sich überall auf dem Server befinden.
Beachten Sie die Verwendung der Variablen rootPath. Dieser Variablenwert wird von dem Konfigurationsparameter definiert, der in einem Initialisierungsparameter (init-parm) der Datei "web.xml" definiert ist, und kann über ein über @Context injiziertes ServletConfig-Instanzobjekt abgerufen werden. Sehen Sie sich den Beispielquellcode an, um mehr über dieses Feature zu erfahren.
Jetzt unterstützt die JAX-RS-Ressourcenklasse POST- und GET-Anforderungen, um die Anforderungen des Widgets "dojox.form.Uploader" und der übergeordneten Dojo-Clientanwendung zu erfüllen. Da es sich um eine REST-Schnittstelle handelt, möchten Sie jetzt auch, dass die Methode DELETE für das Löschen hochgeladener Dateiressourcen unterstützt wird. Fügen Sie dazu der JAX-RS-Ressourcenklasse die folgende Java-Methode hinzu:
@DELETE @Path("{filename}") public Response deleteImage(@PathParam("filename") String filename) { File file = new File(rootPath + "/" + filename); if (file.exists()) { file.delete(); } else { // Eine nicht vorhandene Ressource kann nicht gelöscht werden. // Fehler 404 zurückgeben. throw new WebApplicationException(Response.Status.NOT_FOUND); } return Response.ok().build(); }
Diese Methode ist der Methode GET sehr ähnlich. Sie empfängt den Dateinamen als PathParam-Methodenparameter und versucht, die Dateiressource zu löschen. Beachten Sie die Verwendung der Annotation @DELETE. Die Unterstützung für DELETE wird in alle Webcontainer des Anwendungsservers integriert. Jetzt kann die Dojo-Clientanwendung die Methode "xhrDelete" verwenden, um DELETE-HTTP-Anforderungen an diese JAX-RS-Ressourcenklasse zu senden.
Die bewährten REST-Verfahren legen fest, dass beim Erstellen einer neuen Ressource über eine POST-Anforderung die Antwort dieser POST-Anforderung einen HTTP-Positionsheader (Location) mit einem URI zu dieser neuen Ressource enthalten muss. Die Anwendung File Uploader ist insofern jedoch keine "reine" REST-Ressource, als sie mehrere Dateien in einer einzigen POST-Nachricht empfangen könnte und somit mehrere neue Dateiressourcen erstellt werden. Deshalb gibt die Beispielanwendung keinen HTTP-Positionsheader zurück.
Der Quellcode der Beispielanwendung File Uploader wird in der Webmoduldatei "FileUploader.war" in der Datei "FileUploader.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.
Wenn Sie den Quellcode anzeigen möchten, müssen Sie zuerst die Datei "FileUploader.ear" suchen. Haben Sie IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile installiert, können Sie die EAR-Datei in Ihrer Installationsstruktur finden.
Angenommen, Sie haben das Feature-Pack im folgenden Verzeichnis installiert:
Plattform Position 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:
Plattform Position Linux und UNIX: /opt/WebSphere/AppServer/web2mobilefep_1.1/samples/fileuploader/appsvcs-fileuploader.ear z/OS: <Installationsstammverzeichnis>/web2mobilefep_1.1/samples/fileuploader/appsvcs-fileuploader.ear Windows: c:\WebSphere\AppServer\web2mobilefep_1.1\samples\fileuploader\appsvcs-fileuploader.ear
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 bzw. Rational Application Developer Version 7.0 oder höher, um die WAR-Datei zu importieren:
Nach Abschluss des Importprozesses ist ein neues Projekt, FileUploader, im Eclipse-Arbeitsbereich vorhanden. Der Quellcode der Anwendung kann über das Projekt "FileUploader" 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 "FileUploader" 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.fileuploader/ FileUploaderApplication.java: Klicken Sie doppelt auf diese Datei, um den Quellcode zu laden. |
Java-Ressourcen: src/com.ibm.websphere.mobile.appsvcs.sample.fileuploader. resources/MultiFileUploadDataService.java: Klicken Sie doppelt auf diese Datei, um den Quellcode zu laden. |
Webanwendungsarchive (WAR, Web Application Archive) sind Dateiarchive, die mit dem ZIP-Algorithmus komprimiert werden. Deshalb kann die Archivdatei mit einer Reihe von ZIP-Tools, 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.
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/FileUploader 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/fileuploader/ FileUploaderApplication.java |
WEB-INF/classes/com/ibm/websphere/mobile/appsvcs/sample/fileuploader/ resources/MultiFileUploadDataService.java |
Lesen Sie die folgenden versionsspezifischen Installationsanweisungen:
In diesem Abschnitt wird die Prozedur zum Installieren der Beispielanwendung File Uploader 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.
Suchen Sie die EAR-Datei der Beispielanwendung File Uploader, 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:
Plattform Position 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:
Plattform Position Linux und UNIX: /opt/WebSphere/AppServer/web2mobilefep_1.1/samples/application_services/fileuploader/appsvcs-fileuploader.ear z/OS: <Installationsstammverzeichnis>/web2mobilefep_1.1/samples/application_services/fileuploader/appsvcs-fileuploader.ear Windows: c:\WebSphere\AppServer\web2mobilefep_1.1\samples\application_services\fileuploader\appsvcs-fileuploader.ear
- Melden Sie sich bei der Administrationskonsole des Anwendungsservers an.
- Klicken Sie auf Anwendungen > Neue Anwendung. (Anmerkung: In WebSphere Application Server Version 6.1 wählen Sie Neue Anwendung installieren aus.)
- Wählen Sie Neue Unternehmensanwendung aus. (Anmerkung: In WebSphere Application Server Version 6.1 überspringen Sie diesen Schritt.)
- Durchsuchen Sie Ihr Dateisystem, und wählen Sie die Datei "appsvcs-graphics.ear" aus, die Sie zuvor gesucht haben. Klicken Sie auf Weiter.
- Klicken Sie auf Weiter, um die Anwendungsinstallation vorzubereiten. (Anmerkung: In WebSphere Application Server Version 6.1 überspringen Sie diesen Schritt.)
- Klicken Sie auf Weiter, um die Standardinstallationsoptionen zu akzeptieren.
- Klicken Sie auf Weiter, um die Standardoptionen für die Zuordnung von Modulen zu Servern zu akzeptieren.
- 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.)
- Klicken Sie auf Weiter, um die Standardoptionen für die Zuordnung virtueller Hosts zu Webmodulen zu akzeptieren.
- Überprüfen Sie die Zusammenfassung der Installationsoptionen.
- Klicken Sie auf Fertig stellen.
- Klicken Sie auf In Masterkonfiguration speichern.
- Klicken Sie auf Anwendungen > Anwendungstypen > WebSphere-Unternehmensanwendungen. (Anmerkung: In WebSphere Application Server Version 6.1 klicken Sie auf Anwendungen > Enterprise-Anwendungen.)
- Wählen Sie IBM WebSphere Application Server - File Uploader sample application aus, und klicken Sie anschließend auf Starten.
Rufen Sie in Ihrem Web-Browser Ihre Anwendungsserverinstallation auf: http://<Hostname_des_Anwendungsservers>:<Port>/appsvcs-fileuploader/.
Der Hostname des Anwendungsservers und der Port sind Angaben, die für Ihre Anwendungsserverinstallation spezifisch sind. Ein Webcontainerport für 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-fileuploader/.
In diesem Abschnitt wird die Vorgehensweise bei der Installation der Beispielanwendung File Uploader 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.
Suchen Sie die EAR-Datei der Beispielanwendung File Uploader, 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:
Plattform Position Linux und UNIX: /opt/WebSphere/AppServerCommunityEdition Windows: c:\WebSphere\AppServerCommunityEdition
In diesem Fall finden Sie die EAR-Dateien und Bibliotheksdateien an folgender Position:
Plattform Position Linux und UNIX: /opt/WebSphere/AppServerCommunityEdition/web2mobilefep_1.1/AppServices/samples/fileuploader/appsvcs-fileuploader.ear Windows: c:\WebSphere\AppServerCommunityEdition\web2mobilefep_1.1\AppServices\samples\fileuploader\appsvcs-fileuploader.ear
Melden Sie sich bei der Administrationskonsole des Anwendungsservers an.
- 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.)
- Suchen Sie über das Feld Archiv in Ihrem Dateisystem die Datei "appsvcs-fileuploader.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.
Rufen Sie in Ihrem Web-Browser Ihre Anwendungsserverinstallation auf: http://<Hostname_des_Anwendungsservers>:<Port>/appsvcs-fileuploader/.
Der Hostname des Anwendungsservers und der Port sind Angaben, die für Ihre Anwendungsserverinstallation spezifisch sind. Der Webcontainerport für die Standardinstallation eines Servers in 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: