JavaアプレットからJakarta Commons HttpClientを使用して
ファイルをアップロードするプログラムを開発しています。
-自作アプレットのjarにはデジタル署名
-Jakarta Commonsのjarはダウンロードしたままのもの
これらをサーバに配置しました。
ところが、ブラウザからこのアプレットでファイルを
アップロードしようとすると、Javaコンソールに
Exception in thread "Thread-6" java.lang.ExceptionInInitializerError
at org.apache.commons.httpclient.HttpClient.<clinit>(HttpClient.java:65)
略
Caused by: java.security.AccessControlException: access denied (java.util.PropertyPermission org.apache.commons.logging.LogFactory.HashtableImpl read)
at java.security.AccessControlContext.checkPermission(Unknown Source)
略
こんな感じの例外が出てしまいます。Eclipseからデバッグ実行していたときはこの例外は出てませんでした。
例外になったのは
HttpClient http = new HttpClient();
の部分です。アップロードの一番最初のところです。
どうにかなりませんでしょうか。よろしくお願いいたします。JDKは1.5です。
https://issues.apache.org/jira/browse/LOGGING-106
https://issues.apache.org/jira/browse/LOGGING-107
で報告されているバグで、Fix Version が"1.1.1"になっています。
現時点で、http://commons.apache.org/logging/ を見ると 1.1.1 は2007年10月のリリースが宣言されていますが、まだそれはダウンロードできません。
LOGGING-106 の右下隅に、このバグで変更されたファイルへのリンク↓
http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trun...
があります。
現時点では、このパッチを LogFactory.java にあてて、ソースからjarをビルドするしかないでしょう。
1.1.1がリリースされるまで待つ時間が残されているなら、それまでは該当のjarファイルにシステムプロパティを読ませる権限を与えて、しのいでもいいんじゃないでしょうか?
Appletは通常のJavaアプリケーションと違い色々な制限があります。
HttpClientはコンストラクタの中で System.getProperty を使ってシステムプロパティを読もうとしますが、Appletでは許可されない操作なので PropertyPermission が投げられています。
なのでどうしてもAppletからHTTP通信がしたいならHttpClientを諦めて、自力実装またはその他のライブラリまたはURLリソースを使うなどを検討された方がよいと思います。
また、そもそもAppletではそのAppletが設置されているホスト以外の外部サイトへの通信も許可されませんが、やりたいことは外部サイトとの通信でしょうか?
もしそうでしたらHttpClientの代りを自前で実装したとしても外部との通信は行えないので Applet で実現しようとすることを諦めた方が賢明かと思います。
例えば Flash なら相手サイトの crossdomain.xml で許可されていればクロスドメインな通信も可能です。
回答ありがとうございます。
ダメなんですか...。
http://www.oklab.org/diary/?date=20070512
ここ見て、アプレットでも大丈夫なようにも読み取れたのでやってたんですが。
プロパティを読ませない方法とかは無いですか?
ホントに自力で実装するしか無いんでしょうか。
ちなみにクロスドメインではないのでそこは大丈夫です。
とりあえずもう少し回答を募集してみます。
http://www.oklab.org/diary/?date=20070512
上のコメントのサイトに HttpClient を使わずに自前実装(フルスクラッチ版)のソースコードがありますね。
これを参考にすればファイルのアップロードをしたいという要件は満たせるのではないでしょうか?
そうですね。一応それは最後の手段だと思っています。
今回の件は、もし解決可能なのであればおそらく設定だけでの話だと思っていましたので、
まずはその線から調べている状況です。
無理なら諦めて自力で実装するつもりです。ありがとうございます。
HttpClientは内部で、
org.apache.commons.logging
を使っているので、このライブラリについて調べるべき。
直感では、HttpClientをnewするまえに、commons.loggingの設定らしきものを
しておいてあげれば、ローカルのリソースに読みに行かないと思います。
ずばりそこが知りたいんです。
Jakarta Commons Loggingがローカルアクセスをしなくなる設定またはコーディング方法を。
よろしくお願いいたします。
https://issues.apache.org/jira/browse/LOGGING-106
https://issues.apache.org/jira/browse/LOGGING-107
で報告されているバグで、Fix Version が"1.1.1"になっています。
現時点で、http://commons.apache.org/logging/ を見ると 1.1.1 は2007年10月のリリースが宣言されていますが、まだそれはダウンロードできません。
LOGGING-106 の右下隅に、このバグで変更されたファイルへのリンク↓
http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trun...
があります。
現時点では、このパッチを LogFactory.java にあてて、ソースからjarをビルドするしかないでしょう。
1.1.1がリリースされるまで待つ時間が残されているなら、それまでは該当のjarファイルにシステムプロパティを読ませる権限を与えて、しのいでもいいんじゃないでしょうか?
これは新情報!ダメっていうのはバグだったわけですね。
逆に言うと、設定でどうにかなる仕様ではなかったという。
10月中に新バージョンが出るのであれば、ギリギリ待てます。
ただ自力実装で行けるかどうかの調査くらいはしておいた方が良さそうですね。
ところで
> それまでは該当のjarファイルにシステムプロパティを読ませる権限を与えて
これはどうやるのでしょうか?commons-logging-1.1.jarに私のデジタル署名を施すということですか?
> それまでは該当のjarファイルにシステムプロパティを読ませる権限を与えて
..\jre\lib\security\java.policy
に、
grant codeBase "http://hogehoge/fuga/commons-logging-1.1.jar" { permission java.util.PropertyPermission "*", "read"; };
の記述をjarファイルの数分書くか、一つのフォルダに集めて、
grant codeBase "http://hogehoge/fuga/commons-logging-jars/*" { permission java.util.PropertyPermission "*", "read"; };
と書くとかですね。
資料はこの辺で。
http://www.nextindex.net/java/security/policy.html
http://sdc.sun.co.jp/java/docs/j2se/1.4/ja/docs/ja/guide/securit...
http://sdc.sun.co.jp/java/docs/j2se/1.4/ja/docs/ja/guide/securit...
すみません。このやり方では何もかわりませんでした。
たぶん私のやり方がダメなんだと思います。
でも、自分でビルドしたcommons-logging-1.1.1.jarを使うことで
この件は解決したので、あとは公式に1.1.1が出るのを待つことにします。
もしこっちの期日(11月上旬)までにリリースされなかったら、
このまま私ビルドの1.1.1を使うことにします。
これは新情報!ダメっていうのはバグだったわけですね。
逆に言うと、設定でどうにかなる仕様ではなかったという。
10月中に新バージョンが出るのであれば、ギリギリ待てます。
ただ自力実装で行けるかどうかの調査くらいはしておいた方が良さそうですね。
ところで
> それまでは該当のjarファイルにシステムプロパティを読ませる権限を与えて
これはどうやるのでしょうか?commons-logging-1.1.jarに私のデジタル署名を施すということですか?