[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[jfriends-ml 10870] Re: 読書会 (More Java Pitfalls) 第 6 回議事録



村山@netgeneです.

>   →JSPからincludeやforwardしている場合にこの問題が発生する可能性あり。
>   
>   この後の話題はついてゆけなかったです。ごめんなさい。
少しフォローしときます.
#どんな話題だったか忘れちゃいましたが,

JSPは,デフォルトで多分javax.servlet.jsp.JspWriterを出力に使います.
これが名前でも分かるとおりjava.io.Writerのサブクラスなんですね.

たとえば「ServletからJSPへのフォワード」などは,要するにdelegation
(処理する権限/責任の委譲)でしかないので,同じレスポンスに続けて出力
することには変わりありません.

Servletでjavax.servlet.ServletOutputStreamを使って出力した後にJSPに
forwardし,JSPでJspWriterに出力しようとすると,おそらくはここで挙げられ
ている理由によりエラーが発生します.

なまじJSPを書く人とServletを書く人が別れてたりすると,このエラーの原因が
全く掴めずに苦労するはめになるかも知れません.

私ならJSPとServletを連携する時は,出力はすべてJSPに任せることをお勧め
します.そうでなくても制御ロジックが分散してデバッグが大変なのと,なに
より文字化けが怖いので.

>  ・setRedirectとforwardの違いは?
>    →setRedirectはクライアントにリダイレクトするようなレスポンスを返す。
>      forwardは別のServletに委譲する。
#forwardとincludeというのは,Servlet/JSPプログラミングで頻繁に使われる
#基本機能.sendRidirect()はどちらかというとHTTPの機能で,sendRidirect()は
HTTPの特定のプロトコル(?)を呼び出すために用意されたメソッド.

>  ・WebブラウザのJavaScriptでフォーム情報の改竄を防ぐ方法はないのか?
>    →ないとおもわれる
フォームの入力情報自体は突き詰めれば自己申告に過ぎず,内容は自由に
「捏造」できるので,基本的に全く信用できないと考えるべきものだと
思います.

>  サーブレットのインスタンス変数を使用する危険について
>  ・スレッドのバグはかなり厄介
並列プログラミングの参考書としては,たしか元bit別冊の次の本が
それなりに良くできていたと記憶してます.

「はじめての並列プログラミング」湯浅 太一 (編).3800円,共立出版
http://www.amazon.co.jp/exec/obidos/ASIN/4320029402/250-7162296-2589010

が,なんせ読んだのが何年も前の話だし,当時並列プログラミングが専門
だっただけに8割方知ってることばかりだったので,逆に内容は良く覚えて
ません.現在注文中で,二,三日中には届くでしょうから,内容を確認して
からまたE-mailを投げるつもりです.

>  ・Webシステムに関するセキュリティの問題をまとめたもの(標準)はなにかないのか?
>    →ごめんなさい。探したのだけれど見つけられませんでした。
こんなページ見つけました.
http://www.ipa.go.jp/security/awareness/vendor/programming/

内容はほとんど見てませんが,雰囲気だけなら悪くなさそう.
もしこれに「落とし穴」があれば,バグレポートをを返してあげるべき
かもしれませんね.
#良くある「落とし穴」である「クロスサイトスクリプティング」で検索
#かけて見つけました.これが「バッファオーバーフロー」だと,MSBlasterの
#記事とかだけでもウジャウジャ出てくるので,見つけるのが難しくなる.

>  ・init()じゃなくてdoGet()でSingletonを呼びだしてもよいのではないか?
>    →そんなことはない。シングルトンの生成は同期メソッドだから呼出しは少ないほうがよい。
>  ・駄目なシングルトン:オブジェクトがなければオブジェクトを作るというのが問題。
>    →この場合遅延インスタンシエーションではなくて、直接フィールドで生成したほうがよいの
この辺は二つの問題が絡んでいます.

1,遅延生成を使っている場合,synchronizedは不可避になる.となると
   doGet()で呼び出すのは致命的なボトルネックになる可能性が高い.
   だからinit()で呼び出すべきである.
#いわゆる「double checkedイディオム」は既に否定されている.
#これの詳細は例のdeveloperWorksの定番記事参照.

2,しかし,そもそも遅延生成を使う必要がないのだから,素直にクラスの
   ロード時に生成しておいた方が良いだろう.そうなると同期も不要になる
   から,doGet()メソッドで呼び出してもボトルネックにはならない.
   それでもdoGet()よりはinit()で呼んだ方が,より良い設計になる.

1でも2でも,「init()で呼ぶべき」という結論は同じなんですが,
その理由が異なるわけです.

>  ・Listing 36.3 のコードは動作しないのでは? countがstatic変数はまずい。
Servletなのでstatic変数でもインスタンス変数でも駄目です.
#Item31で示した落とし穴をItem36で繰り返してるのは何故?(^^;
#ひょっとして書いてる人が違ってて,Item36の作者はItem31の
#落とし穴を知らないとか?