Introdução ao aplicativo de amostra do File Uploader

Esta página é o ponto de início para aprender sobre o aplicativo File Uploader. Os seguintes tópicos serão cobertos:

Visão geral do aplicativo File Uploader

O aplicativo de amostra File Uploader foi criado para complementar o uso dos widgets dojox.form.File Uploader e dojox.form.Uploader do Dojo Toolkit for JavaScript. A amostra do File Uploader demonstra como desenvolver um aplicativo JAX-RS do Representational State Transfer (REST) que pode receber e responder solicitações originadas dos widgets dojox.form.FileUploader e dojox.form.Uploader no Dojo Toolkit para fazer upload.

Os widgets dojox.form.FileUploader e dojox.form.Uploader fazem o upload de arquivos da forma tradicional que um formulário HTML do navegador da Web faria. Ele usa uma mensagem HTTP codificada multipart/form-data. O recurso JAX-RS recebe os dados do formulário enviado já analisado em suas diversas partes. Esse processo simplifica a implementação do código do servidor de forma significativa. A classe de recurso JAX-RS precisa apenas se repetir nas partes e processar os dados adequadamente.

O propósito principal dessa amostra do File Uploader é demonstrar a simplicidade e a capacidade da classe de recurso JAX-RS. Entretanto, para demonstrar completamente essa simplicidade, o widget dojox.form.Uploader é incluído como um componente em um aplicativo Dojo mais amplo. Por exemplo, leia sobre a gravação do aplicativo File Uploader.

Pré-requisitos

Pré-requisito do produto Versão
Java Technology Edition 5.0 e posterior
Servidor de aplicativos Java Platform, Enterprise Edition 5 (Java EE) e posterior

WebSphere Application Server Versão 6.1.0.x e posterior

WebSphere Application Server Community Edition Versão 2.X.

Navegador da Web Qualquer navegador atualizado da Web, como: Internet Explorer 7 e posterior, Mozilla Firefox 3.x e posterior, Google Chrome Safari Opera
IDE de Desenvolvimento (Opcional) Eclipse versão 3.X

Limitações do aplicativo de amostra do File Uploader

O aplicativo de amostra File Uploader não se destina à implementação em servidores de produção. Ele se destina somente a propósitos de desenvolvimento e educacionais.

Todos os códigos de origem do aplicativo, recurso e páginas da Web do JAX-RS são fornecidos no estado em que se encontram para que você use, copie e modifique sem pagamento de royalty, quando desenvolver aplicativos executados com o software WebSphere. É possível usar o código de amostra para seu próprio uso interno ou para redistribuição como parte de um aplicativo ou em seus produtos.

Gravando o aplicativo de amostra do File Uploader

O design do aplicativo de amostra File Uploader demonstra como abordar o desenvolvimento de um aplicativo baseado no AJAX com o Dojo Toolkit em um ambiente Java EE em conformidade com os requisitos dos widgets Dojo dojox.form.FileUploader e dojox.form.Uploader. Para atender esses objetivos, as duas partes de um aplicativo Java EE, o lado do cliente e o lado do servidor, são organizadas em operações simples que executam uma função útil. Isso segue o padrão básico que os aplicativos Java EE usam ao incorporar tecnologias AJAX.

Suposições

Nas seguintes seções, supõe-se que já esteja familiarizado com a estrutura do JavaScript para Dojo, portanto o aplicativo cliente Dojo de amostra ou o widget Dojo dojox.form.Uploader em uso não são explicados detalhadamente.

O cliente

O cliente é a página da Web entregue ao navegador. Na página da Web, o widget dojox.form.Uploader é instanciado e os eventos do navegador são conectados a esse widget. A navegação do sistema de arquivos é acionada pelo Shockwave Flash ou diretamente pela estrutura do JavaScript para Dojo. O widget dojox.form.Uploader usa HTML5, caso o navegador em uso o suporte e degrada sem erros para o Shockwave Flash ou HTML normal, dependendo dos recursos do navegador. Ele permite a seleção simultânea de diversos arquivos e envia os uploads do arquivo por meio de HTML5 ou de um iframe em HTML oculto. Esse uso de um iframe oculto para executar o upload é necessário devido ao tipo de conteúdo multipart/form-data sendo enviado. A resposta então aciona atualizações parciais da página. Esse processo, se tratado pelo navegador com capacidade para HTML5 ou Shockwave Flash, ocorre sem causar um recarregamento integral da página. O widget dojox.form.FileUploader foi descontinuado no Dojo 1.6 e está programado para redução no Dojo 2.0. Ele foi substituído pelo dojox.form.Uploader. O serviço de amostra, entretanto, é capaz de detectar e responder apropriadamente os requisitos impostos por cada um desses dois widgets. Para obter informações mais específicas sobre o design do cliente, leia sobre O aplicativo de amostra File Uploader para o cliente.

O servidor

O servidor fornece a infraestrutura para processar serviços e entregar páginas da Web. Nesse aplicativo, o lado do servidor é uma classe de recurso JAX-RS que recebe e processa consultas POST multipart/form-data a partir dos widgets Dojo dojox.form.FileUploader e dojox.form.Uploader e responde de acordo com os requisitos desses widgets e do aplicativo Dojo incluído. Para o widget dojox.form.FileUploader, a resposta depende do agente do usuário (o navegador ou Shockwave Flash) que inicia a consulta POST. Para o widget dojox.form.Uploader, a resposta depende do campo "name" da "parte"multipart/form-data que contém a carga útil do arquivo. Para a transação iniciada no navegador sem HTML5, o JavaScript Object Notation (JSON) em uma área de texto HTML é retornado. Para a transação iniciada em HTML5, o JSON é retornado. Se o Shockwave Flash iniciou a transação, é retornada uma sequência customizada. O conteúdo do JSON ou da sequência customizada é gerado de acordo com os requisitos do aplicativo que usa os widgets dojox.form.FileUploader e dojox.form.Uploader. Para obter informações mais específicas sobre o design do lado do servidor, leia sobre O aplicativo de amostra do File Uploader para o servidor.

O aplicativo de amostra do File Uploader para o cliente

O aplicativo de amostra do File Uploader usa o widget dojox.form.Uploader para ativar o controle da navegação para o sistema de arquivos local do usuário para seleção de arquivos e fornece o controle para enviar os dados ao clicar no botão de envio do widget. O controle da navegação dojox.form.Uploader é ativado pelo próprio widget usando uma entrada de arquivo de forma padrão ou ativando o aplicativo Shockwave Flash, se o navegador tiver o plug-in do Shockwave Flash instalado. Ao navegar o sistema de arquivos local usando os controles de HTML5 do navegador, o usuário poderá selecionar diversos arquivos simultaneamente. Ao usar o plug-in do Shockwave Flash, o usuário também poderá selecionar diversos arquivos simultaneamente durante a navegação do sistema de arquivos local. Os navegadores sem capacidade para HTML5 permitem apenas a seleção de um arquivo por vez durante a navegação do sistema de arquivos local, mas diversos arquivos poderão ser enfileirados antes de enviá-los para upload.

O aplicativo construído em torno do widget dojox.form.Uploader inclui links para ativar ou desativar o suporte de recursos individuais do widget dojox.form.Uploader. Eles são incluídos como parte do aplicativo para demonstrar a capacidade do widget.

Além disso, o aplicativo recebe dados de resposta do servidor por meio do widget dojox.form.Uploader e, se possível, usa esses dados para exibir os arquivos transferidos por upload recentemente. Ele também mantém uma lista dos arquivos em uma matriz para ativar sua exclusão do servidor quando clicar no botão "Excluir Todos os Arquivos Transferidos por Upload do Servidor". Este botão aciona a função deletePreviousUploads no aplicativo, o que remove os arquivos da lista exibida e usa as consultas Dojo AJAX xhrDelete para solicitar que o servidor exclua os recursos de arquivos transferidos por upload recentemente.

Se já estiver familiarizado com o dojox.form.Uploader, então poderá reconhecer esse aplicativo como sendo semelhante a um dos testes fornecidos com o dojox.form.Uploader no Dojo Toolkit 1.6. Essa amostra do cliente baseia-se muito nesse teste, com uma grande diferença. A maioria dos servidores HTTP não suportam o método DELETE de HTTP, portanto o teste original não incluía tal função. Entretanto, o aplicativo cliente Dojo não suporta o método DELETE.

O propósito principal desse aplicativo de amostra do File Uploader é demonstrar a simplicidade de ter um recurso JAX-RS desenvolvido, que possa receber envios do dojox.form.Uploader, assim o exercício de compreender ainda mais e codificar o cliente é deixado para o leitor.

Para obter mais informações sobre como usar o lado do cliente, consulte o código de origem do aplicativo. Cada seção no documento HTML é comentada, explicando o propósito do bloco de códigos.

O aplicativo de amostra do File Uploader para o servidor

No mínimo, o aplicativo de amostra do File Uploader para o servidor deve ser capaz de receber uma consulta POST com um tipo de conteúdo multipart/form-data. Isso acomodará os requisitos do widget dojox.form.Uploader. O aplicativo de amostra do cliente Dojo que inclui o dojox.form.Uploader é capaz de exibir os arquivos transferidos por upload recentemente. Isso significa que nosso recurso JAX-RS precisará retornar dados ao cliente, que incluam a URL do arquivo recém-transferido por upload, e que pode responder a uma consulta GET para esse arquivo transferido por upload recentemente. Além disso, desejamos que o cliente possa ser capaz de solicitar que o recurso do arquivo transferido por upload recentemente seja excluído. Isso significa que nosso recurso JAX-RS também deverá ter um método que possa receber solicitações DELETE.

O tempo de execução do JAX-RS tem um recurso integrado de análise de carga útil do multipart/form-data e passagem desses dados em uma instância do objeto org.apache.wink.common.model.multipart.BufferedInMultiPart para o método de classes do recurso JAX-RS.

Criando a classe de recurso JAX-RS que receberá as solicitações de 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 {
   // ... }

Observe que essa classe de recurso JAX-RS é declarada como tendo um segmento de URL de "upload". Essa classe de recurso tratará as solicitações previstas em http://<server>:<port>/<context-root>/<uri-mapping>/upload

A raiz de contexto será definida pelo arquivo application.xml, se o arquivo archive Web (.war) for compactado em um arquivo archive corporativo (.ear). Se o .war for instalado por ele mesmo, a raiz de contexto será definida no momento da instalação pelo usuário. O mapeamento de URI é definido no WEB-INF/web.xml, no arquivo .war.

Criando os métodos de recursos JAX-RS

O widget dojox.form.Uploader envia o upload da mesma forma que faz um navegador; como um POST de HTTP com um cabeçalho de Tipo de Conteúdo do multipart/form-data. Essas informações, juntamente com a URL de destino, são usadas pelo tempo de execução do JAX-RS para combinar a mensagem de entrada com o método Java que irá recebê-lo. Portanto, implemente um método na classe de recurso do JAX-RS para aceitá-lo.

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

A anotação @POST declara que esse método receberá solicitações POST de HTTP na URL que termina com "upload". Observe, também, que declaramos o @Consumes. Isso ajuda o tempo de execução JAX-RS a combinar a mensagem de entrada com o método Java. O tempo de execução do JAX-RS tentará combinar o cabeçalho Tipo de Conteúdo da mensagem de entrada com o valor @Consumes.

Criando a classe de aplicativo principal JAX-RS

Nesse ponto, é necessária uma outra classe para completar o aplicativo. O JAX-RS inicializa um aplicativo e seus recursos e provedores por meio da classe que estende o javax.ws.rs.core.Application. Portanto, crie a seguinte classe.

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

Ativando o aplicativo JAX-RS no web.xml

Agora é necessário juntar as partes no arquivo web.xml. Abaixo encontram-se as partes críticas para ativar esse aplicativo 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> ...

Observe o servlet-class e init-param com param-name javax.ws.rs.Application. Essa é a forma padrão para declarar a implementação do servlet e passar a referência da classe que estende o javax.ws.rs.core.Application para o tempo de execução JAX-RS.

Com a inclusão do WEB-INF/web.xml, do aplicativo compilado e dos arquivos de biblioteca apropriados no diretório WEB-INF/lib/ do arquivo .war, o aplicativo pode ser instalado em um servidor de aplicativos. Consulte o conteúdo da amostra incluída, se desejar ver a lista de bibliotecas necessárias. O aplicativo de amostra incluído está no formato de um arquivo .war compactado em um arquivo .ear. No arquivo .ear está o arquivo application.xml padrão, que especifica a raiz de contexto da URL do "/appsvcs-fileuploader". Assim, a URL para o arquivo index.html é http://<server>:<port>/appsvcs-fileuploader/. Observe que a URL especificada no index.html no aplicativo de amostra é "rest/upload", que é relativo ao local do arquivo index.html e é o resultado da concatenação do padrão da url no web.xml e na anotação @Path na classe de recurso JAX-RS.

Para obter mais detalhes sobre a implementação do método que recebe e processa a carga útil da mensagem multipart/form-data, visualize o código de origem ou continue a leitura.

Implementação do Método de Upload

O método de upload recebe um objeto BufferedInMultiPart, que é a carga útil da mensagem multipart/form-data já analisada. A ação é executada em cada parte.

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

Outras partes do envio do formulário BufferedInMultiPart podem estar em campos de entrada ou caixas de seleção de tipo de texto HTML regular. O processamento dessas partes foi omitido nesta amostra.

Recebemos e processamos com êxito as partes do arquivo enviadas do widget Dojo dojox.form.Uploader.

Suporte adicional

O aplicativo JAX-RS que construiu até agora é suficiente para receber e processar a carga útil da mensagem multipart/form-data enviada pelo dojox.form.Uploader. Agora, você deverá compreender a resposta solicitada pelo dojox.form.Uploader ou as características dessa resposta, necessárias pelo aplicativo cliente anexado maior. A documentação do dojox.form.Uploader indica que a resposta deve ter um cabeçalho de Tipo de Conteúdo de "text/html". Em uma classe de recurso de JAX-RS, isso é trivial para ser declarado. É necessário declarar somente o tipo de conteúdo em uma anotação @Produces do nível de método. O tempo de execução do JAX-RS designará o cabeçalho HTTP apropriado, como por exemplo:

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

Além disso, a documentação do dojox.form.Uploader indica que ele requer que a resposta seja uma matriz JSON agrupada em uma tag <textarea> ao responder ao agente do usuário do navegador de um navegador sem HTML5. Agora, presuma que o agente do usuário padrão seja um navegador sem HTML5, não um navegador com HTML5 e não um Shockwave Flash. Ao construir na implementação anterior acima e agora importar o com.ibm.json.java.JSONArray e o com.ibm.json.java.JSONObject, é possível fornecer a matriz JSON retornada com o conteúdo solicitado pelo aplicativo cliente do Dojo de amostra.

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

A documentação do widget dojox.form.FileUploader indica que o cabeçalho Usuário-Agente determina o formato da resposta. A documentação do widget dojox.form.Uploader indica que o serviço que recebe os uploads deve usar o "nome" das "partes" multipart/form-data para determinar o emissor dos dados e responder adequadamente. O seguinte exemplo inclui o nome e as partes.

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

Observe que o método de upload agora recebe um parâmetro adicional: @Context UriInfo uriInfo. A anotação @Context instrui o tempo de execução do JAX-RS a introduzir uma instância do tipo declarado nos parâmetros de chamada do método de upload. O ciclo de vida dessa instância introduzida ocorre por solicitação de HTTP. Essa instância UriInfo introduzida deve ser detectada na URL que foi usada para chamar o método de upload. Assim que tiver essas informações, será possível usá-las para retornar a URL do recurso dos arquivos recém-transferidos por upload, para que o aplicativo cliente do Dojo possa chamar uma solicitação GET de HTTP que transferiu por upload o recurso do arquivo. Isso mantém as boas práticas das interfaces REST.

Agora o Widget dojox.form.Uploader receberá a resposta necessária e passará os dados formatados como um objeto JavaScript de volta para o aplicativo cliente Dojo, que irá usá-lo para solicitar o recurso do arquivo transferido por upload recentemente.

Os métodos do utilitário chamados pela implementação do método de upload, tal como parseContentDispositionHeader, readInputStream e getFileURL não estão descritos aqui, mas podem ser inspecionados no código de origem de amostra incluído.

Usando a solicitação GET para buscar o arquivo transferido por upload

O aplicativo cliente Dojo pretende exibir o arquivo recém-transferido por upload imediatamente, ao receber a resposta da solicitação POST. A resposta da solicitação POST inclui uma URI nos arquivos transferidos por upload, que será usada no atributo "src" de uma tag <img> gerada. Portanto, a classe de recurso JAX-RS deve executar uma das seguintes ações:

O seguinte exemplo demonstra a segunda ação, na qual o método Java é incluído na classe de recurso 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); }

Há diversos itens a serem observados nesse método Java. Primeiro, a sequência declarada na anotação @Path é declarada com colchetes, para que seja passada como um parâmetro para o método getImage. Isso significa que a URL solicitada para esse método Java que suporta o método de HTTP GET é http://<server>:<port>/fileuploader/rest/upload/uploadedfile.jpg. O objeto retornado desse método getImage é um objeto JAX-RS Response. Isso lhe oferece mais controle sobre as características da resposta do que é possível com o uso de anotações de JAX-RS. Declare o Tipo de Conteúdo da resposta e passe o FileInputStream bruto de volta ao tempo de execução JAX-RS. Para o navegador, o recurso do arquivo transferido por upload recentemente está disponível na URL especificada na resposta da consulta POST. Embora o arquivo Java real possa estar em qualquer local do servidor.

Observe o uso da variável rootPath. Esse valor da variável é definido por um parâmetro de configuração declarado em um init-param do arquivo web.xml e pode ser recuperado de um objeto de instância ServletConfig introduzido pelo @Context. Consulte o código de origem de amostra desse recurso.

Excluindo recursos do arquivo

Neste ponto, a classe de recurso JAX-RS suporta as solicitações POST e GET para acomodar as solicitações do widget dojox.form.Uploader e do aplicativo cliente Dojo incluído. Como isso é uma interface REST, você também poderá desejar suportar que o método DELETE trate a exclusão dos recursos do arquivo transferido por upload. Inclua o seguinte método Java na classe de recurso 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(); }

Observe que esse método é muito semelhante ao GET. Ele recebe o nome do arquivo como um objeto de parâmetro do método PathParam e tenta excluir o recurso do arquivo. Observe o uso da anotação @DELETE. O suporte ao DELETE é construído em todos os contêineres de Web do servidor de aplicativos. O aplicativo cliente Dojo agora pode usar o método xhrDelete para enviar solicitações de HTTP DELETE para essa classe de recurso JAX-RS.

Boas práticas da interface REST

As boas práticas de REST indicam que quando um novo recurso é criado por meio de um POST, a resposta do POST deve incluir um cabeçalho de HTTP de Local com uma URI nesse novo recurso. Entretanto, o aplicativo File Uploader não é mais um recurso REST "puro", visto que poderá receber diversos arquivos em uma mensagem POST, criando, assim, diversos novos recursos de arquivo. Portanto, a amostra não retorna um cabeçalho HTTP de Local.

Visualizando o código de origem do aplicativo de amostra do File Uploader

O código de origem do aplicativo de amostra do File Uploader é fornecido no arquivo do módulo da Web FileUploader.war, no arquivo FileUploader.ear. Há duas abordagens para visualizar o código de origem: por meio do Ambiente de Desenvolvimento Integrado (IDE) baseado no Eclipse ou ao descompactar o arquivo appsvcs-directorylisting.ear e, então, descompactar o arquivo .war contido nele.

Localizando o arquivo EAR

A primeira etapa de visualizar o código de origem é localizar o arquivo FileUploader.ear. Se você instalou o IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile, então é possível localizar o arquivo EAR na árvore de instalação.

Por exemplo, se instalou o feature pack no seguinte local:

Plataforma Location
Linux e UNIX: /opt/WebSphere/AppServer
Ponto de montagem do z/OS: <install_root>
Windows: c:\WebSphere\AppServer

Em seguida, será possível localizar o arquivo EAR em:

Plataforma Location
Linux e 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

Visualizando o Código de origem em um IDE Baseado no Eclipse

Usar um IDE baseado no Eclipse é a abordagem mais simples para examinar o código de origem do arquivo WAR. Usar qualquer IDE do Eclipse 3.2.X, 3.3.X com o Web Tools Project 2.5 ou superior ou o Rational Application Developer, Versão 7.0 ou superior, pode importar o archive Web (WAR) ao concluir as seguintes etapas:

  1. Expanda o arquivo appsvcs-fileuploader.ear.
  2. No menu de IDE do Eclipse, abra o menu Arquivo e selecione Importar.
  3. No painel apresentado, expanda a opção Web. Em seguida, selecione o arquivo WAR e clique em Avançar.
  4. No campo de entrada Arquivo WAR, clique em Navegar e selecione o arquivo localizado anteriormente.
  5. Aceite as opções padrão, se forem aceitáveis, e clique em Concluir.

Quando o processo de importação estiver concluído, um novo projeto, FileUploader, existirá na área de trabalho do Eclipse. O código de origem do aplicativo pode ser acessado a partir do projeto FileUploader. Para acessar o código do cliente ou do servidor, consulte a seguinte tabela dos locais do código de origem na árvore do projeto do Eclipse FileUploader.

Código de Origem Location
Lado do cliente (Navegador da Web) WebContent/index.html: Contém as definições do Widget Dojo e as funções do script do cliente. Esse arquivo carrega um perfil Dojo não otimizado.
Lado do servidor Recursos: src/com.ibm.websphere.mobile.appsvcs.sample.fileuploader/ FileUploaderApplication.java: Clique duas vezes nesse arquivo para carregar o código de origem.
Recursos Java: src/com.ibm.websphere.mobile.appsvcs.sample.fileuploader. resources/MultiFileUploadDataService.java: Clique duas vezes nesse arquivo para carregar o código de origem.

Visualizando o código de origem ao extrair o arquivo archive do aplicativo da Web

Os arquivos do aplicativo da Web são archives do arquivo compactados usando o algoritmo ZIP. Portanto, o arquivo archive pode ser expandido por meio de qualquer ferramenta ZIP para compactar arquivos, incluindo o programa Java archive (JAR). Nas seguintes etapas, supõe-se que o usuário escolha a ferramenta favorita para criar arquivos compactados.

  1. Expanda o arquivo FileUploader.ear localizado anteriormente em um diretório no sistema usando a ferramenta favorita para compactar arquivos. Nas seguintes etapas, supõe-se que EXPAND_DIR/FileUploader seja o local correto.
  2. Liste os arquivos no diretório EXPAND_DIR/FileUploader no qual o arquivo FileUploader.ear foi expandido.

Depois de ter expandido o conteúdo do arquivo EAR, você deverá expandir o conteúdo do arquivo .war. Em seguida, será possível acessar o código de origem. Para acessar o código do cliente ou do servidor, consulte a seguinte tabela dos locais do código de origem no diretório EXPAND_DIR/FileUploader.

Código de Origem Location
Lado do cliente (Navegador da Web) index.html: Contém as definições do widget Dojo e as funções do script do cliente.
Lado do servidor 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

Instalando o aplicativo de amostra do File Uploader

Consulte as seguintes instruções de instalação específica da versão:

Instruções de instalação do WebSphere Application

Esta seção descreve o procedimento para instalar o aplicativo de amostra do File Uploader na Versão 6.1.0.X e posterior do IBM WebSphere Application Server. Presume-se que esteja familiarizado com a instalação e administração do aplicativo do servidor de aplicativos.

Antes de Começar

Localize o arquivo archive corporativo (EAR) do aplicativo de amostra do File Uploader fornecido com a instalação do produto. É possível localizar o arquivo EAR na árvore de instalação na qual o IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile foi instalado. Por exemplo, se instalou o feature pack no seguinte local:

Plataforma Location
Linux e UNIX: /opt/WebSphere/AppServer
Ponto de montagem do z/OS: <install_root>
Windows: c:\WebSphere\AppServer

Em seguida, será possível localizar o arquivo EAR em:

Plataforma Location
Linux e 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

Instalando o aplicativo de amostra do File Uploader usando o console administrativo

  1. Efetue login no console administrativo do servidor de aplicativos.
  2. Navegue até Aplicativos > Novo Aplicativo. (Nota: No WebSphere Application Server Versão 6.1, selecione Instalar Novo Aplicativo)
  3. Selecione Novo Aplicativo Corporativo. (Nota: No WebSphere Application Server Versão 6.1, ignore esta etapa)
  4. Navegue no sistema de arquivos e selecione o arquivo appsvcs-graphics.ear localizado anteriormente. Clique em Avançar.
  5. Clique em Avançar para se preparar para a instalação do aplicativo. (Nota: No WebSphere Application Server Versão 6.1, ignore esta etapa)
  6. Clique em Avançar para aceitar as opções de instalação padrão.
  7. Clique em Avançar para aceitar as opções padrão para módulos de mapa para servidores.
  8. Clique em Avançar para aceitar as opções padrão para Metadados para módulos. (Nota: No WebSphere Application Server Versões 6.1 e 7, ignore esta etapa)
  9. Clique em Avançar para aceitar as opções padrão para hosts virtuais de mapa para módulos da Web.
  10. Revise o resumo das opções de instalação.
  11. Clique em Concluir.
  12. Clique em Salvar na configuração principal.
  13. Navegue até Aplicativos > Tipos de Aplicativos > Aplicativos Corporativos do WebSphere. (Nota: No WebSphere Application Server Versão 6.1, navegue até Aplicativos > Aplicativos Corporativos)
  14. Selecione o IBM WebSphere Application Server - aplicativo de amostra do File Uploader e clique em Iniciar.

Acessar o cliente demo do aplicativo instalado

Aponte o navegador da Web para a instalação de servidor de aplicativos: http://<application server hostname>:<port>/appsvcs-fileuploader/

O nome do host e o número da porta do servidor de aplicativos são específicos da instalação de servidor de aplicativos. Uma porta do contêiner da Web da instalação padrão do servidor de aplicativos é 9080. Se estiver executando o navegador da Web na mesma estação de trabalho como a instalação de servidor de aplicativos e tiver aceito todos os valores padrão, então use a seguinte URL: http://localhost:9080/appsvcs-fileuploader/.

Instruções de instalação do WebSphere Application Server Community Edition Versão 2.X

Esta seção descreve o procedimento para instalar o aplicativo de amostra do File Uploader na Versão 2.X do IBM WebSphere Application Server Community Edition. Presume-se que esteja familiarizado com a instalação e administração do aplicativo do servidor de aplicativos.

Antes de Começar

Localize o arquivo archive corporativo (EAR) do aplicativo de amostra do File Uploader fornecido com a instalação do produto. É possível localizar o arquivo EAR na árvore de instalação na qual o IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile foi instalado. Por exemplo, se instalou o feature pack no seguinte local:

Plataforma Location
Linux e UNIX: /opt/WebSphere/AppServerCommunityEdition
Windows: c:\WebSphere\AppServerCommunityEdition

Em seguida, será possível localizar o arquivo EAR e os arquivos de biblioteca em:

Plataforma Location
Linux e 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

Instalação por meio do console administrativo

Efetue login no console administrativo do servidor de aplicativos.

  1. Clique em Aplicativos > Implementador no menu da esquerda. (Nota: No WebSphere Application Server Community Edition Versão 2.0, clique em Aplicativos> Implementar Novo)
  2. No campo Archive, navegue no sistema de arquivos e selecione o arquivo appsvcs-fileuploader.ear localizado anteriormente. Mantenha Plano em branco e as opções padrão selecionadas. Em seguida, clique em Instalar.

O aplicativo será iniciado automaticamente e a instalação concluída.

Acessar o cliente demo do aplicativo instalado

Aponte o navegador da Web para a instalação de servidor de aplicativos: http://<application server hostname>:<port>/appsvcs-fileuploader/.

O nome e a porta do host do servidor de aplicativos são específicos da instalação de servidor de aplicativos. Uma porta do contêiner da Web da instalação padrão do servidor do WebSphere Application Server Community Edition é 8080. Se estiver executando o navegador na mesma estação de trabalho da instalação de servidor de aplicativos e tiver aceito todos os valores padrão, então use a seguinte URL:

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