Initiation de l'exemple d'application File Uploader

Cette page représente le point de départ de découverte de l'application File Uploader. Les rubriques suivantes sont traitées :

Présentation de l'application File Uploader

L'exemple d'application File Uploader a été créée pour compléter l'utilisation de widgets dojox.form.File Uploader et dojox.form.Uploader du Dojo Toolkit for JavaScript. L'exemple File Uploader montre comment développer une application JAX-RS REST (Representational State Transfer) qui peut recevoir et répondre des/aux téléchargements provenant des widgets dojox.form.FileUploader et dojox.form.Uploader dans le Dojo Toolkit.

Les widgets dojox.form.FileUploader et dojox.form.Uploader téléchargent des fichiers de manière standard, comme un formulaire HTML de navigateur Web. Un message HTTP codé multipart/form-data est utilisé. La ressource JAX-RS reçoit les données de formulaire soumis déjà analysées dans ses différentes parties. Ce processus simplifie considérablement l'implémentation du code de serveur. La classe de ressource JAX-RS doit simplement itérer sur les parties et traiter les données en fonction.

L'objectif principal de cet exemple File Uploader est de prouver la simplicité et la fonctionnalité de la classe de ressource JAX-RS. Toutefois, pour montrer complètement cette simplicité, le widget dojox.form.Uploader est inclus en tant que composant dans une plus grande application Dojo. Consultez les rubriques concernant l'application File Uploader pour un exemple.

Prérequis

Prérequis produit Version
Java Technology Edition 5.0 et version ultérieure
Serveur d'application Java Platform, Enterprise Edition 5 (Java EE) et version ultérieure

WebSphere Application Server Version 6.1.0.x et ultérieure

WebSphere Application Server Community Edition Version 2.X.

Navigateur Web Tout navigateur Web moderne, tel que : Internet Explorer 7 et version ultérieure Mozilla Firefox 3.x et version ultérieure Google Chrome Safari Opera
Development IDE (facultatif) Eclipse version 3.X

Limitations de l'exemple de l'application File Uploader

L'exemple d'application File Uploader n'est pas destiné à un déploiement sur les serveurs de production. Il est créé à des fins de développement et d'éducation uniquement.

Tout le code source de l'application JAX-RS application, de ressource et des pages Web est fourni tel quel pour que vous l'utilisiez, copiez et modifiez sans paiement de royaltie lorsque vous développez des applications exécutées avec le logiciel WebSphere. Vous pouvez utiliser les exemples de code pour vos besoins internes ou pour le redistribuer dans le cadre d'une application ou de vos produits.

Ecriture de l'exemple d'application File Uploader

La conception de l'exemple d'application File Uploader montre comment approcher le développement d'une application basée sur AJAX avec le Dojo Toolkit dans un environnement Java EE selon la configuration requise des widgets dojox.form.FileUploader et dojox.form.Uploader Dojo. Pour cela, les deux parties d'une application Java EE, le côté client et le côté serveur, sont organisés en opérations simples effectuant une fonction utile. Le modèle basique, utilisé par les applications Java EE lors de l'incoroporation des technologies AJAX, est utilisé.

Suppositions

Les sections suivantes supposent que vous connaissez déjà l'infratructure JavaScript pour Dojo ; elles n'expliquent pas en détails l'exemple d'application client Dojo ou le widget Dojo dojox.form.Uploader utilisé.

Le client

Le client n'est autre que la page Web qui est servie au navigateur. Dans la page Web, le widget dojox.form.Uploader est instancié et les événements de navigateur ont connectés à ce widget. Le parcours du système de fichiers est effectuée par Shockwave Flash, ou bien directement par l'infrastructure JavaScript pour Dojo. Le widget dojox.form.Uploader utilise HTML5 si le navigateur en cours le prend en charge et diminue progressivement vers Shockwave Flash ou HTML normal selon les capacités du navigateur. Il autorise la sélection de plusieurs fichiers en même temps, et soumet les téléchargements de fichier via HTML5 ou un iframe HTML mis en cache. Cette utilisation d'une iframe masquée pour effectuer le téléchargement est requise à cause du type de contenu multipart/form-data en cours d'envoi. La réponse entraîne alors des mises à jour de page partielles. Ce processus, s'il est géré par le navigateur conforme HTML5 ou Shockwave Flash, se produit sans entraîner de rechargement de la page complète. Le widget dojox.form.FileUploader est déprécié vers Dojo 1.6 et il est planifié pour une suppression dans Dojo 2.0. Il a été remplacé par dojox.form.Uploader. L'exemple de service, toutefois, est capable de détecter la configuration requise imposée par chacun des deux widgets et d'y répondre de manière appropriée. Pour des informations plus spécifiques sur la conception client, consultez la rubrique sur l'exemple d'application File Uploader pour le client.

Le serveur

Le serveur fournit l'infrastructure du traitement des services et du service des pages Web. Dans cette application, le côté serveur est une classe de ressource JAX-RS qui reçoit et traite les requêtes POST multipart/form-data des widgets dojox.form.FileUploader et dojox.form.Uploader, et répond selon les prérequis de ces widgets et l'application Dojo intégrée. Pour le widget dojox.form.FileUploader, la réponse dépend de l'agent de l'utilisateur (le navigateur ou Shockwave Flash) lançant la requête POST. Pour le widget dojox.form.Uploader, la réponse dépend de la zone "nom" de la "partie" multipart/form-data contenant la charge du fichier. Pour les transactions initiées par un navigateur non adapté à HTML5, JavaScript Object Notation (JSON) dans une balise de zone de texte HTML est renvoyé. Pour les transactions en HTML5, JSON est renvoyé. Si Shockwave Flash a lancé la transation, une chaîne personnalisée est renvoyée. Le contenu de JSON ou de la chaîne personnalisée est générée selon les prérequis de l'application utilisant les widgets dojox.form.FileUploader et dojox.form.Uploader. Pour plus d'informations sur la conception côté serveur, consultez la rubrique sur l'exemple d'application File Uploader pour le serveur.

L'exemple d'application File Uploader pour le client

L'exemple d'application File Uploader utilise le widget dojox.form.Uploader pour autoriser le contrôle de navigation sur le système de fichiers local de l'utilisateur à de fins de sélection, et il fournit le contrôle pour soumettre les données lorsque vous cliquez sur le bouton de soumission du widget. Le contrôle de navigation dojox.form.Uploader est activé par le widget à l'aide de l'entrée de fichier de formulaire standard ou en activant l'application Shockwave Flash, si le navigateur a le plug-in Shockwave Flash installé. Lors de la navigation dans le système de fichiers local à l'aide des contrôles HTML5 du navigateur, l'utilisateur peut sélectionner plusieurs fichiers en même temps. Lors de l'utilisation du plug-in Shockwave Flash, l'utilisateur peut également sélectionner plusieurs fichiers en même temps durant la navigation du système de fichiers local. Les navigateurs qui ne prennent pas en charge HTML5 permettent uniquement la sélection d'un fichier en même temps durant la navigation dans le système de fichiers local, mais plusieurs fichiers peuvent être placés en file d'attente avant leur soumission pour téléchargement.

L'application créée avec le widget dojox.form.Uploader inclut des liens pour activer ou désactiver la prise en charge des fonctions individuelles du widget dojox.form.Uploader. Ils sont inclus dans le cadre de l'application pour démontrer la fonction du widget.

En outre, l'application reçoit des données de réponse du serveur via le widget dojox.form.Uploader et l'utilise pour afficher les fichiers récemment téléchargés si possible. Elle garde également une liste des fichiers pour activer leur suppression du serveur. Ce bouton enclenche la fonction deletePreviousUploads dans l'application, qui supprime le fichiers de la liste affichée et utilise les requêtes Dojo AJAX xhrDelete pour demander que le serveur supprime les ressources de fichiers récemment téléchargés.

Si vous connaissez déjà dojox.form.Uploader, vous pouvez voir que cette application est similaire à celle des tests fournis avec dojox.form.Uploader dans Dojo Toolkit 1.6. Cet exemple de client est fortement basé sur ce test, mais il existe une différence majeure. La plupart des serveurs HTTP ne prennent pas en charge la méthode HTTP DELETE, le test original n'incluait donc pas de telle fonction. Toutefois, l'application client Dojo ne prend pas en charge la méthode DELETE.

L'objectif principal de cet exemple d'application File Uploader est de montrer la simplicité de l'obtention d'une ressource JAX-RS développée qui peut recevoir des soumissions de dojox.form.Uploader, l'exercice de compréhension et d'encodage du client est laissé au lecteur.

Pour en savoir plus sur l'utilisation du côté client, reportez-vous au code source de l'application. Chaque section du document HTML est en effet commentée avec des explications sur la finalité du bloc de code.

L'exemple d'application File Uploader pour le server

Au minimum, l'exemple d'application File Uploader pour le serveur doit être capable de recevoir une requête POST avec un type de contenu multipart/form-data. Ceci accomodera les prérequis du widget dojox.form.Uploader. Cet exemple d'application client Dojo incluant dojox.form.Uploader est capable d'afficher les fichiers récemment téléchargés. Cela signifie que notre ressource JAX-RS devra renvoyer les données au client qui inclut l'URL du fichier venant d'être téléchargé, et peut répondre à la requête GET pour ledit fichier. En outre, nous voulons que le client puise demander la suppression de la ressource de fichier récemment téléchargée. Ceci signifie que notre ressource JAX-RS doit également avoir une méthode pouvant recevoir les requêtes DELETE.

L'exécution JAX-RS a une fonction intégrée d'analyse de charge de multipart/form-data et de transmission de données dans une instance d'objet org.apache.wink.common.model.multipart.BufferedInMultiPart à une méthode de classe de ressource JAX-RS.

Création de la classe de ressource JAX-RS qui va recevoir les requêtes HTTP

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
{
   // ...
}

Notez que cette classe de ressource JAX-RS est déclarée avoir un segment d'URL de "téléchargement". Cette classe de ressource va gérer les requêtes ciblées sur http://<server>:<port>/<context-root>/<uri-mapping>/upload

La racine de contexte est définie par le fichier application.xml si votre fichier archive Web (.war) est intégré à un fichier .ear. Si le fichier .war est installé seul, la racine de contexte est définie au moment de l'installation par l'utilisateur. Le mappage d'URI est défini dans le WEB-INF/web.xml du fichier .war.

Création des méthodes de ressource JAX-RS

Le widget dojox.form.Uploader ssoumet la charge comme tout navigateur, en HTTP POST avec un en-tête Type-Contenu de multipart/form-data. Ces informations, avec l'URL cible, sont utilisées par l'exécution JAX-RS pour correspondre au message entrant avec la méthode Java qui va le recevoir. Par conséquent, implémentez une méthode dans la classe de ressource JAX-RS pour l'accepter.

@POST
@Consumes(MediaType.MULTIPART_FORM_DATA)
public String upload(BufferedInMultiPart bimp)
{
   // ...
}

L'annotation @POST déclare que cette méthide recevra les requêtes HTTP POST à la fin de l'URL avec "téléchargement". Notez également que vous avons déclaré @Consumes. Ceci aide l'exécution JAX-RS à faire correspondre le message entrant à la méthode Java. L'exécution JAX-RS va essayer de correspondre à l'en-tête Type-Contenu du message entrant avec la valeur @Consumes.

Création de la classe d'application coeur JAX-RS

A ce stade, une classe supplémentaire est requise pour terminer l'application. JAX-RS initialise une application et ses ressources et fournisseurs via la classe développant javax.ws.rs.core.Application. Par conséquent, créez la classe suivante.

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;
   }
}

Activation de l'application JAX-RS dans web.xml

Nous devons maintenant assembler toutes les pièces dans le fichier web.xml. Vous trouverez ci-dessous les parties critiques de l'activation de cette application JAX-RS.

...
<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>
...

Notez la classe servlet-class et le paramètre init-param avec param-name javax.ws.rs.Application. Il s'agit du moyen standard de déclarer l'implémentation servlet et transmettre la référence de la classe développant javax.ws.rs.core.Application dans l'exécution JAX-RS.

Avec l'inclusion de WEB-INF/web.xml, l'application compilée et les bons fichiers de bibliothèque dans le répertoire WEB-INF/lib/ du fichier .war, l'application peut être installée sur un serveur d'application. Voir le contenu de l'exemple inclus si vous souhaitez voir la liste des bibliothèques requises. L'exemple d'application incluse est sous la forme d'un fichier .war intégré à un fichier .ear. Dans le fichier .ear, vous trouverez le fichier application.xml standard, qui indique la raconte contexte URL de "/appsvcs-fileuploader". L'URL du fichier index.html est http://<server>:<port>/appsvcs-fileuploader/. Notez que l'URL indiquée dans le fichier index.html de l'exemple d'application est "rest/upload", qui est relatif à l'emplacement du fichier index.html et le résultat de la concaténation de l'url-pattern de web.xml et l'annotation @Path de la classe de ressource JAX-RS.

Pour plus de détails sur l'implémentation de la méthode de réception et de traitement de la charge de message multipart/form-data, affichez le code source ou continuez de lire.

Implémentation de la méthode de téléchargement

La méthode de téléchargement reçoit un objet BufferedInMultiPart, qui est la charge de message multipart/form-data déjà analysée. Action prise de chaque côté.

@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");

         // Only one Content-Disposition header exists per part.
         // Therefore, it is safe to use list.get(0):
         Map<String, String> cdHeaderMap =
                                  parseContentDispositionHeader(list.get(0));
         String filename = cdHeaderMap.get("filename");
         if (filename != null) {
            // This part is a file.
            byte[] bytes = readInputStream(parts.get(i).getInputStream());
            // Do something with the bytes; write to file system,
            // or pass to a file handler.
            // ...
         }
      }
   }
   // ...
}

D'autres parties de la soumission de formulaire BufferedInMultiPart peuvent être des cases ou zones d'entrées de type de texte HTML classique. Le traitement de ces parties est omis de cet exemple.

Nous avons reçu correctement et traité les parties de fichier soumises du widget Dojo dojox.form.Uploader.

Autre support

L'application JAX-RS que vous avez créée jusque là est suffisante pour recevoir et traiter la charge de message multipart/form-data soumise par dojox.form.Uploader. Maintenant, vous devez comprendre la réponse requise par the dojox.form.Uploader, ou les spécificités de cette réponse nécessaires à la plus grande application client intégrée. La documentation pour dojox.form.Uploader indique que la réponse doit avoir un en-tête Type-Contenu de "text/html". Dans une classe de ressource JAX-RS, il n'est pas important de le déclarer. Vous devez uniquement déclarer le type de contenu dans une annotation de niveau de méthode @Produces. L'exécution JAX-RS affectera le bon en-tête HTTP, par exemple :

@POST
@Consumes(MediaType.MULTIPART_FORM_DATA)
@Produces(MediaType.TEXT_HTML)
public String upload(BufferedInMultiPart bimp)
{
   // ...
}

En outre, la documentation pour dojox.form.Uploader indique que la réponse doit être un tableau JSON encapsulé dans une balise <textarea> lors de la réponse à l'agent d'utilisateur du navigateur à partir d'un navigateur non HTML5. Pour l'instant, supposons que l'agent d'utilisateur par défaut est un navigateur non HTML5, n'est pas un navigateur HTML5 ni Shockwave Flash. Avec la génération sur la précédente implémentation ci-dessus, et maintenant l'importation de importing com.ibm.json.java.JSONArray et com.ibm.json.java.JSONObject, vous pouvez fournir le tableau JSON renvoyé avec le contenu requis par l'exemple de l'application client Dojo.

@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");

         // Only one Content-Disposition header exits per part.
         // Therefore, it is safe to use list.get(0):
         Map<String, String> cdHeaderMap =
                                  parseContentDispositionHeader(list.get(0));
         String filename = cdHeaderMap.get("filename");
         if (filename != null) {
            // This part is a file.
            byte[] bytes = readInputStream(parts.get(i).getInputStream());
            // Do something with the bytes; write to file system,
            // or pass to a file handler.
            // ...

            // Build up the return object as required by our sample Dojo client.
            JSONObject jsonObject = new JSONObject();
            jsonObject.put("uri", getFileURL(uriInfo, filename));
            jsonObject.put("name", filename);
            jsonArray.add(jsonObject);
         }
      }
   }

   // Example of what gets returned:
   // <textarea>[{"uri":"/fileuploader/rest/upload/uploadedfile.jpg",
   //             "name":"uploadedfile.jpg"}]
   // </textarea>
   return "<textarea>" + jsonArray.toString() + "</textarea>";
}

La documentation de widget dojox.form.FileUploader indique que l'en-tête d'agent d'utilisateur détermine le format de la réponse. La documentation du widget dojox.form.Uploader indique que le service recevant les téléchargements doit utiliser le "nom" des "parties" multipart/form-data afin de déterminer l'expéditeur des données et répondre en conséquence. L'exemple suivant inclut le nom et les parties.

// Different uploading clients require different responses.
// Both dojox.form.FileUploader and dojox.form.Uploader must be handled.
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
{
   // Assume regular html form
   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");

         // Only one Content-Disposition header exists per part.
         // Therefore, it is safe to use list.get(0):
         Map<String, String> cdHeaderMap =
                                  parseContentDispositionHeader(list.get(0));
         String name = cdHeaderMap.get("name");

         // Determine the client type.  See dojox.form.Uploader documentation.
         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());
            // Do something with the bytes; write to file system,
            // or pass to a file handler.
            // ...

            // Build up the return string as required by our sample Dojo client.
            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);
   // Only one User-Agent header exists  so it is safe to use get(0).
   String userAgent = userAgentHeaders == null ? null : userAgentHeaders.get(0);

   // If the Flash client was used, it requires a specific
   // response format payload, not 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) + ",";
         }
      }
      // Remove trailing comma.
      flashString = flashString.substring(0, flashString.length() - 1);
      return flashString;
   } else if (uploadType == UPLOAD_TYPE.HTML5) {
      return jsonArray.toString();
   }

   String result = "<textarea>" + jsonArray.toString() + "</textarea>";
   // Temporary iframe used to send AJAX query requires returned data
   // to be wrapped in text area. This is required by
   // dojox.form.FileUploader and dojox.form.Uploader for non-HTML5 browsers.
   // See dojox.form.Uploader documentation for more information.
   return result;
}

Vous remarquez que la méthode de téléchargement prend maintenant un paramètre supplémentaire : @Context UriInfo uriInfo. L'annotation @Context demande à l'exécution JAX-RS d'injecter une instance du type déclaré dans les paramètres d'appel de méthode de téléchargement. Le cycle de vie de cette instance injectée est par requête HTTP. Cette instance UriInfo injectée doit détecter l'URL qui était utilisée pour appeler la méthode de téléchargement. Une fois que vous disposez de ces informations, vous pouvez les utiliser pour renvoyer l'URL de ressource des fichiers venant d'être téléchargés pour que l'application client Dojo puisse appeler la requête GET HTTP ayant téléchargé la ressource de fichier. Ceci est en conforme aux meilleures pratiques des interfaces REST.

Maintenant le widget dojox.form.Uploader va recevoir la réponse requie, et transmettre les donnée formatées en objet JavaScript à nouveau sur l'application client Dojo, qui l'utilisera pour demander la ressource de fichier récemment téléchargé.

Les méthodes d'utilitaire appelées depuis notre implémentation de méthode de téléchargement, telles que parseContentDispositionHeader, readInputStream et getFileURL, ne sont pas décrites ici, mais peuvent être consultées dans l'exemple de code source inclus.

Utilisation de la requête GET pour extraire le fichier téléchargé

L'application client Dojo compte afficher le fichier venant d'être téléchargé immédiatement à réception de la réception de la requête POST. La réponse de la requête POST inclut une URI vers les fichiers téléchargés, qui sera utilisé dans la balise "src" attribute of a generated <img>. Par conséquent, notre classe de ressource JAX-RS doit effectuer l'une des actions suivantes :

  • Sauvegardez le fichier téléchargé à un emplacement accessible par le Web et renvoyez l'URL statique au fichier.
  • Sauvegardez le fichier téléchargé à un emplacement connu et renvoyez une URL vers la méthode Java pouvant traiter une requête HTTP GET.

L'exemple suivant montre la deuxième action, au cours de laquelle la méthode Java est ajoutée à la classe de ressource JAX-RS :

@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('.'));

      // This default is standard for browsers
      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();
   }
   // The requested resource does not exist.  Return a 404 error.
   throw new WebApplicationException(Response.Status.NOT_FOUND);
}

Il y a différents éléments à noter concernant cette méthode Java. D'abord, la chaîne déclarée dans l'annotation @Path est déclarée avec des accolades de sorte qu'elle soit transmise en paramètre de la méthode getImage. Cela signifie que l'URL de requête pour cette méthode Java prenant en charge la méthode HTTP GET est http://<server>:<port>/fileuploader/rest/upload/uploadedfile.jpg. L'objet renvoyé de cette méthode getImage est un objet de réponse JAX-RS. Ceci vous donne davantage de contrôle sur les spécificités de la réponse possible avec l'utilisation des annotations JAX-RS. Déclarez le Type-Contenu de la réponse et transmettez à nouveau le FileInputStream brut dans l'exécution JAX-RS. Pour le navigateur, la ressource de fichier récemment téléchargé est disponible à l'URL indiquée dans la réponse de la requête POST. Toutefois, le fichier Java actuel peut être n'importe où sur le serveur.

Notez l'utilisation de la variable rootPath. Cette valeur de variable est définie par un paramètre de configuration déclaré dans un init-param du fichier web.xml ; elle peut être extraite d'un objet d'instance ServletConfig injecté @Context. Voir l'exemple de code source pour cette fonction.

Suppression de ressources de fichier

A ce stade, notre classe de ressource JAX-RS prend en charge les requêtes POST et GET pour satisfaire les prérequis du widget dojox.form.Uploader et de l'application client Dojo intégrée. Etant donné qu'il s'agit d'une interface REST, vous pouvez également souhaiter prendre en charge la méthode DELETE afin de gérer la suppression des ressources de fichier téléchargés. Ajoutez la méthode Java suivante à notre classe de ressource JAX-RS :

 @DELETE
 @Path("{filename}")
 public Response deleteImage(@PathParam("filename") String filename)
 {
    File file = new File(rootPath + "/" + filename);
    if (file.exists()) {
       file.delete();
    } else {
       // You cannot delete a resource that does not exist.
       // Return a 404 error.
       throw new WebApplicationException(Response.Status.NOT_FOUND);
    }
    return Response.ok().build();
}

Notez que cette méthode est très similaire à GET. Elle reçoit le nom de fichier en objet de paramètre de méthode PathParam et tente de supprimer la ressource de fichier. Notez l'utilisation de l'annotation @DELETE. La prise en charge de DELETE est intégrée à tous les conteneurs Web de serveur d'application. L'application client Dojo peut maintenant utiliser la méthode xhrDelete pour envoyer les requêtes HTTP DELETE à cette classe de ressource JAX-RS.

Meilleures pratiques de l'interface REST

Les meilleures pratiques REST indiquent que lorsqu'une nouvelle ressource est créée via un POST, la réponse de ce POST doit inclure un en-tête HTTP d'emplacement avec un URI de cette nouvelle ressource. Toutefois, l'application File Uploader n'est pas une ressource REST "pure" étant donné qu'elle peut recevoir plusieurs fichiers dans un seul message POST, créant ainsi plusieurs ressources de fichier. L'exemple ne renvoie donc pas d'en-tête HTTP d'emplacement.

Affichage du code source de l'exemple d'application File Uploader

Le code source de l'exemple d'application File Uploader est fourni dan le fichier de module Web FileUploader.war du fichier FileUploader.ear. Il y a deux moyens d'afficher le code source : via un IDE Eclipse ou en décompressant successivement le fichier appsvcs-directorylisting.ear et le fichier .war contenu dans le fichier ear.

Localisation du fichier EAR

La première chose à faire pour visualiser le code source est de repérer le fichier FileUploader.ear. Si vous avez installé la version IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile, vous trouverez le fichier EAR dans votre arborescence d'installation.

Par exemple, si vous avez installé le module de fonctions à l'emplacement :

Linux et UNIX : /opt/WebSphere/AppServer
point de montage z/OS : <install_root>
Windows : c:\WebSphere\AppServer

Vous trouverez alors le fichier EAR à l'emplacement suivant :

Linux et UNIX : /opt/WebSphere/AppServer/web2mobilefep_1.1/samples/fileuploader/appsvcs-fileuploader.ear
z/OS : <install_root>/web2mobilefep_1.1/samples/fileuploader/appsvcs-fileuploader.ear
Windows : c:\WebSphere\AppServer\web2mobilefep_1.1\samples\fileuploader\appsvcs-fileuploader.ear

Affichage du code source dans un environnement de développement intégré Eclipse

Un IDE Eclipse est le moyen le plus simple d'examiner le code source du fichier WAR. Utilisez Eclipse 3.2.X, 3.3.X IDE avec Web Tools Project 2.5 ou version ultérieure, ou bien Rational Application Developer, Version 7.0 ou ultérieure, puis le fichier d'archive Web (WAR) en suivant la procédure comme suit :

  1. Développez le fichier appsvcs-fileuploader.ear.
  2. Dans le menu IDE Eclipse, ouvrez le menu Fichier et sélectionnez Importer.
  3. Dans le panneau qui s'affiche, développez l'option Web. Sélectionnez alors le fichier WAR, puis cliquez sur Suivant.
  4. Dans la zone Fichier WAR, cliquez sur Parcourir et sélectionnez le fichier que vous aviez repéré.
  5. Acceptez les options par défaut, si elles sont acceptables, puis cliquez sur Terminer.

Une fois l'importation terminée, un nouveau projet, FileUploader, existe dans l'espace de travail Eclipse. Le code source de l'application est accessible à partir du projet FileUploader. Pour accéder au code serveur ou client, consultez le tableau suivant qui donnent les emplacements du code source dans l'arborescence du projet Eclipse FileUploader.

Code source Emplacement
Côté client (navigateur Web) WebContent/index.html : contient les définitions des widgets Dojo et fonctions de script client. Ce fichier charge le profil Dojo non optimisé.
Côté serveur Ressources Java : src/com.ibm.websphere.mobile.appsvcs.sample.fileuploader/ FileUploaderApplication.java: Double-cliquez sur ce fichier pour charger le code source.
Ressources Java : src/com.ibm.websphere.mobile.appsvcs.sample.fileuploader. resources/MultiFileUploadDataService.java : Double-cliquez sur ce fichier pour charger le code source.

Affichage du code source en extrayant le fichier d'archive d'application Web

Les archives d'application Web sont des archives de fichiers compressés avec l'algorithme ZIP. L'archive peut donc être ouverte par plusieurs outils ZIP de compression de fichiers, dont le programme JAR. La procédure suivante suppoe que l'utilisateur choisisse son outil favori pour créer les fichiers compressés.

  1. Décompressez dans un répertoire de votre système le fichier FileUploader.ear avec l'outil de votre choix. La procédure suivante suppose que EXPAND_DIR/FileUploader est à l'emplacement correct.
  2. Listez les fichiers dan le répertoire EXPAND_DIR/FileUploader dans lequel le fichier FileUploader.ear a été développé.

Une fois que vous avez décompressé le contenu du fichier EAR, vous devez également développer le contenu du fichier .war. Vous pouvez alors accéder au code source. Pour accéder au code du client ou du serveur, consultez le tableau suivant qui donne les emplacements du code source dans le répertoire EXPAND_DIR/FileUploader.

Code source Emplacement
Côté client (navigateur Web) index.html : contient les définitions des widgets Dojo et fonctions de script client.
Côté serveur 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

Installation de l'exemple d'application File Uploader

Reportez-vous aux instructions d'installation spécifiques à chaque version :

Instructions d'installation WebSphere Application Server

Cette section décrit la procédure d'installation de l'exemple d'application File Uploader sur la Version 6.1.0.X et ultérieure d'IBM WebSphere Application Server. Vous devez avoir des bonnes connaissances sur l'administration et l'installation de l'application pour le serveur d'application.

Avant de commencer

Localisez le fichier d'archive (EAR) de l'exemple d'application File Uploader qui est fourni avec l'installation de votre produit. Vous le trouverez dans votre arborescence d'installation où vous avez installé IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile. Par exemple, si vous avez installé le module de fonctions à l'emplacement :

Linux et UNIX : /opt/WebSphere/AppServer
point de montage z/OS : <install_root>
Windows : c:\WebSphere\AppServer

Vous trouverez alors le fichier EAR à l'emplacement suivant :

Linux et UNIX : /opt/WebSphere/AppServer/web2mobilefep_1.1/samples/application_services/fileuploader/appsvcs-fileuploader.ear
z/OS : <install_root>/web2mobilefep_1.1/samples/application_services/fileuploader/appsvcs-fileuploader.ear
Windows : c:\WebSphere\AppServer\web2mobilefep_1.1\samples\application_services\fileuploader\appsvcs-fileuploader.ear

Installation de l'exemple d'application File Uploader à l'aide de la console d'administration

  1. Connectez-vous à la console administrative pour le serveur d'application.
  2. Naviguez jusqu'à Applications > Nouvelle application. (Note : dans WebSphere Application Server Version 6.1, sélectionnez Installation d'une nouvelle application)
  3. Sélectionnez New Enterprise Application. (Note : dans WebSphere Application Server Version 6.1, ignorez cette étape)
  4. Parcourez votre système de fichiers et sélectionnez le fichier appsvcs-graphics.ear localisé précédemment. Cliquez sur Suivant.
  5. Cliquez sur Suivant pour préparer l'installation d'application. (Note : dans WebSphere Application Server Version 6.1, ignorez cette étape)
  6. Cliquez sur Suivant pour accepter les options d'installation par défaut.
  7. Cliquez sur Suivant pour accepter les options par défaut pour le mappage des modules vers les serveurs.
  8. Cliquez sur Suivant pour accepter les options par défaut pour les métadonnées des modules. (Note : dans WebSphere Application Server Versions 6.1 et 7, ignorez cette étape)
  9. Cliquez sur Suivant pour accepter les options par défaut pour le mappage des hôtes virtuels pour les modules Web.
  10. Consultez le récapitulatif des options d'installation.
  11. Cliquez sur Terminer.
  12. Cliquez sur Sauvegarder dans la configuration principale.
  13. Naviguez jusqu'à Applications > Types d'application > WebSphere Enterprise Applications. (Note : dans WebSphere Application Server Version 6.1, naviguez jusqu'à Applications > Enterprise Applications)
  14. Sélectionnez IBM WebSphere Application Server - File Uploader sample application, et cliquez sur Démarrer.

Accédez au client démo de l'application installée

Pointez votre navigateur Web vers votre installation de serveur d'application : http://<nom d'hôte de serveur d'application>:<port>/appsvcs-fileuploader/

Le nom d'hôte du serveur d'applications et le numéro du port sont spécifiques à l'installation de votre serveur d'applications. Le port de conteneur Web d'installation par défaut du serveur d'application est 9080. Si vous exécutez votre navigateur Web sur le même poste de travail que votre installation de serveur d'application et avez opté pour toutes les valeurs par défaut, utilisez l'URL suivante : http://localhost:9080/appsvcs-fileuploader/.

Instructions d'installation pour WebSphere Application Server Community Edition Version 2.X

Cette section décrit la procédure d'installation de l'exemple d'application File Uploader dans la Version 2.X d'IBM WebSphere Application Server Community Edition. Vous devez avoir des bonnes connaissances sur l'administration et l'installation de l'application pour le serveur d'application.

Avant de commencer

Localisez le fichier d'archive (EAR) de l'exemple d'application File Uploader qui est fourni avec l'installation de votre produit. Vous le trouverez dans votre arborescence d'installation où vous avez installé IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile. Par exemple, si vous avez installé le module de fonctions à l'emplacement :

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

Vous trouverez alors les fichiers de bibliothèque et EAR à l'emplacement suivant :

Linux et 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

Installation à l'aide de la console administrative

Connectez-vous à la console administrative pour le serveur d'application.

  1. Cliquez sur Applications > Deployer dans le menu de gauche. (Note : dans WebSphere Application Server Community Edition Version 2.0, cliquez sur Applications > Déployer)
  2. Dans la zone Archive, parcourez votre système de fichiers et sélectionnez le fichier appsvcs-fileuploader.ear localisé précédemment. Laissez la zone Plan vide et les options par défaut sélectionnées. Cliquez alors sur Installer.

L'application démarre automatiquement ; l'installation est terminée.

Accédez au client démo de l'application installée

Pointez votre navigateur Web vers votre installation de serveur d'application : http://<nom d'hôte de serveur d'application>:<port>/appsvcs-fileuploader/.

Les port et nom d'hôte du serveur d'application sont spécifiques à votre installation de serveur d'application. Le port de conteneur Web d'installation par défaut de serveur WebSphere Application Server Community Edition est 8080. Si vous exécutez votre navigateur Web sur le même poste de travail que votre installation de serveur d'application et avez opté pour toutes les valeurs par défaut, utilisez l'URL suivante :

http://localhost:8080/appsvcs-fileuploader/