前回のエントリ、直列化したデータをDBに突っ込むの続き。DBに保存したら、読み出す方法が分からないとダメだわな。ごめんなさい。

Object object = null;
InputStream in;
ObjectInputStream ois;

        
if (resultSet.next()) {
    // バイナリデータを読み出して復元
    in = resultSet.getBinaryStream("analyze_data");
    ois = new ObjectInputStream(in);
    object = ois.readObject();
}

あとは、この object を直列化する元のクラスにキャストしてあげれば、いつものように使い回せるはず。便利、便利。

シリアライズしたオブジェクトは、DBのバイナリデータ型のカラムに登録することができる。生成にコストがかかって、かつセッションに保持するとメモリを食い潰しそうなオブジェクトの保存方法のひとつとして、この手段を検討したい。

Connection conn = null;
PreparedStatement ps = null;


// 指定オブジェクトを直列化
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream out = new ObjectOutputStream(baos);
out.writeObject((Serializable) contents);
int buffer = baos.size();


// DBへの書き出し用ストリームの作成
InputStream in = new ByteArrayInputStream(baos.toByteArray());


// 直列化したオブジェクトを InputStream に書出
baos.flush();


try {
    String sql = "INSERT INTO table(contents) VALUES (?)";
    conn = getConnection();
    ps = conn.parepareStatement(sql);
    ps.setBinaryStream(1, in, buffer);
    ps.executeUpdate
} catch (Exception e) {
    e.printStackTrace();
} finally {
    if (ps != null)
        ps.close();
    if (conn != null)
        conn.close();
}

サンプルとしてざっくり書いてみたけど、こんな感じで大丈夫のはず。とりあえずメモなんで、動かしてないです。間違いあったら、すんません。

ちなみに、ByteArrayOutputStream の close には意味が無いらしい。転送先にデータを書き出すためには、明示的に flush する必要があるとのこと。標準APIのjavadocに書いてあったので、多分そうなんだと思います。(おいおい)

J2SE 5.0 から StringBuilder クラスが導入された。

このクラスは、ほとんどの実装で高速に実行されるので、可能な場合は、StringBuffer よりも優先して使用することをお勧めします。

ということで、実際のところどんなもんか試してみた。

続きを読む "StringBuffer 対 StringBuilder"

eclipse3.2 + EclipseHTMLEditor2.0.2 の組み合わせで JSTL1.1 を使用すると、「"c"に対応するtaglibディレクティブが存在しないかTLDファイルが見つかりません。」と怒られて、エディターが真っ赤に染まってしまう。

実際にアプリケーションを動作させることは可能なので、単にエディタが URI から TLDファイルを解決できないんだろう。でも、設定を見る限りは、URI も定義されていて大丈夫っぽいんだけどなー。

JSTLタグの補完機能が使えないのは痛いので、解決法が見つかるまでは、3.1にダウングレードして開発することに。何か情報をお持ちの方は、ご一報くださいまし。

遅ればせながら、ようやくeclipse3.2を導入した。

しかし、エディタでJSPファイルを開いたら、とんでもなく文字化けしていらっしゃる。なんだこれは。3.1まではこんなことなかったのに。そこでファイルのプロパティを見てみると、文字コード設定が「ISO-8859-1」になっているではないか。

エクリプス氏曰く、「デフォルト(内容から判別する: ISO-8859-1)」だと。

いやいや、内容から判別できていないから。こっちはMS932で書いているんだよ、遊びじゃないんだよ、本気と書いてマジなんだよ。なんだそれ。

ファイルごとにプロパティを開いて正しいエンコードを設定するのもだるいので、どうにか一括して設定できないかと思って探索したら、見つけました。

[ウィンドウ]＞[設定]＞[一般]＞[コンテンツ・タイプ] で、ファイルタイプごとにデフォルト・エンコードの設定を行える仕様だった。うげー、分かりづらいッス。

ただし、プロジェクトごとに設定したりはできないんで、文字コードの異なるプロジェクトが並行して走っているときは、面倒くさい。.settingファイルを直接イジったりすれば、いけるのかな？

つーか、プロジェクトごとに文字コードが異なるってのが、ダメだろ。ううう。

「リソースファイルを WEB-INF/classes 以外の場所に配置できないもんか」の続き。

クラスローダーから見えない properties ファイルは参照できないんだなー、残念だなー、今日の雨は秋の訪れを予感させるなー、おでん食べたいなー、とか思っていたのだけど、実は相対パスで上の階層まで見れることが判明！

ClassLoader loader;
InputStream inputStream = null;


String path = "../../hoge/test.properties";
Properties properties = new Properties();


try {
    loader = Thread.currentThread().getContextClassLoader();
    inputStream = new BufferedInputStream(loader.getResourceAsStream(path));
    properties.load(inputStream);
} catch (IOException e) {
    e.printStackTrace();
} finally {
    if (inputStream != null) {
        try {
            inputStream.close();
        } catch (Exception e) {
            //
        }
    }
}

こんなことができるとは知らなんだ。頭は柔軟じゃないとダメっすね。

Tomcat5.0 クラスローダの手引き

properties ファイルを WEB-INF/classes 以外の場所に配置できないものかと調査中。結局、クラスローダーが見えないところには置けないっぽい。リポジトリのチェック順序とか見て、結構ガッカリ。

コアな話なので、また時間のあるときに調べてみよう。

DBUnit のように DB 操作を行うユニットテストを実施する際、そこで使うコネクションをどう取ろうかという話。

バッチ処理のような単体プログラムであれば、単純に JDBC のコネクションを自前で生成すれば良いんだろうけど、Webアプリケーションのなかで、DB操作を行うメソッドを間接的に利用するクラスをテストしようとすると、ちと面倒なことになる。わざわざテスト用コネクションを受けるインタフェースと実装を用意しなくちゃなんない。うざー。

そこで考えてみる。

実際のアプリケーションは、tomcat などのコンテナの JNDI を使ってコネクションを張るわけで。じゃあ、ユニットテストケースからも tomcat が見えて、JNDI を使えれば良いんじゃないか、と。そんなことできるのか、と。ツールとか無いのか、と。あったよ、と。

JUnit JNDI DataSource helper package

こいつを使うことで、コンテナ上で動くのと同様に、DB操作するクラスのユニットテストができます。素晴らしい。結構、感動した。

以下、簡単な使い方のまとめ。

続きを読む "JNDI を使用したユニットテストの方法"

「例外をスローする」

そんなことを偉そうに語ってきたけれども、にわかにスローについて何も知らない自分がいることに気付き、愕然とした。一体それは、オーバースローなのか、サイドスローなのか、はたまたアンダースローなのか。

個人的にはサイドスローっぽいイメージです。本当にどうでもいい。

NetBeansで、本日2回目の大ハマリ。

NetBeans5.0にバンドルされているTomcat5.5.9をそのまま使用中。んで、tomcat-users.xmlとかを書き換えたりしていたんだけど、一向に反映される気配がない。なぜ。正しく設定しているはずだし、おかしい。

半ばあきらめかけていたら、ユーザーディレクトリの下に、さりげなくNetBeansの影武者を発見。同様の設定ファイルが、こっちにもできている。それを修正したら、ちゃんと動いた。…お、お前かあ！

C:\Documents and Settings\%USER_NAME%\.netbeans\5.0
(%USER_NAME% はユーザー名)

どの段階でこういう配置になるのか分からないし、もしかしたら自分だけかもしれないけど、設定まわりで困ったら、こっちも参照しましょう、と。

やっぱりマニュアルちゃんと読まないとダメかなあ。ふう。

引き続き、NetBeansにハマリ中。今度は、文字コードがおかしいようで、コンパイルが通らない。

javaソースファイルの文字コード設定も、どこでやるか分かりにくくて大変だった。[ツール]→[オプション]→[詳細オプション]→[編集]→[Javaソース]→[デフォルトエンコーディング]という、限りなく深いところで設定しなければならない。口で説明しようとしたら噛むくらい深い。

で、これで文字コードの設定はOKかと思ったら、コンパイル時のエンコード指定は、また別。そりゃプロジェクトごとに指定できないと使えないんだけど、モヤっとする。

コンパイル時のエンコーディング設定は、[プロジェクトプロパティ]→[構築]→[コンパイル]の「追加のコンパイラオプション」で指定する。

-encoding EUC-JP

IDEだから人に優しいインタフェースを持っているんだろうと思っていたら、コマンドラインでの方法と同じ。思い込みはいけないですな。結構ハマった。ううう。

久しぶりにNetBeansで遊ぼうと思ったら、CVSからのチェックアウトプロジェクトの作り方を忘れていて、スゴク焦る。

Eclipseと同じように、[新規プロジェクト] から作れる気になっていたのだけど、間違い。正しくは、上部メニューから、[CVS]→[チェックアウト] で、一度ソースをチェックアウトしなくちゃいけない。それから、そのソースを用いてプロジェクトを作成するという、めんどい手順を踏む必要がある。

ヘルプにそれっぽいことが書いてあったけど、分かりづらい。ヘルプが本当にヘルプになる場合って、まれだよなあ。ほとんどは、ヘルプの内容を検索して調べている気がする。もういっそ google がヘルプってことじゃダメだろうか。ダメだな。

Jakarta Commons Collectionsライブラリを使えば、コレクションの要素に関するさまざまな処理を、サクっと実装することができる。便利な世の中になったもんで。

たとえば、コレクションの各要素に特定の処理を行うには、forAllDo メソッドが使える。

CollectionUtils.forAllDo(list, new Closure() {
	public void execute(Object input) {
		// 要素に対する処理
		Hoge hoge = (Hoge) input;
		hoge.doSomething();
	}
});

他にも、filter とか select といった、かゆいところに手が届くメソッドが数多く用意されている。覚えておくと、プログラミングの戦術が増やせるかもしれない。

ただ、この程度の処理ならば、自前で Iterator を使って書いても早いし、見通しも良くなると思う。そんなわけで、今まで一回も使ったことありません。結局、かゆいところは、自分でかく。寂くて弱い男です。ううう。

続きを読む "コレクションの各要素に特定の処理を行う"

javascript でも JSP 同様にカスタムタグが使えたら、かなり柔軟なことができるだろうなーと思って試したら、できた。js ファイルを JSP と見なすように設定すれば良いだけの話。

web.xml の jsp-config を以下のように指定すれば、OK。

<jsp-config>
  <jsp-property-group>
    <url-pattern>*.jsp</url-pattern>
    <el-ignored>false</el-ignored>
    <page-encoding>MS932</page-encoding>
    <scripting-invalid>false</scripting-invalid>
  </jsp-property-group>
  <jsp-property-group>
    <url-pattern>*.js</url-pattern>
    <el-ignored>false</el-ignored>
    <page-encoding>MS932</page-encoding>
    <scripting-invalid>false</scripting-invalid>
  </jsp-property-group>
</jsp-config>

ただし、jsファイルもJSP同様にバイトコード化されて実行されるので、負荷は上がる。そして、外部 js ファイルの読み出しだと、request スコープが変わるため、値の取り出しには工夫が必要。ということで、あまりオススメしません。何だそれ。

こんなことするんだったら、カスタムタグを使いたい javascript 関数をまとめた javascript.jsp みたいなのを作って、それを import する方が、賢い気がする。request スコープも同じだし。ああ、そうしよう。

と、ひとり納得して終わる。

またぞろ開発プロジェクトがスタート。過去のプロジェクトを引き継いでの開発なので、とりあえずCVSリポジトリにブランチを作るところから。

これまでCVSの操作は、linux にログインしてダイレクトに行っていた。でも、今回は実験もかねて、Eclipse からやってみようかと。ホントに Eclipse は、何でもできる。便利すぎて怖い。まんじゅう怖い。お茶も怖い。

なお、「CVSって何ですか？」とか「ブランチって何？」という人は、こちらのページが異様に詳しいので、のぞいて圧倒されてみると良いと思います。

以下、Eclipse によるブランチタグ生成のメモ。

続きを読む "Eclipseでブランチタグを作成する"