カテゴリー: lifehack

– close() するのは PreparedStatement#close() でなく ResultSet#close() でもなく、絶対に Connection でなければならない。
– ログ情報には PreparedStatement#toString() がよさげ(少なくとも com.mysql.jdbc では)。
理由は、ログのための利便性から。SQLException がどのクエリでエラーになったかを残してくれないので、 PreparedStatement インスタンスがクエリ周りの情報をきっちり保持してくれていれば、toString() でログにどのクエリ文を実行したかが残せる。しかし、PreparedStatement#close() は DB 接続を閉じる仕様とは限らないため、Connection#close() を呼ぶ必要がある。PreparedStatement#close() だけにしたらプールがあふれ、思わぬ場所で DB 接続が開くのをずっと待ち続けることになってしまった。
– 例:

boolean isExist(int id){
    PreparedStatement ps = null;
    try{
        final Connection con = getConnection();
        try{
            ps = con.prepareStatement(“SELECT id FROM list WHERE id = ? LIMIT 1”);
            ps.setInt(1, id);
            return ps.executeQuery().next();
        }finally{
            con.close();
        }
    }catch(SQLException e){
        log(“Query error [“+ps+”]”, e); // void log(String, Throwable); とする
        return false;
    }
}

– 基本は通常のクラスと同じだが、条件として javax.servlet.http.HttpServletを親クラスとする必要がある。
– protected void do*(HttpServletRequest, HttpServletResponse)
doGet, doPost, doDelete, doHead, doOptions, doPut, doTrace があり、それぞれ対応するリクエストのときに呼び出される。
– protected void service(HttpServletRequest arg0, HttpServletResponse arg1) throws ServletException, IOException
別のオーバーロードされた service メソッドから処理を受け、配分するのが役目なので protected。
parent.service(req,res) を呼び出した時点で do*(req,res) の処理が行われるので、その前後の共通動作を定義するのに便利。
– 日本語(マルチバイト文字)を引数にとる
— getParametervalues,getParameterを使い、化けた状態の文字を取得したあと

new String(string.getBytes(“ISO_8859_1”), “Shift_JIS”);

のようにする。(HTTPプロトコルの文字コードが ISO-8859-1 のため)
— HttpServletRequestクラスのsetCharacterEncodingで、パラメータを取得する前にエンコードを指定しておく。
— HttpServletRequest#setCharacterEncoding(String enc) の挙動の違いの問題に注意！
Tomcat 4.1.29 以降の 4.1.*/5.0.16以降の 5.0.*、では、Getメソッドではエンコードされなくなった。GETの引数はURIに含まれるので、URIはエンコードされるべきではないという見解による仕様変更とのこと。
– スレッドセーフということ。
サーバサイドでは１つのインスタンスを使いまわしてマルチスレッドで動作するので、スレッド同士の不要な干渉をなくさなければならない。
“staticではない”フィールド(インスタンス変数)もスレッド間では共有されている事に注意！
–> ページ閲覧者固有の変数を持ちたい場合、メソッド内で定義した変数を使わなければならない。
データアクセスなど同期を取らないといけない場合は、(デッドロックにくれぐれも注意しつつ)適宜 synchronized にする。

– 正しく出力されるので害はないものの、毎回警告がでていたので調べてみた。警告内容は次の通り。

javadoc: 警告 – パッケージ “x.y.z” に複数のパッケージコメントのソースが検出されました。

英語だと以下。

Multiple sources of package comments found for package “x.y.z”

Java Forums <http://forum.java.sun.com/thread.jspa?threadID=599721&tstart=0> にずばり回答が。

Yep. The Doclet interface of the Doclet API specifies a method
 
void setRawCommentText(String text)
 
prior to 1.5 this method did exactly what its name implies. With 1.5 the implementation was changed to generate a warning and do nothing if it was attempted to set the comment text multiple times.
What happens is this:
Javadoc sees the package.html files in the sources, creates an appropriate Doc (PackageDoc) instance and sets the comment text. Then for some reason Javadoc encounters package.html files for already existing Doc instances and tries to set the comment text a second (third, fourth, …) time.
So, all you need to do is to ensure that Javadoc parses the package.html file for a given package only once, i.e. ensure that only sourcepath points to the package.html files but not classpath.

1.5 から package.html が複数見付かった時に上書きしつつ、警告を出すようになったとのこと。
ここで例にあるとおり、 javadoc のオプションで、 sourcepath でパッケージのある場所を示しつつ、なおかつ classpath でも示していたのが原因だった。Eclipse ではリリースディレクトリにも package.html をコピーしてくれていて、結局それが source のものと重複してしまった。
 
そもそも不要な、classpath からリリースディレクトリ(bin)の指定を外して解決。