Getting started with the File Uploader sample application

This page is the starting point for learning about the File Uploader application. The following topics are covered:

Overview of the File Uploader application

The File Uploader sample application was created to complement the use of the dojox.form.File Uploader and dojox.form.Uploader widgets from the Dojo Toolkit for JavaScript. The File Uploader sample demonstrates how to develop a JAX-RS Representational State Transfer (REST) application that can receive and respond to uploads originating from the dojox.form.FileUploader and dojox.form.Uploader widgets in the Dojo Toolkit.

The dojox.form.FileUploader and dojox.form.Uploader widgets upload files in the traditional way that a web browser HTML form would. It uses a multipart/form-data encoded HTTP message. The JAX-RS resource receives the submitted form data already parsed into its multiple parts. This process simplifies the implementation of the server code significantly. The JAX-RS resource class only needs to iterate over the parts and process the data accordingly.

The primary purpose of this File Uploader sample is to demonstrate the simplicity and capability of the JAX-RS resource class. However, to fully demonstrate this simplicity, the dojox.form.Uploader widget is included as a component in a larger Dojo application. Read about writing the File Uploader application for an example.

Prerequisites

Product prerequisite Version
Java Technology Edition 5.0 and later
Java Platform, Enterprise Edition 5 (Java EE) application server and later

WebSphere Application Server Version 6.1.0.x and later

WebSphere Application Server Community Edition Version 2.X.

Web browser Any modern web browser, such as: Internet Explorer 7 and later Mozilla Firefox 3.x and later Google Chrome Safari Opera
Development IDE (Optional) Eclipse version 3.X

Limitations of the File Uploader sample application

The File Uploader sample application is not intended for deployment to production servers. It is for development and educational purposes only.

All source code for the JAX-RS application, resource, and Web pages is provided as is for you to use, copy, and modify without royalty payment when you develop applications that run with WebSphere software. You can use the sample code either for your own internal use or for redistribution as part of an application, or in your products.

Writing the File Uploader sample application

The design of the File Uploader sample application demonstrates how to approach development of an AJAX-based application with the Dojo Toolkit in a Java EE environment conforming to the requirements of the dojox.form.FileUploader and dojox.form.Uploader Dojo widgets. To meet these goals, the two parts of a Java EE application, the client side and the server side, are organized into simple operations that perform a useful function. It follows the basic pattern that Java EE applications use when incorporating AJAX technologies.

Assumptions

The following sections assume that you are already familiar with the JavaScript framework for Dojo, and do not explain in detail the sample Dojo client application or the Dojo dojox.form.Uploader widget that is being used.

The client

The client is the web page that is served to the browser. In the web page, the dojox.form.Uploader widget is instantiated and browser events are connected to this widget. The file system browse is driven by either Shockwave Flash or directly by the JavaScript framework for Dojo. The dojox.form.Uploader widget uses HTML5 if the browser in use supports it, and degrades gracefully to Shockwave Flash or normal HTML depending on the capabilities of the browser. It allows for multiple simultaneous file selection, and submits the file uploads through HTML5 or a hidden HTML iframe. This use of a hidden iframe to perform the upload is required due to the multipart/form-data content type being sent. The response then drives partial page updates. This process, if handled by the HTML5-capable browser or Shockwave Flash, happens without causing a full page reload. The dojox.form.FileUploader widget is deprecated in Dojo 1.6 and is scheduled for removal in Dojo 2.0. It has been replaced by dojox.form.Uploader. The sample service, however, is capable of detecting and replying appropriately to the requirements imposed by each of these two widgets. For more specific information about the client design, read about The File Uploader sample application for the client.

The server

The server provides the infrastructure for processing services and serving Web pages. In this application, the server side is a JAX-RS resource class that receives and processes multipart/form-data POST queries from the dojox.form.FileUploader and dojox.form.Uploader Dojo widgets, and responds according to the requirements of these widgets and the enclosing Dojo application. For dojox.form.FileUploader widget, the reply is dependent on the user agent (the browser, or Shockwave Flash) initiating the POST query. For dojox.form.Uploader widget, the reply is dependent on the "name" field of the multipart/form-data "part" containing the file payload. For non-HTML5 browser-initiated transaction, JavaScript Object Notation (JSON) in an HTML textarea tag is returned. For HTML5-initiated transaction, JSON is returned. If Shockwave Flash initiated the transation, a custom string is returned. The contents of the JSON or custom string are generated according to the requirements of the application making use of the dojox.form.FileUploader and dojox.form.Uploader widgets. For more specific information about the server side design, read about The File Uploader sample application for the server.

The File Uploader sample application for the client

The File Uploader sample application uses the dojox.form.Uploader widget to enable the browse control to the user's local file system for file selection, and provides the control to submit the data upon clicking the widget's submit button. The dojox.form.Uploader browse control is enabled by the widget itself using standard form file input or by enabling the Shockwave Flash application, if the browser has the Shockwave Flash plug-in installed. When browsing the local file system using the browser's HTML5 controls, the user may select multiple files simultaneously. When using the Shockwave Flash plug-in, the user may also select multiple files simultaneously during the browse of the local file system. Browsers that are not HTML5 capable only permit selection of one file at a time during the browse of the local file system, but multiple files may be queued prior to submitting them for upload.

The application built around the dojox.form.Uploader widget includes links to enable or disable support of individual features of the dojox.form.Uploader widget. They are included as part of the application to demonstrate the capability of the widget.

In addition, the application receives response data from the server through the dojox.form.Uploader widget, and uses it to display the recently uploaded files, if possible. It also keeps a list of the files in an array to enable deletion of them from the server when you click the "Delete All Uploaded Files from Server" button. This button triggers the deletePreviousUploads function in the application, which removes the files from the displayed list and uses Dojo AJAX xhrDelete queries to request that the server delete the recently uploaded file resources.

If you are already familiar with dojox.form.Uploader, then you might recognize this application as being similar to one of the tests provided with dojox.form.Uploader in Dojo Toolkit 1.6. This client sample is based heavily on that test, with one major difference. Most HTTP servers do not support the HTTP DELETE method, so the original test did not include such a function. However, the Dojo client application does support the DELETE method.

The primary purpose of this File Uploader sample application is to demonstrate the simplicity of getting a JAX-RS resource developed that can receive submissions from the dojox.form.Uploader, so the exercise of further understanding and coding the client is left to the reader.

For more information on how to use the client side, refer to the application source code. Each section in the HTML document is commented, explaining the purpose of the code block.

The File Uploader sample application for the server

At a minimum, the File Uploader sample application for the server must be capable of receiving a POST query with a multipart/form-data content type. This will be accommodate the requirements of the dojox.form.Uploader widget. This Dojo client sample application that includes the dojox.form.Uploader is capable of displaying the recently uploaded files. This means our JAX-RS resource will need to return data to the client that includes the URL of the just-uploaded file, and can respond to a GET query for that recently uploaded file. In addition, we want the client to be able to request that the recently uploaded file resource be deleted. This means our JAX-RS resource should also have a method that can receive DELETE requests.

The JAX-RS runtime has built-in capability of parsing the payload of the multipart/form-data and passing that data in a org.apache.wink.common.model.multipart.BufferedInMultiPart object instance to the JAX-RS resource class method.

Creating the JAX-RS resource class that will receive the HTTP requests

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

Note this this JAX-RS resource class is declared to have a URL segment of "upload". This resource class will handle requests targeted at http://<server>:<port>/<context-root>/<uri-mapping>/upload

The context root is defined by the application.xml file if your web archive file (.war) is packaged in a enterprise archive (.ear) file. If the .war is installed by itself, the context root is defined at install time by the user. The URI mapping is defined in the WEB-INF/web.xml in the .war file.

Creating the JAX-RS resource methods

The dojox.form.Uploader widget submits the upload just like a browser would; as an HTTP POST with a Content-Type header of multipart/form-data. This information, along with the target URL, is used by the JAX-RS runtime to match the inbound message with the Java method that will receive it. Therefore, implement a method in the JAX-RS resource class to accept it.

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

The @POST annotation declares that this method will receive HTTP POST requests at the URL ending with "upload". Note too that we've declared @Consumes. This helps the JAX-RS runtime match the inbound message with the Java method. The JAX-RS runtime will try to match the inbound message Content-Type header with the @Consumes value.

Creating the JAX-RS core application class

At this point, one more class is required to complete the application. JAX-RS initializes an application and its resources and providers through the class that extends javax.ws.rs.core.Application. Therefore, create the following class.

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

Enabling the JAX-RS application in web.xml

Now we need to put all the pieces together in the web.xml file. Below are the critical parts to enable this JAX-RS application.

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

Note the servlet-class and the init-param with param-name javax.ws.rs.Application. This is the standard way to declare the servlet implementation and pass the reference of the class that extends javax.ws.rs.core.Application to the JAX-RS runtime.

With the inclusion of the WEB-INF/web.xml, the compiled application, and the proper library files in the WEB-INF/lib/ directory of the .war file, the application can be installed to an application server. See the contents of the included sample if you wish to see the list of required libraries. The included sample application is in the form of a .war file packaged within an .ear file. Within the .ear file is the standard application.xml file, which specifies the URL context root of "/appsvcs-fileuploader". Thus the URL to the index.html file is http://<server>:<port>/appsvcs-fileuploader/. Note that the URL specified in the index.html in the sample application is "rest/upload", which is relative to the location of the index.html file, and is the result of the concatenation of the url-pattern in the web.xml and the @Path annotation in the JAX-RS resource class.

For more details on the implementation of the method receiving and processing the multipart/form-data message payload, view the source code, or continue reading.

Upload method implementation

The upload method receives a BufferedInMultiPart object, which is the already-parsed multipart/form-data message payload. Action is taken on each part.

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

Other parts of the BufferedInMultiPart form submission might be regular HTML text type input fields or checkboxes. Processing of these parts is omitted from this sample.

We have successfully received and processed the file parts submitted from the dojox.form.Uploader Dojo widget.

Additional support

The JAX-RS application that you have built so far is sufficient for receiving and processing the multipart/form-data message payload submitted by the dojox.form.Uploader. Now, you must understand the response required by the dojox.form.Uploader, or the specifics of that response needed by the larger enclosing client application. The documentation for the dojox.form.Uploader states that the reply must have a Content-Type header of "text/html". In a JAX-RS resource class, this is trivial to declare. You need only to declare the content type in a method level @Produces annotation. The JAX-RS runtime will assign the appropriate HTTP header; for example:

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

In addition, the documentation for dojox.form.Uploader states that it requires the response to be a JSON array wrapped in a <textarea> tag when replying to the browser user agent from a non-HTML5 browser. For now, assume that the default user agent is a non-HTML5 browser, not an HTML5 browser and not Shockwave Flash. Building on the previous implementation above, and now importing com.ibm.json.java.JSONArray and com.ibm.json.java.JSONObject, you can supply the returned JSON array with the contents required by the sample Dojo client application.

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

The dojox.form.FileUploader widget documentation states that the User-Agent header determines the format of the response. The dojox.form.Uploader widget documentation states that the service receiving uploads must use the "name" of the multipart/form-data "parts" to determine the sender of the data, and reply accordingly. The following example includes name and parts.

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

You notice that the upload method now takes an additional parameter: @Context UriInfo uriInfo. The @Context annotation instructs the JAX-RS runtime to inject an instance of the declared type into the upload method invocation parameters. The lifecycle of this injected instance is per HTTP request. This injected UriInfo instance must detect the URL that was used to invoke the upload method. Once you have this information, you can use it to return the resource URL of the just uploaded files so the Dojo client application can call the HTTP GET request that uploaded file resource. This is in keeping with the best practices of REST interfaces.

Now the dojox.form.Uploader widget will receive the required response, and pass the formatted data as a JavaScript object back to the Dojo client application, which will use it to request the recently uploaded file resource.

The utility methods called from our upload method implementation, such as parseContentDispositionHeader, readInputStream, and getFileURL are not described here, but can be inspected in the included sample source code.

Using the GET request to fetch the uploaded file

The Dojo client application intends to display the just uploaded file immediately upon receiving the response from the POST request. The response from the POST request includes a URI to the uploaded files, which will be used in the "src" attribute of a generated <img> tag. Therefore, our JAX-RS resource class must do one of two things:

The following example demonstrates the second action, where the Java method is added to the JAX-RS resource class:

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

There are several things to note about this Java method. First, the string declared in teh @Path annotation is declared with braces so that it is passed as a parameter to the getImage method. This means the request URL for this Java method supporting the GET HTTP method is http://<server>:<port>/fileuploader/rest/upload/uploadedfile.jpg. The returned object from this getImage method is a JAX-RS Response object. This gives you more control over the specifics of the response than is possible with the use of JAX-RS annotations. Declare the Content-Type of the reply, and pass the raw FileInputStream back to the JAX-RS runtime. To the browser, the recently uploaded file resource is available at the URL specified in the reply from the POST query. Although, the actual Java file might be anywhere on the server.

Note the use of the variable rootPath. This variable value is defined by a configuration parameter declared in an init-param of the web.xml file and can be retrieved from an @Context injected ServletConfig instance object. See the sample source code for this feature.

Deleting file resources

At this point, our JAX-RS resource class supports POST and GET requests to accommodate the requirements of the dojox.form.Uploader widget and the enclosing Dojo client application. Given this is a REST interface, you may also want to support the DELETE method to handle deleting uploaded file resources. Add the following Java method to our JAX-RS resource class:

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

Notice this method is very similar to the GET. It receives the filename as a PathParam method parameter object and attempts to delete the file resource. Note the use of the @DELETE annotation. Support for DELETE is built into all application server web containers. The Dojo client application can now use the xhrDelete method to send DELETE HTTP requests to this JAX-RS resource class.

REST interface best practices

REST best practices state that when a new resource is created through a POST, the reply from that POST should include a Location HTTP header with a URI to that new resource. However, the File Uploader application is not a "pure" REST resource in that it might receive multiple files in one POST message; therefore creating multiple new file resources. Therefore, the sample does not return a Location HTTP header.

Viewing the source code of the File Uploader sample application

The source code of the File Uploader sample application is provided within the FileUploader.war web module file within the FileUploader.ear file. There are two approaches to viewing the source code: through an Eclipse-based Integrated Development Environment (IDE) or by decompressing the appsvcs-directorylisting.ear file, then decompressing the .war file contained inside.

Locating the EAR file

The first step in viewing the source code is locating the FileUploader.ear file. If you have installed the IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile, then you can find the EAR file in your installation tree.

For example, if you installed the feature pack in the following location:

Platform Location
Linux and UNIX: /opt/WebSphere/AppServer
z/OS mount point: <install_root>
Windows: c:\WebSphere\AppServer

Then you can find the EAR file at:

Platform Location
Linux and 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

Viewing the source code in an Eclipse-based IDE

Using an Eclipse-based IDE is the simplest approach to examining the source code of the WAR file. Use any Eclipse 3.2.X, 3.3.X IDE with the Web Tools Project 2.5 or later, or Rational Application Developer, Version 7.0 or higher, can import the web archive (WAR) file when you complete the following steps:

  1. Expand the appsvcs-fileuploader.ear file.
  2. From the Eclipse IDE menu, open the File menu and select Import.
  3. In the presented panel, expand the Web option. Then select the WAR file, and click Next.
  4. In the WAR File entry field, click Browse, and select the file you located earlier.
  5. Accept the default options, if they are acceptable, and click Finish.

When the import process completes, a new project, FileUploader, exists in the Eclipse workspace. The application source code can be accessed from the FileUploader project. To access the client or server code, see the following table for source code locations in the FileUploader Eclipse project tree.

Source Code Location
Client side (Web Browser) WebContent/index.html: Contains the Dojo Widget definitions and client script functions. This file loads the unoptimized Dojo profile.
Server side Java Resources: src/com.ibm.websphere.mobile.appsvcs.sample.fileuploader/ FileUploaderApplication.java: Double-click this file to load the source code.
Java Resources: src/com.ibm.websphere.mobile.appsvcs.sample.fileuploader. resources/MultiFileUploadDataService.java: Double-click this file to load the source code.

Viewing the source code by extracting the web application archive file

Web application archives are file archives compressed using the ZIP algorithm. Therefore, the archive file can be expanded by any number of ZIP tools tools for compressing files, including the Java archive (JAR) program. The following steps assume that the user chooses their favorite tool to create compressed files.

  1. Expand the FileUploader.ear file you located earlier into a directory on your system using your favorite tool for compressing files. The following steps assume that EXPAND_DIR/FileUploader is the correct location.
  2. List the files in the EXPAND_DIR/FileUploader directory that the FileUploader.ear file was expanded into.

After you have expanded the EAR file contents, you should also expand the .war file contents. Then you can access the source code. To access the client or server code, see the following table for source code locations in the EXPAND_DIR/FileUploader directory.

Source Code Location
Client side (Web Browser) index.html: Contains the Dojo widget definitions and client script functions.
Server side 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

Installing the File Uploader sample application

Refer to the following version-specific installation instructions:

WebSphere Application Server installation instructions

This section describes the procedure for installing the File Uploader sample application on Version 6.1.0.X and later of the IBM WebSphere Application Server. It is assumed that you are familiar with application installation and administration for the application server.

Before you begin

Locate the File Uploader sample application enterprise archive (EAR) file that is provided with your product installation. You can find the EAR file in your installation tree where you installed the IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile. For example, if you installed the feature pack in the following location:

Platform Location
Linux and UNIX: /opt/WebSphere/AppServer
z/OS mount point: <install_root>
Windows: c:\WebSphere\AppServer

Then you can find the EAR file at:

Platform Location
Linux and 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

Installing the File Uploader sample application using the administrative console

  1. Log into the administrative console for the application server.
  2. Navigate to Applications > New Application. (Note: In WebSphere Application Server Version 6.1, select Install New Application)
  3. Select New Enterprise Application. (Note: In WebSphere Application Server Version 6.1, skip this step)
  4. Browse your file system, and select the appsvcs-graphics.ear file that you located earlier. Click Next.
  5. Click Next to prepare for the application installation. (Note: In WebSphere Application Server Version 6.1, skip this step)
  6. Click Next to accept the default installation options.
  7. Click Next to accept the default options for map modules to servers.
  8. Click Next to accept the default options for Metadata for modules. (Note: In WebSphere Application Server Versions 6.1 and 7, skip this step)
  9. Click Next to accept the default options for map virtual hosts for web modules.
  10. Review the summary of the installation options.
  11. Click Finish.
  12. Click Save to the master configuration.
  13. Navigate to Applications > Application Types > WebSphere Enterprise Applications. (Note: In WebSphere Application Server Version 6.1, Navigate to Applications > Enterprise Applications)
  14. Select the IBM WebSphere Application Server - File Uploader sample application, and click Start.

Access the installed application demo client

Point your web browser to your application server installation: http://<application server hostname>:<port>/appsvcs-fileuploader/

The application server host name and port number are specific to your application server installation. An application server default installation web container port is 9080. If you are running your web browser on the same workstation as your application server installation and have taken all the default values, then use the following URL: http://localhost:9080/appsvcs-fileuploader/.

WebSphere Application Server Community Edition Version 2.X installation instructions

This section describes the procedure for installing the File Uploader sample application into Version 2.X of the IBM WebSphere Application Server Community Edition. It is assumed that you are familiar with application installation and administration for the application server.

Before you begin

Locate the File Uploader sample application enterprise archive (EAR) file that is provided with your product installation. You can find the EAR file in your installation tree where you installed the IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile. For example, if you installed the feature pack in the following location:

Platform Location
Linux and UNIX: /opt/WebSphere/AppServerCommunityEdition
Windows: c:\WebSphere\AppServerCommunityEdition

Then, you can find the EAR and library files at:

Platform Location
Linux and 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 through the administrative console

Log into the administrative console for the application server.

  1. Click Applications > Deployer in the left menu. (Note: In WebSphere Application Server Community Edition Version 2.0, click Applications > Deploy New)
  2. In the Archive field, browse your file system, and select the appsvcs-fileuploader.ear file that you located earlier. Leave the Plan blank and the default options selected. Then, click Install.

The application starts automatically, and installation is complete.

Access the installed application demo client

Point your Web browser to your application server installation: http://<application server hostname>:<port>/appsvcs-fileuploader/.

The application server host name and port is specific to your application server installation. The WebSphere Application Server Community Edition server default installation Web container port is 8080. If you are running your browser on the same workstation as your application server installation and have accepted all the default values, then use the following URL:

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