- PR -

JavaWebStartの配布ファイルのサイズ制限について

«前のページへ 1|2
投稿者投稿内容
taro
ぬし
会議室デビュー日: 2003/10/20
投稿数: 316
投稿日時: 2004-03-06 15:01
ねこばばさん、こんにちは。
かずくんさんのおっしゃってる
＞Class.getResource()でリソースを読み込む場合、
というのは、ねこばばさんの提示されたコードの以下の部分のことですので、
リソース（画像ファイル）のjar内での配置場所とクラスファイルが読みに行く
パスとのくいちがいについておっしゃっているのではないでしょうか？
コード:

ImgChipData = Toolkit.getDefaultToolkit().getImage( this.getClass().getResource

( "IMAGE/img.gif" );

ちなみに、エラーとなったjarファイルを解凍するとどうなりますか？

# 改行を入れるよう編集

[ メッセージ編集済み 編集者: taro 編集日時 2004-03-06 15:02 ]
かずくん
ぬし
会議室デビュー日: 2003/01/08
投稿数: 759
お住まい・勤務地: 太陽系第三惑星
投稿日時: 2004-03-06 16:21
taroさん、補足説明ありがとうございます。

と、これだけでは何なので.....
特定のクラス、または特定のパッケージの属するクラスから画像などのリソースファイルを読みこむ場合は、
そのパッケージ下にリソースファイルを配置し、Class#getResource()を使用します。
この場合、パッケージ名＋リソースパスを検索しに行きます。ただし、リソースパスの先頭が"/"で始まる場合は、パッケージ名を付与しなかったはずです。

具体的には、

  • root

    • package_A/

      • Class_A
      • images/

    • package_B/

      • Class_B



というクラス階層になっていた場合、
コード:
Class_A.class.getResource("images/...")

で、imagesディレクトリ下のリソースを読みこむことはできますが、
コード:
Class_B.class.getResource("images/...")

の場合、images下のリソースファイルを読みこむことはできません。

一方、アプリケーション全体や、複数のパッケージからアクセスするようなリソースの場合、ClassLoader#getResource()を使用します。この場合、指定したリソースパスそのものを検索しに行きます。この挙動は、Class#getResource()において、先頭に"/"を付与してリソースパスを指定した場合と同じです。

この２つのgetResource()の使い分けは、リソースファイルの置かれる立場（特定のクラスからのみ or アプリケーション全体からアクセス）で使い分けます。

本題に戻って、
今回のケースでは、開発時とリリース時とで、指定したクラスとリソースファイルとの相対位置が異なってはいないでしょうか？
異なる場合、上述のClass_Bのケースで示したようにリソースファイルを読むことができなくなります。
ねこばば
会議室デビュー日: 2004/01/19
投稿数: 8
投稿日時: 2004-03-08 00:12
ディレクトリ構成はこんな感じです。
aaa/bbb/ccc/SampleJnlp.class　←画像ファイルを読みこむクラス
IMAGE/img.gif ←画像ファイル
META-INF/MANIFEST.MF
META-INF/MYSELF.DSA
META-INF/MYSELF.SF
init/init.inf
※画像ファイルは一部のクラスしか必要としないのですが、管理しやすいように
ルートから別ディレクトリ上においてあります。

↓以下の方法でうまくいきました。
ImgChipData = tk.getImage( getClass().getClassLoader().getResource( "IMAGE/img.gif" );

↓以下の方法で試みると、個人フォルダ配下のディレクトリ上を参照してました。
ImgChipData = tk.getImage( getClass().getResource( "IMAGE/img.gif" );
おそらくWebStartのログ出力先がここだった為だと思います。
当然、セキュリティにも引っかかりますので警告ダイアログが表示されます。

★localhostで試すと簡単にうまくいきました。700K強のサイズでも。（笑）
画像ファイルがこわれているとか、セキュリティ権限が問題とか憶測が飛びましたが、
原因はすべて通信上のトラブルだと思います。

みなさん、ありがとうございましたといいたいところですが、解決できていないので、
WebStartではネットワーク通信上で問題が多々あるということでしょうか？
この解決方法があれば教えてくださいませ。

WebStartって、ファイルが完全にDL出来た事を確認してから、
処理を進めるように設計されていないのかなぁ。
シュン
ぬし
会議室デビュー日: 2004/01/06
投稿数: 328
お住まい・勤務地: 東京都
投稿日時: 2004-03-10 17:12
もしかしすると、WebStartの問題というよりは、ToolKit#getImage()が非同期処理(画像のロード完了を待たない)という仕様になっているせいではないでしょうか？
このような場合、MediaTrackerで画像のロード完了をきちんと待つのが、セオリーになっているようですよ。
ねこばば
会議室デビュー日: 2004/01/19
投稿数: 8
投稿日時: 2004-03-10 19:51
ご返信ありがとうございます。

試してみましたが、だめでした。
というのも、WebStartがダウンロード処理を行っている段階で、
エラーが帰ってきますので、javaVMがmainメソッドを呼び出す以前の段階で
問題がおきているのです。
DL→認証→実行→終了のどのプロセスにおいても処理完了を確認してから、
次のプロセスに移るように制御しないと実用化は難しいと思うのですが、
商用化した事がある方々はこの問題をどう対処しているのでしょうか？
ねこばば
会議室デビュー日: 2004/01/19
投稿数: 8
投稿日時: 2004-03-12 00:39
解決しましたのお知らせ。

WebStartの配布ファイルの制限サイズは正確には調べてませんが、
クラスファイルやリソースファイルを１ファイルずつjarファイル化して
試みたらうまくいきました。
あるサイトを見たら、各種のツールをjar毎に分けて配布していて、
全ファイルの合計サイズもそこそこ大きかったので「もしや？！」と思い、
試してみたらビンゴでした。

これで、好きなプログラムをいつでもどこでもDLして使えそうです。
アプレットも同じような問題を抱えていたのですが、Jarファイルに小さく分けて
配布したらうまく言ってたのかもと思うと、どこかしらHelpにでも載せて欲しかった
と正直思いました。

今まで投稿してくだっさた方々に心からお礼を申し上げます。
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）