Esta página es el punto de partida para obtener información sobre la aplicación File Uploader. Se tratan los siguientes temas:
La aplicación de ejemplo de File Uploader se ha creado para complementar el uso del cargador dojox.form.File y de los widgets dojox.form.Uploader de Dojo Toolkit for JavaScript. El ejemplo de File Uploader muestra cómo desarrollar una aplicación JAX-RS REST (Representational State Transfer) que pueda recibir y responder a las cargas que se originan en los widgets dojox.form.FileUploader y dojox.form.Uploader en Dojo Toolkit.
Los widgets dojox.form.FileUploader y dojox.form.Uploader cargan archivos de la manera tradicional en la que lo haría un formulario HTML de navegador web. Utiliza un mensaje HTTP codificado multipart/form-data. El recurso JAX-RS recibe los datos del formulario enviado ya analizado en sus múltiples partes. Este proceso simplifica considerablemente la implementación del código del servidor. La clase de recurso JAX-RS sólo tiene que iterar entre las partes y procesar los datos de la forma correspondiente.
El principal objetivo de este ejemplo de File Uploader es mostrar la simplicidad y la capacidad de la clase de recurso JAX-RS. Sin embargo, para mostrar plenamente esta simplicidad, se incluye el widget dojox.form.Uploader como un componente de una aplicación Dojo mayor. Lea acerca de cómo escribir la aplicación File Uploader para ver un ejemplo.
Requisitos previos del producto | Versión |
---|---|
Java Technology Edition | 5.0 y posteriores |
Servidor de aplicaciones Java Platform, Enterprise Edition 5 (Java EE) y posteriores | WebSphere Application Server Versión 6.1.0.x y posteriores WebSphere Application Server Community Edition Versión 2.X. |
Navegador web | Cualquier navegador web actual, como: Internet Explorer 7 y posteriores, Mozilla Firefox 3.x y posteriores, Google Chrome, Safari, Opera |
Entorno de desarrollo integrado (opcional) | Eclipse versión 3.X |
La aplicación de ejemplo de File Uploader no está pensada para el despliegue de servidores de producción. Es sólo para fines de desarrollo y formativos.
Todo el código fuente para la aplicación JAX-RS, recurso y páginas web se proporciona tal cual para que se utilice, copie y modifique sin pago de derechos al desarrollar aplicaciones que se ejecuten con software WebSphere. Puede utilizar el código de ejemplo para su propio uso personal o para su redistribución como parte de una aplicación, o en sus productos.
El diseño de la aplicación de ejemplo de File Uploader muestra cómo enfocar el desarrollo de una aplicación basada en AJAX con Dojo Toolkit en un entorno de Java EE que cumpla los requisitos de los widgets Dojo dojox.form.FileUploader y dojox.form.Uploader. Para cumplir estos objetivos, las dos partes de una aplicación Java EE, el lado del cliente y el lado del servidor, se organizan en operaciones simples que realizan una función útil. Sigue el patrón básico que utilizan las aplicaciones Java EE cuando incorporan tecnologías AJAX.
Los apartados siguientes presuponen que ya está familiarizado con la infraestructura de JavaScript para Dojo y no explican en detalle la aplicación cliente Dojo de ejemplo ni el widget Dojo dojox.form.Uploader que se utiliza.
El cliente es la página web que se entrega al navegador. En la página web, se crea una instancia del widget dojox.form.Uploader y los sucesos del navegador se envían a este widget. La exploración del sistema de archivos la dirige Shockwave Flash o directamente la infraestructura JavaScript para Dojo. El widget dojox.form.Uploader utiliza HTML5 si el navegador en uso lo admite, y degrada correctamente a Shockwave Flash o HTML normal según las prestaciones del navegador. Permite la selección simultánea de varios archivos y envía las cargas de archivos mediante HTML5 o un iframe HTML oculto. Este uso de un iframe oculto para realizar la carga es necesario debido al tipo de contenido multipart/form-data que se está enviando. A continuación, la respuesta controla actualizaciones de página parciales. Este proceso, si lo maneja un navegador con capacidad para HTML5 o Shockwave Flash, se produce sin que se tenga que volver a cargar la página completa. El widget dojox.form.FileUploader está en desuso en Dojo 1.6 y está planificada su eliminación en Dojo 2.0. Ha sido sustituido por dojox.form.Uploader. Sin embargo, el servicio de ejemplo puede detectar los requisitos que imponen cada uno de estos dos widgets y responder correctamente a ellos. Para obtener información más específica sobre el diseño del cliente, lea sobre La aplicación de ejemplo de File Uploader para el cliente.
El servidor proporciona la infraestructura para procesar servicios y proporcionar páginas web. En esta aplicación, el lado del servidor es una clase de recurso JAX-RS que recibe y procesa consultas POST multipart/form-data de los widgets Dojo dojox.form.FileUploader y dojox.form.Uploader y responde según los requisitos de estos widgets y la aplicación Dojo contenedora. Para el widget dojox.form.FileUploader, la respuesta depende del agente de usuario (el navegador o Shockwave Flash) que inicia la consulta POST. Para el widget dojox.form.Uploader, la respuesta depende del campo "name" de la "parte" multipart/form-data que contiene la carga útil del archivo. Para transacciones iniciadas en navegadores sin capacidad para HTML5, se devuelve JavaScript Object Notation (JSON) en un código HTML textarea. Para una transacción iniciada en HTML5, se devuelve JSON. Si Shockwave Flash ha iniciado la transacción, se devuelve una serie personalizada. El contenido de la serie JSON o personalizada se genera según los requisitos de la aplicación que utiliza los widgets dojox.form.FileUploader y dojox.form.Uploader. Para obtener información más específica sobre el diseño del lado del servidor, lea sobre La aplicación de ejemplo de File Uploader para el servidor.
La aplicación de ejemplo de File Uploader utiliza el widget dojox.form.Uploader para habilitar el control de la exploración al sistema de archivos local del usuario para la selección de archivos, y proporciona el control para enviar los datos al pulsar el botón de envío del widget. El control de exploración de dojox.form.Uploader lo habilita el propio widget mediante entrada de archivo de formulario estándar o habilitando la aplicación Shockwave Flash, si el navegador tiene instalado el plugin Shockwave Flash. Al examinar el sistema de archivos local mediante los controles HTML5 del navegador, el usuario puede seleccionar varios archivos simultáneamente. Cuando se utiliza el plugin Shockwave Flash, el usuario puede seleccionar también varios archivos simultáneamente durante la exploración del sistema de archivos local. Los navegadores que no admiten HTML5 sólo permiten la selección de un único archivo cada vez durante la exploración del sistema de archivos local, pero es posible poner en cola varios archivos antes de enviarlos para su carga.
La aplicación creada alrededor del widget dojox.form.Uploader incluye enlaces para habilitar o inhabilitar el soporte de las características individuales del widget dojox.form.Uploader. Se incluyen como parte de la aplicación para mostrar la prestación del widget.
Además, la aplicación recibe los datos de respuesta del servidor mediante el widget dojox.form.Uploader, y lo utiliza para visualizar los archivos cargados recientemente, si es posible. También mantiene una lista de los archivos para permitir su supresión desde el servidor cuando se pulsa el botón "Suprimir todos los archivos cargados del servidor". Este botón desencadena la función deletePreviousUploads en la aplicación, lo que elimina los archivos de la lista visualizada y utiliza las consultas Dojo AJAX xhrDelete para solicitar que el servidor suprima los recursos de archivos cargados recientemente.
Si ya está familiarizado con dojox.form.Uploader, es posible que reconozca esta aplicación como similar a una de las pruebas proporcionadas con dojox.form.Uploader en Dojo Toolkit 1.6. Este ejemplo de cliente se basa en gran parte en dicha prueba, con una diferencia importante. La mayoría de los servidores HTTP no dan soporte al método HTTP DELETE, por lo que la prueba original no incluía una función de este tipo. Sin embargo, la aplicación cliente Dojo da soporte al método DELETE.
El objetivo principal de esta aplicación de ejemplo de File Uploader es mostrar la simplicidad de la obtención de un recurso JAX-RS desarrollado que puede recibir envíos de dojox.form.Uploader, de modo que el ejercicio de mayor comprensión y codificación del cliente se deja al lector.
Para obtener más información sobre cómo utilizar el lado del cliente, consulte el código fuente de la aplicación. Cada sección del documento HTML incluye comentarios que explican la finalidad del bloque de código.
Como mínimo, la aplicación de ejemplo de File Uploader para el servidor debe poder recibir una consulta POST con un tipo de contenido multipart/form-data. Esto cumplirá los requisitos del widget dojox.form.Uploader. Esta aplicación de ejemplo de cliente Dojo que incluye el dojox.form.Uploader puede visualizar los archivos cargados recientemente. Esto significa que nuestros recursos JAX-RS deberán devolver datos al cliente que incluyan el URL del archivo que se acaba de subir y puedan responder a una consulta GET para ese archivo cargado recientemente. Además, queremos que el cliente pueda solicitar la supresión del recurso de archivo cargado recientemente. Esto significa que nuestros recursos JAX-RS también deben tener un método que pueda recibir solicitudes DELETE.
La ejecución de JAX-RS puede analizar la carga útil de multipart/form-data y pasar dichos datos en una instancia de objeto org.apache.wink.common.model.multipart.BufferedInMultiPart al método de la clase de recurso JAX-RS.
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 { // ... }
Tenga en cuenta esta clase de recurso JAX-RS se declara para tener un segmento de URL de "upload". Esta clase de recurso manejará solicitudes dirigidas a http://<servidor>:<puerto>/<raíz-contexto>/<correlación-uri>/upload
La raíz de contexto se define mediante el archivo application.xml si el archivo de archivador web (.war) está empaquetado en un archivo de archivador empresarial (.ear). Si el .war se instala por sí mismo, la raíz de contexto la define durante la instalación el usuario. La correlación de URI se define en WEB-INF/web.xml en el archivo .war.
El widget dojox.form.Uploader envía la carga de la misma forma que lo haría un navegador; como un HTTP POST con una cabecera Content-Type de multipart/form-data. Esta información, junto con el URL de destino, la utiliza la ejecución de JAX-RS para correlacionar el mensaje de entrada con el método Java que lo recibirá. Por lo tanto, implemente un método en la clase de recurso JAX-RS para aceptarlo.
@POST @Consumes(MediaType.MULTIPART_FORM_DATA) public String upload(BufferedInMultiPart bimp) { // ... }
La anotación @POST declara que este método recibirá solicitudes HTTP POST en el URL que termina en "upload". Tenga en cuenta también que hemos declarado @Consumes. Esto ayuda al tiempo de ejecución de JAX-RS a correlacionar el mensaje de entrada con el método Java. La ejecución de JAX-RS intentará correlacionar la cabecera Content-Type del mensaje de entrada con el valor @Consumes.
En este punto, se requiere una clase adicional para completar la aplicación. JAX-RS inicializa una aplicación y sus recursos y proveedores mediante la clase que amplía javax.ws.rs.core.Application. Por lo tanto, cree la clase siguiente.
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; } }
Ahora debemos ensamblar todas las piezas en el archivo web.xml. A continuación se muestran algunas partes críticas para habilitar esta aplicación 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> ...
Tenga en cuenta servlet-class e init-param con param-name javax.ws.rs.Application. Esta es la forma estándar de declarar la implementación de servlet y pasar la referencia de la clase que amplía javax.ws.rs.core.Application al tiempo de ejecución de JAX-RS.
Con la inclusión de WEB-INF/web.xml, la aplicación compilada y los archivos de biblioteca adecuados en el directorio WEB-INF/lib/ del archivo .war, la aplicación se puede instalar en un servidor de aplicaciones. Consulte el contenido del ejemplo incluido si desea ver la lista de bibliotecas necesarias. La aplicación de ejemplo incluida tiene el formato de un archivo .war empaquetado en un archivo .ear. En el archivo .ear se encuentra el archivo application.xml estándar, que especifica la raíz de contexto del URL de "/appsvcs-fileuploader". De este modo, el URL del archivo index.html es http://<servidor>:<puerto>/appsvcs-fileuploader/. Tenga en cuenta que el URL especificado en el archivo index.html en la aplicación de ejemplo es "rest/upload", que es relativo a la ubicación del archivo index.html, y es el resultado de la concatenación del url-pattern del archivo web.xml y la anotación @Path de la clase de recurso JAX-RS.
Para obtener más detalles sobre la implementación del método de recibir y procesar la carga útil del mensaje multipart/form-data, visualice el código fuente, o continúe leyendo.
El método de carga recibe un objeto BufferedInMultiPart, que es la carga útil del mensaje multipart/form-data ya analizado. Se realiza una acción en 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"); // Sólo existe una cabecera Content-Disposition por parte. // Por lo tanto, es seguro utilizar list.get(0): Map<String, String> cdHeaderMap = parseContentDispositionHeader(list.get(0)); String filename = cdHeaderMap.get("filename"); if (filename != null) { // Esta parte es un archivo. byte[] bytes = readInputStream(parts.get(i).getInputStream()); // Haga algo con los bytes; grábelos en el sistema de archivos // o páselos a un manejador de archivos. // ... } } } // ... }
Otras partes del envío de formulario BufferedInMultiPart pueden ser recuadros de selección o campos de entrada de tipo de texto HTML normales. En este ejemplo se omite el proceso de estas partes.
Hemos recibido y procesado correctamente las partes del archivo enviado desde el widget Dojo dojox.form.Uploader.
La aplicación JAX-RS que ha creado hasta ahora es suficiente para recibir y procesar la carga útil del mensaje multipart/form-data enviado por el dojox.form.Uploader. Ahora debe comprender la respuesta que requiere el dojox.form.Uploader o los detalles de esa respuesta que requiere la aplicación cliente mayor contenedora. La documentación del dojox.form.Uploader indica que la respuesta debe tener una cabecera Content-Type de "text/html". En una clase de recurso JAX-RS, es trivial esta declaración. Sólo necesita declarar el tipo de contenido en una anotación @Produces de nivel de método. El tiempo de ejecución de JAX-RS asignará la cabecera HTTP adecuada; por ejemplo:
@POST @Consumes(MediaType.MULTIPART_FORM_DATA) @Produces(MediaType.TEXT_HTML) public String upload(BufferedInMultiPart bimp) { // ... }
Además, la documentación de dojox.form.Uploader indica que requiere que la respuesta sea una matriz JSON contenida en un código <textarea> al responder al agente de usuario del navegador desde un navegador que no permite HTML5. Por ahora, supongamos que el agente de usuario predeterminado es un navegador que no permite HTML5, no un navegador que permita HTML5 ni Shockwave Flash. Creando en la implementación anterior y ahora importando com.ibm.json.java.JSONArray y com.ibm.json.java.JSONObject, puede proporcionar la matriz JSON devuelta con el contenido que requiere la aplicación cliente Dojo de ejemplo.
@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"); // Sólo existe una cabecera Content-Disposition por parte. // Por lo tanto, es seguro utilizar list.get(0): Map<String, String> cdHeaderMap = parseContentDispositionHeader(list.get(0)); String filename = cdHeaderMap.get("filename"); if (filename != null) { // Esta parte es un archivo. byte[] bytes = readInputStream(parts.get(i).getInputStream()); // Haga algo con los bytes; grábelos en el sistema de archivos // o páselos a un manejador de archivos. // ... // Crear el objeto de retorno según requiera nuestro cliente Dojo de ejemplo. JSONObject jsonObject = new JSONObject(); jsonObject.put("uri", getFileURL(uriInfo, filename)); jsonObject.put("name", filename); jsonArray.add(jsonObject); } } } // Ejemplo de lo que se devuelve: // <textarea>[{"uri":"/fileuploader/rest/upload/uploadedfile.jpg", // "name":"uploadedfile.jpg"}] // </textarea> return "<textarea>" + jsonArray.toString() + "</textarea>"; }
La documentación del widget dojox.form.FileUploader indica que la cabecera User-Agent determina el formato de la respuesta. La documentación del widget dojox.form.Uploader indica que el servicio que recibe las cargas debe utilizar el "name" de las "partes" multipart/form-data para determinar el remitente de los datos, y responder en consecuencia. El ejemplo siguiente incluye nombre y partes.
// Distintos clientes de carga requieren diferentes respuestas. // Se debe manejar tanto dojox.form.FileUploader como dojox.form.Uploader. 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 { // Supongamos formato HTML normal 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"); // Sólo existe una cabecera Content-Disposition por parte. // Por lo tanto, es seguro utilizar list.get(0): Map<String, String> cdHeaderMap = parseContentDispositionHeader(list.get(0)); String name = cdHeaderMap.get("name"); // Determine el tipo de cliente. Consulte la documentación de 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) { // esta Parte es un archivo byte[] bytes = readInputStream(parts.get(i).getInputStream()); // Haga algo con los bytes; grábelos en el sistema de archivos, // o páselos a un manejador de archivos. // ... // Cree la serie de retorno según requiera nuestro cliente Dojo de ejemplo. 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); // Sólo existe una cabecera User-Agent, así que es seguro utilizar get(0). String userAgent = userAgentHeaders == null ? null : userAgentHeaders.get(0); // Si se ha utilizado el cliente Flash, requiere una carga útil de formato // de respuesta específica, no 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) + ","; } } // Eliminar coma final. flashString = flashString.substring(0, flashString.length() - 1); return flashString; } else if (uploadType == UPLOAD_TYPE.HTML5) { return jsonArray.toString(); } String result = "<textarea>" + jsonArray.toString() + "</textarea>"; // El iframe temporal utilizado para enviar la consulta AJAX requiere que los datos devueltos // estén contenidos en el área de texto. Esto lo requieren dojox.form.FileUploader y // dojox.form.Uploader para navegadores que no admiten HTML5. // Consulte la documentación de dojox.form.Uploader para obtener más información. return result; }
Tenga en cuenta que el método de carga ahora contiene un parámetro adicional: @Context UriInfo uriInfo. La anotación @Context indica a la ejecución de JAX-RS que inyecte una instancia del tipo declarado en los parámetros de invocación del método de carga. El ciclo de vida de esta instancia inyectada es por solicitud HTTP. Esta instancia de UriInfo inyectada debe detectar el URL que se ha utilizado para invocar el método de carga. Cuando tenga esta información, podrá utilizarla para devolver el URL del recurso de los archivos que se acaban de cargar, de modo que la aplicación cliente Dojo pueda llamar a la solicitud HTTP GET que ha cargado el recurso de archivo. Esto está en consonancia con los métodos recomendados de las interfaces REST.
Ahora el widget dojox.form.Uploader recibirá la respuesta necesaria y pasará los datos formateados como un objeto JavaScript de nuevo a la aplicación cliente Dojo, que los utilizará para solicitar el recurso de archivo recientemente cargado.
Los métodos de programa de utilidad llamados desde nuestra implementación de método de carga, como parseContentDispositionHeader, readInputStream y getFileURL, no se describen aquí, pero pueden consultarse en el código fuente de ejemplo incluido.
La aplicación cliente Dojo planea visualizar el archivo que se acaba de cargar inmediatamente al recibir la respuesta de la solicitud POST. La respuesta de la solicitud POST incluye un URI a los archivos cargados, que se utilizarán en el atributo "src" de un código <img> generado. Por lo tanto, nuestra clase de recurso JAX-RS debe realizar una de las dos acciones siguientes:
- Guardar el archivo cargado en un sitio accesible mediante la web y devolver el URL estático al archivo.
- Guardar el archivo cargado en un sitio conocido y devolver un URL al método Java que puede procesar una consulta HTTP GET.
El ejemplo siguiente muestra la segunda acción, en la que el método Java se añade a la clase 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('.')); // Este valor predeterminado es estándar para navegadores 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(); } // El recurso solicitado no existe. Se devuelve un error 404. throw new WebApplicationException(Response.Status.NOT_FOUND); }
Existen varios aspectos que se deben considerar acerca de este método Java. En primer lugar, la serie declarada en la anotación @Path se declara con llaves de modo que se pasa como un parámetro al método getImage. Esto significa que el URL de solicitud para este método Java que da soporte al método GET HTTP es http://<servidor>:<puerto>/fileuploader/rest/upload/uploadedfile.jpg. El objeto devuelto por este método getImage es un objeto de respuesta JAX-RS. Esto le proporciona más control sobre los detalles de la respuesta de lo que es posible con la utilización de anotaciones JAX-RS. Declare el Content-Type de la respuesta y pase el FileInputStream bruto al tiempo de ejecución de JAX-RS. En el navegador el recurso de archivo cargado recientemente está disponible en el URL especificado en la respuesta de la consulta POST. Aunque el archivo Java real puede estar en cualquier lugar del servidor.
Tenga en cuenta el uso de la variable rootPath. Este valor de variable lo define un parámetro de configuración declarado en un init-param del archivo web.xml y se puede recuperar desde un objeto de instancia de ServletConfig inyectado @Context. Consulte el código fuente de ejemplo de esta característica.
En este punto, nuestra clase de recurso JAX-RS da soporte a solicitudes POST y GET para satisfacer los requisitos del widget dojox.form.Uploader y la aplicación cliente Dojo contenedora. Dado que se trata de una interfaz REST, también es posible que desee dar soporte al método DELETE para manejar la supresión de recursos de archivo subidos. Añada el siguiente método Java para nuestra clase 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 { // No puede suprimir un recurso que no existe. // Se devuelve un error 404. throw new WebApplicationException(Response.Status.NOT_FOUND); } return Response.ok().build(); }
Tenga en cuenta que este método es muy similar a GET. Recibe el nombre de archivo como un objeto de parámetro de método PathParam e intenta suprimir el recurso de archivo. Tenga en cuenta el uso de la anotación @DELETE. El soporte de DELETE se incorpora en todos los contenedores web del servidor de aplicaciones. Ahora la aplicación cliente Dojo puede utilizar el método xhrDelete para enviar solicitudes DELETE HTTP a esta clase de recurso JAX-RS.
Los procedimientos recomentados de REST indican que cuando se crea un nuevo recurso mediante POST, la respuesta de este POST debe incluir una cabecera HTTP Location con un URI a ese nuevo recurso. No obstante, la aplicación File Uploader no es un recurso REST "puro" por el hecho de que podría recibir varios archivos en un único mensaje POST, creando, por lo tanto, varios recursos de archivo nuevos. En consecuencia, el ejemplo no devuelve una cabecera HTTP Location.
El código fuente de la aplicación de ejemplo de File Uploader se proporciona en el archivo de módulo web FileUploader.war en el archivo FileUploader.ear. Existen dos enfoques para visualizar el código fuente: mediante un entorno de desarrollo integrado basado en Eclipse o descomprimiendo el archivo appsvcs-directorylisting.ear y, a continuación, descomprimiendo el archivo .war que contiene.
El primer paso para ver el código fuente es localizar el archivo FileUploader.ear. Si ha instalado IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile, puede encontrar el archivo EAR en el árbol de instalación.
Por ejemplo, si ha instalado el paquete de características en la siguiente ubicación:
Plataforma Ubicación Linux y UNIX: /opt/WebSphere/AppServer Punto de montaje en z/OS: <raíz_instalación> Windows: c:\WebSphere\AppServer
A continuación, puede encontrar el archivo EAR en:
Plataforma Ubicación Linux y UNIX: /opt/WebSphere/AppServer/web2mobilefep_1.1/samples/fileuploader/appsvcs-fileuploader.ear z/OS: <raíz_instalación>/web2mobilefep_1.1/samples/fileuploader/appsvcs-fileuploader.ear Windows: c:\WebSphere\AppServer\web2mobilefep_1.1\samples\fileuploader\appsvcs-fileuploader.ear
La utilización de un entorno de desarrollo integrado basado en Eclipse es el enfoque más sencillo para examinar el código fuente del archivo WAR. Utilice cualquier entorno de desarrollo integrado de Eclipse 3.2.x, 3.3.x con Web Tools Project 2.5 o posteriores, o Rational Application Developer, Versión 7.0 o posteriores para importar el archivo de archivador web (WAR) cuando complete los pasos siguientes:
Cuando el proceso de importación finalice, existirá un proyecto nuevo, FileUploader, en el espacio de trabajo de Eclipse. Se puede acceder al código fuente de la aplicación desde el proyecto FileUploader. Para acceder al código del cliente o del servidor, consulte la tabla siguiente para ver las ubicaciones del código fuente en el árbol de proyectos de Eclipse de FileUploader.
Código fuente | Ubicación |
---|---|
Lado del cliente (navegador web) | WebContent/index.html: contiene las definiciones de widget de Dojo y las funciones de script de cliente. Este archivo carga el perfil de Dojo sin optimizar. |
Lado del servidor | Recursos Java: src/com.ibm.websphere.mobile.appsvcs.sample.fileuploader/ FileUploaderApplication.java: efectúe una doble pulsación en este archivo para cargar el código fuente. |
Recursos Java: src/com.ibm.websphere.mobile.appsvcs.sample.fileuploader. resources/MultiFileUploadDataService.java: efectúe una doble pulsación en este archivo para cargar el código fuente. |
Los archivadores de aplicaciones web son archivos archivadores comprimidos con el algoritmo ZIP. Por lo tanto, el archivo de archivador se puede expandir mediante una gran variedad de herramientas ZIP para comprimir archivos, incluido el programa JAR (Java archive). En los pasos siguientes se supone que el usuario elige su herramienta favorita para crear archivos comprimidos.
Cuando haya expandido el contenido del archivo EAR, expanda también el contenido del archivo .war. A continuación, puede acceder al código fuente. Para acceder al código del cliente o del servidor, consulte la tabla siguiente para ver las ubicaciones del código fuente en el directorio DIR_EXPANS/FileUploader.
Código fuente | Ubicación |
---|---|
Lado del cliente (navegador web) | index.html: contiene las definiciones de widget de Dojo y las funciones de script de cliente. |
Lado del 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 |
Consulte las siguientes instruccciones de instalación específicas de la versión:
En esta sección se describe el procedimiento para instalar la aplicación de ejemplo de File Uploader en la versión 6.1.0.x y posteriores de IBM WebSphere Application Server. Se presupone que está familiarizado con la instalación y la administración de la aplicación para el servidor de aplicaciones.
Busque el archivo de archivador empresarial (EAR) de la aplicación de ejemplo de File Uploader que se proporciona con la instalación del producto. Puede encontrar el archivo EAR en el árbol de instalación donde ha instalado IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile. Por ejemplo, si ha instalado el paquete de características en la siguiente ubicación:
Plataforma Ubicación Linux y UNIX: /opt/WebSphere/AppServer Punto de montaje en z/OS: <raíz_instalación> Windows: c:\WebSphere\AppServer
A continuación, puede encontrar el archivo EAR en:
Plataforma Ubicación Linux y UNIX: /opt/WebSphere/AppServer/web2mobilefep_1.1/samples/application_services/fileuploader/appsvcs-fileuploader.ear z/OS: <raíz_instalación>/web2mobilefep_1.1/samples/application_services/fileuploader/appsvcs-fileuploader.ear Windows: c:\WebSphere\AppServer\web2mobilefep_1.1\samples\application_services\fileuploader\appsvcs-fileuploader.ear
- Inicie la sesión en la consola de administración para el servidor de aplicaciones.
- Vaya a Aplicaciones > Aplicación nueva. (Nota: en WebSphere Application Server Versión 6.1, seleccione Instalar aplicación nueva)
- Seleccione Nueva aplicación empresarial. (Nota: en WebSphere Application Server Versión 6.1, sáltese este paso)
- Examine el sistema de archivos y seleccione el archivo appsvcs-graphics.ear que ha localizado anteriormente. Pulse Siguiente.
- Pulse Siguiente para preparar la instalación de la aplicación. (Nota: en WebSphere Application Server Versión 6.1, sáltese este paso)
- Pulse Siguiente para aceptar las opciones de instalación predeterminadas.
- Pulse Siguiente para aceptar las opciones predeterminadas para correlacionar módulos con servidores.
- Pulse Siguiente para aceptar las opciones predeterminadas para metadatos para módulos. (Nota: en WebSphere Application Server Versiones 6.1 y 7, sáltese este paso)
- Pulse Siguiente para aceptar las opciones predeterminadas para correlacionar hosts virtuales para módulos web.
- Revise el resumen de las opciones de instalación.
- Pulse Finalizar.
- Pulse Guardar en la configuración maestra.
- Vaya a Aplicaciones > Tipos de aplicación > Aplicaciones empresariales WebSphere. (Nota: en WebSphere Application Server Versión 6.1, vaya a Aplicaciones > Aplicaciones empresariales)
- Seleccione IBM WebSphere Application Server - Aplicación de ejemplo de File Uploader y pulse Iniciar.
Apunte el navegador web a la instalación del servidor de aplicaciones: http://<nombre de host del servidor de aplicaciones>:<puerto>/appsvcs-fileuploader/
El nombre de host y el número de puerto del servidor de aplicaciones son específicos de su instalación de servidor de aplicaciones. Un puerto de contenedor web de instalación predeterminado de servidor de aplicaciones es 9080. Si ejecuta el navegador web en la misma estación de trabajo que la instalación del servidor de aplicaciones y ha aceptado todos los valores predeterminados, utilice el URL siguiente: http://localhost:9080/appsvcs-fileuploader/.
En esta sección se describe el procedimiento para instalar la aplicación de ejemplo de File Uploader en la versión 2.x de IBM WebSphere Application Server Community Edition. Se presupone que está familiarizado con la instalación y la administración de la aplicación para el servidor de aplicaciones.
Busque el archivo de archivador empresarial (EAR) de la aplicación de ejemplo de File Uploader que se proporciona con la instalación del producto. Puede encontrar el archivo EAR en el árbol de instalación donde ha instalado IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile. Por ejemplo, si ha instalado el paquete de características en la siguiente ubicación:
Plataforma Ubicación Linux y UNIX: /opt/WebSphere/AppServerCommunityEdition Windows: c:\WebSphere\AppServerCommunityEdition
A continuación, puede encontrar los archivos EAR y de biblioteca en:
Plataforma Ubicación Linux y 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
Inicie la sesión en la consola de administración para el servidor de aplicaciones.
- Pulse Aplicaciones > Aplicación de despliegue en el menú de la izquierda. (Nota: en WebSphere Application Server Community Edition Versión 2.0, pulse Aplicaciones > Desplegar nueva)
- En el campo Archivo, examine el sistema de archivos y seleccione el archivo appsvcs-fileuploader.ear que ha localizado anteriormente. Deje Plan vacío y las opciones predeterminadas seleccionadas. A continuación, pulse Instalar.
La aplicación se inicia automáticamente y se completa la instalación.
Apunte el navegador web a la instalación del servidor de aplicaciones: http://<host del servidor de aplicaciones>:<puerto>/appsvcs-fileuploader/.
El nombre de host y el puerto del servidor de aplicaciones son específicos de su instalación de servidor de aplicaciones. El puerto de contenedor web de instalación predeterminado del servidor WebSphere Application Server Community Edition es 8080. Si está ejecutando el navegador web en la misma estación de trabajo que la instalación del servidor de aplicaciones y ha aceptado todos los valores predeterminados, utilice el URL siguiente: