File Uploader サンプル・アプリケーション入門

このページは、File Uploader アプリケーションについて学習するための 開始点です。次のトピックが取り上げられています。

File Uploader アプリケーションの概要

File Uploader サンプル・アプリケーションは、Dojo Toolkit for JavaScript の dojox.form.File Uploader ウィジェット および dojox.form.Uploader ウィジェットの使用を補完するために 作成されたものです。File Uploader サンプルは、 Dojo Toolkit の dojox.form.FileUploader ウィジェットおよび dojox.form.Uploader ウィジェットが行うアップロードを受け取って 応答することができる JAX-RS Representational State Transfer (REST) アプリケーションの開発方法を示します。

dojox.form.FileUploader ウィジェットおよび dojox.form.Uploader ウィジェットは、 Web ブラウザー HTML フォームが行うような伝統的な方法でファイルをアップロードします。この方法では、multipart/form-data エンコード HTTP メッセージが使用されます。 サブミットされたフォーム・データを JAX-RS リソースが受け取りますが、このデータは既に解析されて複数のパーツに なっています。この処理によって、サーバー・コードの実装が大幅に単純化されます。 JAX-RS リソース・クラスは、これらのパーツについて反復して、内容に応じてデータを処理すればいいだけです。

この File Uploader サンプルの主要な目的は、JAX-RS リソース・クラスの単純さと機能を 示すことです。ただし、この単純さをフルに示すため、 dojox.form.Uploader ウィジェットは、より大きい Dojo アプリケーションに 1 つのコンポーネントとして組み込まれています。 例について、File Uploader アプリケーションの作成についての説明を参照してください。

前提条件

前提となる製品 バージョン
Java Technology Edition 5.0 以降
Java Platform, Enterprise Edition 5 (Java EE) アプリケーション・サーバー以降

WebSphere Application Server バージョン 6.1.0.x 以降

WebSphere Application Server Community Edition バージョン 2.X

Web ブラウザー 任意の新しい Web ブラウザー (例: Internet Explorer 7 以降、 Mozilla Firefox 3.x 以降、Google Chrome、Safari、Opera)
開発 IDE (オプション) Eclipse バージョン 3.X

File Uploader サンプル・アプリケーションの制限

File Uploader サンプル・アプリケーションは、実動サーバーへのデプロイメントを目的としていません。 開発および研修目的にのみ使用してください。

JAX-RS アプリケーション、リソース、および Web ページのすべてのソース・コードは、 WebSphere ソフトウェアと共に稼働するアプリケーションを開発する際に、無料で使用し、 複製し、変更することができるよう、現存するままの状態で提供されます。サンプル・コードは、 ユーザー環境内でのみ使用する場合、またはアプリケーションの一部として、すなわち自社製品において再配布する場合のいずれの場合にも使用できます。

File Uploader サンプル・アプリケーションの作成

File Uploader サンプル・アプリケーションは、 dojox.form.FileUploader ウィジェットおよび dojox.form.Uploader Dojo ウィジェットの要件に合わせて、Java EE 環境で Dojo Toolkit を使用して Ajax ベースの アプリケーションを開発する方法を示すように設計されています。これらの目標を達成するため、1 つの Java EE アプリケーションが 2 つの パート (クライアント・サイドとサーバー・サイド) に分かれていて、単純ないくつかの操作によって 1 つの有用な機能が実行されるように編成され ています。これは、Ajax テクノロジーを取り込むときに Java EE アプリケーションが使用する 基本的なパターンに従っています。

想定事項

以降のセクションでは、Dojo の JavaScript フレームワークに 関する知識があることが前提となっていて、サンプル Dojo クライアント・アプリケーションや 使用されている Dojo dojox.form.Uploader ウィジェットに関する詳しい説明はありません。

クライアント

クライアントは、ブラウザーにサービスを提供する Web ページです。この Web ページでは、 dojox.form.Uploader ウィジェットがインスタンス化され、ブラウザー・イベントがこのウィジェット に接続されます。ファイル・システム・ブラウズは、Shockwave Flash によって駆動されるか、 または、Dojo の JavaScript フレームワークによって直接駆動されます。dojox.form.Uploader ウィジェットは、使用されているブラウザー が HTML5 をサポートしている場合は HTML5 を使用し、ブラウザーの機能に応じて、Shockwave Flash または通常の HTML に グレードを下げます。このウィジェットは、複数ファイルの同時選択ができ、 HTML5 または隠蔽されている HTML iframe を介してファイル・アップロードをサブミットします。隠蔽されている iframe を アップロード実行のために使用する必要があるのは、multipart/form-data コンテンツ・タイプ が送信されるためです。その後、応答によって、部分的なページ更新が起こります。このプロセス は、HTML5 対応ブラウザーまたは Shockwave Flash によって処理される場合は、フルページの再ロード を起こしません。dojox.form.FileUploader ウィジェットは、Dojo 1.6 では非推奨であり、 Dojo 2.0 で削除される予定です。これは dojox.form.Uploader によって置換されました。しかし、 サンプル・サービスは、これら 2 つのウィジェットのそれぞれの要件に応じて、検出および応答を 実行できるようになっています。クライアント設計に関するより詳しい説明については、 クライアント用の File Uploader サンプル・アプリケーションをお読みください。

サーバー

サーバーは、サービスの処理および Web ページへのサービス提供のためのインフラストラクチャーを提供します。 このアプリケーションでは、 サーバー・サイドは、dojox.form.FileUploader ウィジェットおよび dojox.form.Uploader Dojo ウィジェット から multipart/form-data POST 照会を受け取って処理し、 それらのウィジェットおよびそれらを含んでいる Dojo アプリケーションの要件に従って応答 する、JAX-RS リソース・クラスです。dojox.form.FileUploader ウィジェットの場合、 応答は、POST 照会を開始したユーザー・エージェント (ブラウザー、または Shockwave Flash) に依存します。dojox.form.Uploader ウィジェット の場合、応答は、ファイル・ペイロードを含んでいる multipart/form-data "part" の "name" フィールド に依存します。HTML5 に対応していないブラウザーが開始したトランザクションの場合、HTML textarea タグ内の JavaScript Object Notation (JSON) が 戻されます。HTML5 が開始したトランザクションの場合、JSON が 戻されます。Shockwave Flash がトランザクションを開始した場合は、カスタム・ストリングが戻されます。JSON または カスタム・ストリングの内容は、dojox.form.FileUploader ウィジェットおよび dojox.form.Uploader ウィジェット を使用するアプリケーションの要件に従って生成されます。サーバー・サイド設計に関する より詳しい説明については、サーバー用 File Uploader サンプル・アプリケーションをお読みください。

クライアント用 File Uploader サンプル・アプリケーション

File Uploader サンプル・アプリケーションは、dojox.form.Uploader ウィジェットを使用して、 ユーザーのローカル・ファイル・システムにおけるファイル選択のためのブラウズ・コントロールを可能にします。 また、このサンプル・アプリケーションは、ウィジェットのサブミット・ボタンのクリックに応じてデータをサブミットするコントロールも提供します。dojox.form.Uploader ブラウズ・コントロール は、標準形式ファイル入力を使用してこのウィジェット自体によって有効にされるか、 または、ブラウザーが Shockwave Flash プラグインをインストール済みの場合は Shockwave Flash アプリケーションを 使用可能にすることによって有効にされます。ブラウザーの HTML5 コントロールを使用して ローカル・ファイル・システムをブラウズする際、ユーザーは同時に複数のファイルを選択できます。Shockwave Flash プラグイン を使用している場合も、ユーザーはローカル・ファイル・システムのブラウズ中に、同時に複数のファイルを選択 できます。HTML5 に対応していないブラウザーでは、ローカル・ファイル・システムのブラウズ中に一度に 1 つの ファイルの選択しかできませんが、複数のファイルをキューに入れておいて、後でまとめてアップロードをサブミットすることができます。

dojox.form.Uploader ウィジェットの周囲に作成されたこのアプリケーション は、dojox.form.Uploader ウィジェットの個々の機能のサポートを有効または無効にするための一連のリンクを含んでいます。これらのリンクは、 ウィジェットの機能を示すために、アプリケーションの一部として組み込まれています。

さらに、このアプリケーションは dojox.form.Uploader ウィジェットを通してサーバーから応答データを 受け取り、それを使用して、可能であれば、最近アップロードされた ファイルを表示します。また、ファイルのリストを配列で保持して、 「アップロードされたすべてのファイルをサーバーから削除」ボタンがクリックされたときにそれらのファイルをサーバーから削除できるようにします。 このボタンは、アプリケーション内の deletePreviousUploads 関数を 起動します。この関数は表示リストからファイルを削除し、Dojo AJAX xhrDelete 照会を 使用して、最近アップロードされたファイル・リソースを削除するようサーバーに要求します。

既に dojox.form.Uploader に関する知識がある読者は気付いているかもしれませんが、この アプリケーションは、Dojo Toolkit 1.6 で dojox.form.Uploader と共に提供されるテストの 1 つに 似ています。このクライアント・サンプルは大部分はそのテストに基づいていますが、大きな違いが 1 つあります。ほとんど の HTTP サーバーは、HTTP DELETE メソッドをサポートしないため、元になったテストはそのような関数を 含んでいませんでした。しかし、この Dojo クライアント・アプリケーションは、DELETE メソッドをサポートします。

この File Uploader サンプル・アプリケーションの主な目的は、dojox.form.Uploader からの サブミットを受け取ることのできる JAX-RS リソースの開発の単純さを示すことです。 したがって、さらに詳しい理解やクライアントのコーディングについてはご自身で行ってください。

クライアント・サイドの使用方法について詳しくは、アプリケーションの ソース・コードを参照してください。HTML 文書の各セクションにコメントが付けられ、コード・ブロックの目的が説明されています。

サーバー用 File Uploader サンプル・アプリケーション

最小でも、サーバー用 File Uploader サンプル・アプリケーションは、 multipart/form-data コンテンツ・タイプの POST 照会を受け取ることができる必要があります。これは、 dojox.form.Uploader ウィジェットの要件に適合します。dojox.form.Uploader を含んでいる Dojo クライアント・サンプル・アプリケーション は、最近アップロードされたファイルを表示することができます。これが意味するのは、 この JAX-RS リソースは、アップロードされたばかりのファイルの URL を含むデータをクライアントに戻す必要があり、 その最近アップロードされたファイルに対する GET 照会に応答できるということです。それに加えて、 最近アップロードされたファイル・リソースの削除をクライアントが要求 できるようにするという要件があります。すなわち、この JAX-RS リソース は DELETE 要求を受け取ることのできるメソッドも備えている必要があるということです。

JAX-RS ランタイムには、multipart/form-data の ペイロードを解析し、そのデータを org.apache.wink.common.model.multipart.BufferedInMultiPart オブジェクト・インスタンス に入れて JAX-RS リソース・クラス・メソッドに渡す機能が組み込まれています。

HTTP 要求を受け取る 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
{
   // ...
}

この JAX-RS リソース・クラスは URL セグメント "upload" を持つよう宣言されていることに注意してください。この リソース・クラスは、 http://<server>:<port>/<context-root>/<uri-mapping>/upload をターゲットにする要求を処理します。

コンテキスト・ルートは、Web アーカイブ・ファイル (.war) がエンタープライズ・アーカイブ・ファイル (.ear) 内に パッケージされている場合、application.xml ファイルによって定義されます。.war が単独でインストールされている場合は、コンテキスト・ルートはユーザーによってインストール時に 定義されます。URI マッピングは .war ファイル内の WEB-INF/web.xml に定義されます。

JAX-RS リソース・メソッドの作成

dojox.form.Uploader ウィジェットは、ブラウザーが実行する場合と同じように、 Content-Type ヘッダーが multipart/form-data の HTTP POST として、アップロードをサブミットします。JAX-RS ランタイム は、この情報とターゲット URL を使用して、インバウンド・メッセージを、それを受け取ることになる Java メソッドと マッチングします。したがって、JAX-RS リソース・クラスに、それを受け入れるメソッドを実装します。

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

@POST アノテーションは、このメソッドが、 "upload" で終わる URL で HTTP POST 要求を受け取ることを宣言しています。@Consumes が宣言されていることにも注意してください。これは、JAX-RS ランタイム がインバウンド・メッセージを Java メソッドとマッチングするのに役立ちます。JAX-RS ランタイムは、 インバウンド・メッセージ Content-Type ヘッダーを @Consumes 値とマッチングしようとします。

JAX-RS コア・アプリケーション・クラスの作成

この時点で、アプリケーションを完了するためにさらに 1 つのクラスが必要です。JAX-RS は、 javax.ws.rs.core.Application を継承するクラスを通して、 アプリケーションおよびそのリソースとプロバイダーを初期設定します。したがって、以下のクラスを作成します。

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

web.xml 内での JAX-RS アプリケーションの使用可能化

次に、すべての断片を web.xml ファイル内でまとめる必要があります。以下は、この 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>
...

servlet-class、および param-name が javax.ws.rs.Application の init-param に注意してください。 これは、サーブレット実装を宣言し、 javax.ws.rs.core.Application を継承するクラスの参照を JAX-RS ランタイムに渡す、標準的な方法です。

WEB-INF/web.xml、コンパイル済みアプリケーション、 および適切なライブラリー・ファイルを .war ファイルの WEB-INF/lib/ ディレクトリーに組み込んで、 アプリケーションをアプリケーション・サーバー上にインストールできます。必要なライブラリー のリストを確認したい場合は、含まれているサンプルの内容を参照してください。含まれているサンプル・アプリケーション は、.ear ファイル内にパッケージされた .war ファイルの形式です。.ear ファイル内の標準 application.xml ファイル は、"/appsvcs-fileuploader" の URL コンテキスト・ルートを指定します。したがって、index.html ファイル への URL は http://<server>:<port>/appsvcs-fileuploader/ です。サンプル・アプリケーション の index.html 内に指定された URL は、index.html ファイルの場所に相対的な "rest/upload" であり、 web.xml 内の url-pattern と JAX-RS リソース・クラス内 の @Path アノテーションとを結合したものであることに注意してください。

multipart/form-data メッセージ・ペイロード を受け取って処理するメソッドの実装について詳しくは、ソース・コードを参照するか、先をお読みください。

upload メソッド実装

upload メソッドは、既に解析済みの multipart/form-data メッセージ・ペイロード である BufferedInMultiPart オブジェクトを受け取ります。各パートに対してアクションが実行されます。

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

BufferedInMultiPart フォーム・サブミットの他のパートは、通常の HTML テキスト・タイプ の入力フィールドまたはチェック・ボックスである可能性があります。これらのパートの処理は、このサンプルからは省略されています。

これで、dojox.form.Uploader Dojo ウィジェットからサブミットされたファイル・パートを 正常に受け取って処理を完了しました。

追加サポート

ここまでで作成した JAX-RS アプリケーションは、dojox.form.Uploader によって サブミットされた multipart/form-data メッセージ・ペイロードを受け取って処理するのには十分です。次に、 dojox.form.Uploader によって必要とされる応答について、または、 これを包含するクライアント・アプリケーションによって必要とされるその応答の特性について、理解する必要があります。dojox.form.Uploader の 文書に、応答の Content-Type ヘッダーは "text/html" でなければならないと 記述されています。JAX-RS リソース・クラス内でこれを宣言するのは簡単です。メソッド・レベルの @Produces アノテーションで コンテンツ・タイプを宣言すればいいだけです。JAX-RS ランタイムは、 以下の例のように、適切な HTTP ヘッダーを割り当てます。

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

さらに、文書によると、dojox.form.Uploader は、HTML5 に対応していないブラウザーからのブラウザー・ユーザー・エージェントに応答するときには、 応答が <textarea> タグ内の JSON 配列であることを必要 とします。ここで、デフォルトのユーザー・エージェント は HTML5 に対応していないブラウザーであり、HTML5 ブラウザーでも Shockwave Flash でもないと仮定します。上述の 実装の上にビルドし、ここで com.ibm.json.java.JSONArray および com.ibm.json.java.JSONObject を インポートすることによって、戻される JSON 配列に、サンプル Dojo クライアント・アプリケーションが 必要とする内容を提供することができます。

@POST
@Consumes(MediaType.MULTIPART_FORM_DATA)
@Produces(MediaType.TEXT_HTML)
public String upload(@Context UriInfo uriInfo, BufferedInMultiPart bimp)
{
   JSONArray jsonArray = new JSONArray();
   List<InPart> parts = bimp.getParts();

   for (int i = 0; i < parts.size(); i++) {
      if (parts.get(i).getHeaders().containsKey("Content-Disposition")) {
         ArrayList<String> list = (ArrayList<String>)parts.get(i)
                                  .getHeaders().get("Content-Disposition");

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

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

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

dojox.form.FileUploader ウィジェットの文書には、User-Agent ヘッダーが 応答のフォーマットを決定すると記述されています。dojox.form.Uploader ウィジェットの文書には、 アップロードを受け取るサービスは multipart/form-data "parts" の "name" を 使用してデータの送信者を判別し、それに応じて応答すると記述されています。以下の例には、name および 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;
}

upload メソッドに新しくパラメーター @Context UriInfo uriInfo が追加されていることに 注意してください。この @Context アノテーションは、JAX-RS ランタイムに、 宣言されたタイプのインスタンスを upload メソッド起動パラメーターに注入するよう指示します。注入されたこのインスタンスの ライフサイクルは、HTTP 要求ごとです。注入されたこの UriInfo インスタンスは、upload メソッドを 起動するのに使用された URL を検出する必要があります。この情報をいったん入手すれば、それを使用して、 アップロードされたばかりのファイルのリソース URL を戻すことができ、Dojo クライアント・アプリケーション はファイル・リソースをアップロードした HTTP GET 要求を呼び出すことができます。これは REST インターフェースのベスト・プラクティスに合っています。

これで、dojox.form.Uploader ウィジェットは、必要な応答を受け取って、フォーマット されたデータを JavaScript オブジェクトとして Dojo クライアント・アプリケーションに戻すようになり、このクライアント・アプリケーション は、それを使用して、最近アップロードされたファイル・リソースを要求します。

parseContentDispositionHeader、readInputStream、および getFileURL など、この upload メソッド実装から呼び出される ユーティリティー・メソッドについてはここでは説明しませんが、 含まれているサンプル・ソース・コード内で調べることができます。

アップロードされたファイルを取り出すための GET 要求の使用

Dojo クライアント・アプリケーションは、アップロードされたばかりのファイルを、POST 要求から 応答を受け取ったらすぐに表示することを目的としています。POST 要求からの応答には、アップロードされたファイルへの URI が 含まれていて、生成される <img> タグの "src" 属性でそれが使用されます。 したがって、この JAX-RS リソース・クラスは以下の 2 つのうちのいずれかを実行する必要があります。

次の例は、2 番目のアクションを示しています。この例では、Java メソッド が 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);
}

この Java メソッドについて注意するべき点がいくつかあります。まず最初は、@Path アノテーション に宣言されているストリングは、getImage メソッドにパラメーターとして渡されるよう、中括弧を付けて宣言されていることです。 これが意味するのは、GET HTTP メソッドをサポートするこの Java メソッドの要求 URL が http://<server>:<port>/fileuploader/rest/upload/uploadedfile.jpg であるということです。この getImage メソッド から戻されるオブジェクトは JAX-RS Response オブジェクトです。これによって、JAX-RS アノテーションを 使用する場合よりも、応答の特性に対してより細かく制御することが可能になります。応答 の Content-Type を宣言し、未加工の FileInputStream を JAX-RS ランタイムに渡します。 ブラウザーでは、POST 照会からの応答に指定された URL で、最近アップロードされたファイル・リソース が使用可能です。ただし、実際の Java ファイル はサーバー上のどこかにある可能性があります。

変数 rootPath の使用に注意してください。この変数値は、 web.xml ファイル内の init-param に宣言された 1 つの構成パラメーターによって定義され、@Context が注入された ServletConfig インスタンス・オブジェクト から取得できます。このフィーチャーについては、サンプル・ソース・コードを参照してください。

ファイル・リソースの削除

この時点で、この JAX-RS リソース・クラスは POST 要求および GET 要求を サポートすることで、dojox.form.Uploader ウィジェットおよびそれを含む Dojo クライアント・アプリケーション の要件に適応しています。これが REST インターフェースであると想定すると、アップロードされたファイル・リソースの 削除を処理する DELETE メソッドもサポートすることが望ましいことがあります。以下の Java メソッド を 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();
}

このメソッドは GET によく似ていることに注意してください。このメソッドは、filename を PathParam メソッド・パラメーター・オブジェクト として受け取り、ファイル・リソースを削除しようとします。@DELETE アノテーション の使用に注意してください。DELETE のサポートは、すべてのアプリケーション・サーバー Web コンテナー内に構築されます。これで、 Dojo クライアント・アプリケーションは、xhrDelete メソッドを使用して、この JAX-RS リソース・クラスに DELETE HTTP 要求 を送信できるようになりました。

REST インターフェースのベスト・プラクティス

REST ベスト・プラクティスでは、新しいリソースが POST を通して作成されたときには、 その POST からの応答には、その新規リソースへの URI を持つ Location HTTP ヘッダーが含まれているべきだとされています。 しかし、File Uploader アプリケーションは、1 つの POST メッセージで複数のファイルを受け取る可能性があり、 その結果として複数の新規ファイル・リソースを作成することがあるという点において、「純粋な」REST リソースではありません。 したがって、このサンプルは Location HTTP ヘッダーを戻しません。

File Uploader サンプル・アプリケーションのソース・コードの表示

File Uploader サンプル・アプリケーションのソース・コード は、FileUploader.ear ファイル内の FileUploader.war Web モジュール・ファイル内にあります。ソース・コード を表示する方法には 2 つの方法があります。Eclipse ベースの統合開発環境 (IDE) を介して 表示する方法と、appsvcs-directorylisting.ear ファイルを解凍し、内部に含まれる .war ファイルを解凍する方法です。

EAR ファイルの探索

ソース・コードを表示するための最初のステップは、FileUploader.ear ファイルの場所を探索することです。 IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile を インストール済みの場合、この EAR ファイルはインストール・ツリー内にあります。

例えば、このフィーチャー・パックを以下の場所にインストールしたとします。

プラットフォーム 場所
Linux および UNIX の場合: /opt/WebSphere/AppServer
z/OS マウント・ポイント: <install_root>
Windows: c:\WebSphere\AppServer

この場合、EAR ファイルは次の場所にあります。

プラットフォーム 場所
Linux および 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

Eclipse ベースの IDE におけるソース・コードの表示

Eclipse ベースの IDE の使用は、WAR ファイルのソース・コードを 調べるための最も単純な方法です。以下のステップを完了すると、任意の Eclipse 3.2.X、3.3.X IDE を Web Tools Project 2.5 以降 または Rational Application Developer バージョン 7.0 以上と共に 使用して、Web アーカイブ (WAR) ファイルをインポートできます。

  1. appsvcs-fileuploader.ear ファイルを展開します。
  2. Eclipse IDE メニューから、「ファイル」メニューを開いて「インポート」を選択します。
  3. 表示されるパネルで、「Web」オプションを展開します。次に、「WAR ファイル」を選択して「次へ」をクリックします。
  4. WAR ファイル」入力フィールドで、「参照」をクリックし、前に場所を確認しておいたファイルを選択します。
  5. デフォルト・オプションが適切であれば受け入れ、「完了」をクリックします。

インポート・プロセスが完了したら、新しいプロジェクトである FileUploader が、Eclipse ワークスペース に表示されます。この FileUploader プロジェクトから、アプリケーション・ソース・コードにアクセスできます。 クライアント・コードまたはサーバー・コードにアクセスするには、以下の表で、 FileUploader Eclipse プロジェクト・ツリー内のソース・コードの場所を参照してください。

ソース・コード 場所
クライアント・サイド (Web ブラウザー) WebContent/index.html: Dojo ウィジェット定義およびクライアント・スクリプト関数 を含みます。このファイルは最適化されていない Dojo プロファイルをロードします。
サーバー・サイド Java リソース: src/com.ibm.websphere.mobile.appsvcs.sample.fileuploader/ FileUploaderApplication.java: このファイルをダブルクリックすると、 ソース・コードがロードされます。
Java リソース: src/com.ibm.websphere.mobile.appsvcs.sample.fileuploader. resources/MultiFileUploadDataService.java: このファイルをダブルクリックすると、ソース・コードがロードされます。

Web アプリケーション・アーカイブ・ファイルを解凍することによるソース・コードの表示

Web アプリケーション・アーカイブは、zip アルゴリズムを使用して圧縮されたファイル・アーカイブです。したがって、 Java アーカイブ (JAR) プログラムを含め、ファイルを圧縮するためのさまざまなツールを使用してアーカイブ・ファイルを 解凍できます。以下のステップでは、ユーザー が選択したツールを使用して圧縮ファイルが作成されていると想定します。

  1. 前に場所を確認しておいた FileUploader.ear ファイルを、 任意のファイル圧縮ツールを使用して、システム上のいずれかのディレクトリーに解凍します。以下の ステップでは、EXPAND_DIR/FileUploader が正しい場所であると想定します。
  2. FileUploader.ear を解凍した EXPAND_DIR/FileUploader ディレクトリー 内のファイルをリストします。

EAR ファイルの内容を解凍した後、.war ファイルの内容も 解凍する必要があります。これで、ソース・コードにアクセスできるようになります。クライアント・コード またはサーバー・コードにアクセスするには、以下の表 で EXPAND_DIR/FileUploader ディレクトリー内のソース・コードの場所を参照してください。

ソース・コード 場所
クライアント・サイド (Web ブラウザー) index.html: Dojo ウィジェット定義およびクライアント・スクリプト関数を 含みます。
サーバー・サイド 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

File Uploader サンプル・アプリケーションのインストール

以下のバージョン固有のインストール手順を参照してください。

WebSphere Application Server インストール手順

このセクションでは、バージョン 6.1.0.X 以降の IBM WebSphere Application Server に File Uploader サンプル・アプリケーションをインストールする手順を説明します。ここでは、アプリケーションのインストールとアプリケーション・サーバーの管理についての知識があることを前提としています。

始める前に

製品インストールと共に提供される File Uploader サンプル・アプリケーション・エンタープライズ・アーカイブ (EAR) ファイルがある場所を確認してください。この EAR ファイルは、IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile をインストールしたインストール・ツリー内にあります。例えば、このフィーチャー・パックを以下の場所にインストールしたとします。

プラットフォーム 場所
Linux および UNIX の場合: /opt/WebSphere/AppServer
z/OS マウント・ポイント: <install_root>
Windows: c:\WebSphere\AppServer

この場合、EAR ファイルは次の場所にあります。

プラットフォーム 場所
Linux および 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

管理コンソールを使用した File Uploader サンプル・アプリケーションのインストール

  1. アプリケーション・サーバーの管理コンソールにログインします。
  2. 「アプリケーション」>「新規アプリケーション」とナビゲートします (注: WebSphere Application Server バージョン 6.1 では、「新規アプリケーションのインストール」を選択します)。
  3. 新規エンタープライズ・アプリケーション (New Enterprise Application)」を選択します。(注: WebSphere Application Server バージョン 6.1 では、このステップをスキップします。)
  4. ファイル・システムを参照し、前に場所を確認しておいた appsvcs-graphics.ear ファイルを選択します。「次へ」をクリックします。
  5. 次へ」をクリックして、アプリケーションのインストール準備をします。(注: WebSphere Application Server バージョン 6.1 では、このステップをスキップします。)
  6. 次へ」をクリックして、デフォルトのインストール・オプションを受け入れます。
  7. 次へ」をクリックして、モジュールからサーバーへのマップに関するデフォルト・オプションを受け入れます。
  8. 次へ」をクリックして、モジュールのメタデータに関するデフォルト・オプションを受け入れます (注: WebSphere Application Server バージョン 6.1 および 7 では、このステップをスキップします)。
  9. 次へ」をクリックして、Web モジュール用の仮想ホストのマップに関するデフォルト・オプションを受け入れます。
  10. インストール・オプションの要約を確認します。
  11. 完了」をクリックします。
  12. マスター構成に保存」をクリックします。
  13. 「アプリケーション」>「アプリケーション・タイプ」>「WebSphere エンタープライズ・アプリケーション」とナビゲートします (注: WebSphere Application Server バージョン 6.1 では、「アプリケーション」>「エンタープライズ・アプリケーション」とナビゲートします)。
  14. IBM WebSphere Application Server - File Uploader サンプル・アプリケーション」を選択し、「開始」をクリックします。

インストールされたアプリケーション・デモ・クライアントへのアクセス

アプリケーション・サーバー・インストール http://<application server hostname>:<port>/appsvcs-fileuploader/ を Web ブラウザーで参照してください。

アプリケーション・サーバーのホスト名とポート番号は、アプリケーション・サーバー・インストールに固有のものです。アプリケーション・サーバー・インストール の Web コンテナーのデフォルト・ポートは 9080 です。アプリケーション・サーバー・インストールと同じワークステーションで Web ブラウザーを 実行していて、すべてデフォルト値を使用している場合は、URL: http://localhost:9080/appsvcs-fileuploader/ を使用してください。

WebSphere Application Server Community Edition バージョン 2.X インストール手順

このセクションでは、バージョン 2.X の IBM WebSphere Application Server Community Edition に File Uploader サンプル・アプリケーションをインストールする手順を説明します。ここでは、アプリケーションのインストールとアプリケーション・サーバーの管理についての知識があることを前提としています。

始める前に

製品インストールと共に提供される File Uploader サンプル・アプリケーション・エンタープライズ・アーカイブ (EAR) ファイルがある場所を確認してください。この EAR ファイルは、IBM WebSphere Application Server Feature Pack for Web 2.0 and Mobile をインストールしたインストール・ツリー内にあります。例えば、このフィーチャー・パックを以下の場所にインストールしたとします。

プラットフォーム 場所
Linux および UNIX の場合: /opt/WebSphere/AppServerCommunityEdition
Windows: c:\WebSphere\AppServerCommunityEdition

この場合、EAR ファイルおよびライブラリー・ファイルは次の場所にあります。

プラットフォーム 場所
Linux および 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

管理コンソールを使用したインストール

アプリケーション・サーバーの管理コンソールにログインします。

  1. 左側のメニューで「アプリケーション」>「デプロイヤー」をクリックします (注: WebSphere Application Server Community Edition バージョン 2.0 では、「アプリケーション」>「新規デプロイ」をクリックします)。
  2. アーカイブ」フィールドで、ファイル・システムを参照し、前に場所を確認しておいた appsvcs-fileuploader.ear ファイルを選択します。「プラン」フィールドをブランクのままにし、デフォルト・オプションが選択されたままにします。次に、「インストール」をクリックします。

アプリケーションが自動的に開始し、インストールが実行されます。

インストールされたアプリケーション・デモ・クライアントへのアクセス

アプリケーション・サーバー・インストール http://<application server hostname>:<port>/appsvcs-fileuploader/ を Web ブラウザーで参照してください。

アプリケーション・サーバーのホスト名とポートは、アプリケーション・サーバー・インストールに固有のものです。WebSphere Application Server Community Edition サーバー・インストール の Web コンテナーのデフォルト・ポートは 8080 です。アプリケーション・サーバー・インストール と同じワークステーションでブラウザーを実行していて、すべてのデフォルト値を受け入れた場合は、次の URL を使用してください。

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