STBBS.NET blog

Springと一緒に Wicketを使う

2008-07-19T01:21:00.006+09:00

我が社は主に Flexと BlazeDSを用いた RIAに注力している。このプラットフォームを用いる場合、サーバ側ではほぼ純粋にビジネスロジックを提供するだけで良いため典型的なMVCタイプの Webアプリケーションよりもさらに分業が容易であるという利点がある。

しかしながら、常にユーザの環境が RIAに適しているとは限らないし、「文書を読ませる」機能に関して言えばそれを Flash Player上に実現した場合あまりユーザにとって快適とは言い難いものになる可能性が高い。

などの理由から、従来通りHTMLで表現される Webアプリケーションを実装する場合も少なからずあるため、近頃先進的な向きに人気の高い Wicketを調べてみた（むろん、同様の目的には Spring MVCや Struts2を使っても良いのだが）。

ここでは、既に Spring Frameworkが Webアプリケーションに導入されていることを前提に Wicketを動作させるために必要な最低限のセットアップを行う手順を示す。
なお、アプリケーションに BlazeDSが既に導入されている場合でも共存が可能であることを確認している。

WEB-INF/lib に設置した jarファイルは下記の通り。

wicket-1.3.4.jar
wicket-ioc-1.3.4.jar
wicket-spring-1.3.4.jar
wicket-spring-annot-1.3.4.jar
slf4j-api-1.5.0.jar
slf4j-jcl-1.5.0.jar

slf4jについては好きな実装を用いて良いと思うが、Springが前提であれば Commons Loggingが存在するはずなのでここでは slf4j-jclを用いている。

必要なライブラリを追加したら、web.xmlに Wicketの設定を追加する。Wicketはサーブレット又はサーブレットフィルタとして適用することが出来るが、後者が推奨されているようだ。


<filter>
  <filter-name>wicket</filter-name>
  <filter-class>
    org.apache.wicket.protocol.http.WicketFilter
  </filter-class>
  <init-param>
    <param-name>applicationFactoryClassName</param-name>
    <param-value>
      org.apache.wicket.spring.SpringWebApplicationFactory
    </param-value>
  </init-param>
</filter>

<filter-mapping>
  <filter-name>wicket</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

典型的な Wicketアプリケーションを構成する要素は、ひとつの WebApplicationクラスとページ数分の WebPageクラス（とそれぞれに対応するHTMLファイル）である。
applicationFactoryClassNameに SpringWebApplicationFactoryをセットすることで、Wicketは Springの applicationContext.xml内に定義されている Beanの中から WebApplicationのインスタンスを選び出して自動的に用いるようになる。
（そのため、ことSpringを用いる場合は web.xmlにWebApplicationの実装クラス名を直接書き込む必要がない）

この設定では、Webアプリケーションに対する全てのリクエストが Wicketのフィルタに一旦渡されるが、Wicketは自身の守備範囲でない URIへのリクエストをスルーするため、画像などのリソースや他のサーブレット（BlazeDSの通信エンドポイントもそうだ）に対するリクエストを妨害されることはないようだ。

さて、最小限の WebApplicationはこのような実装になる。


package net.stbbs.wicket;

import org.apache.wicket.spring.injection.annot.SpringComponentInjector;

public class WebApplication extends
    org.apache.wicket.protocol.http.WebApplication {

  @Override
  public void init()
  {
    super.init();
    this.addComponentInstantiationListener(new SpringComponentInjector(this));
  }
  
  @Override
  public Class getHomePage() {
    return HomePage.class;
  }

}

Springと統合するために、initメソッドに対し addComponentInstantiationListenerの呼び出しを追加している。これによって、WebPageクラスのインスタンスが生成される際にはアノテーションに従って自動的にフィールドインジェクションが行われるようになる。例えばこのように。


public class HomePage extends WebPage {
  @SpringBean(name="helloService")
  private HelloService helloService;
  :
  :

上記の例ではアノテーションのパラメータとして name を渡しているが、型の合致するBeanがアプリケーションコンテキスト内にひとつしか無い場合は省略しても良い。

WebPageオブジェクトのライフサイクルは Wicketの管理下にあり Springのそれとは一致しないが、WebPageオブジェクトにフィールドインジェクションされた Beanは実際には適切に自動生成されたプロキシであり、これによりライフサイクルの差異は吸収されるらしい。

インジェクションの対象となるフィールドには初期化の記述をしないように注意すること（例えば private HelloService helloService = null; のように）。インジェクタはフィールドの初期化処理よりも前に走るため、フィールドの初期化を記述するとそれで上書きされてしまうそうだ。

あとは Wicketの作法に従って WebPageクラスと HTMLファイルを必要なだけ作ることで UIを構築していけば良いだろう。

Windows XP Professionalをマルチユーザー仕様に改造する

2008-07-13T22:53:00.011+09:00

ここで紹介するハックはマイクロソフトのEULAに抵触する可能性が高いため、あくまで海外サイトから得た情報を参考までに紹介するに止めるうえ、上級者向けに必要最低限の内容のみ掲載する。情報を利用した結果ついて当方では一切の責任を負うことができないので、各自自己責任のもとで行って頂きたい。
（なおこのネタ自体は 2006年頃から存在するようだが、要点だけまとめた日本語の情報が他に見あたらなかった）

Windows XP Professionalはリモートデスクトップクライアントを用いることで離れた端末からネットワークを通じてログインし、利用できる。しかしながら、同時に利用することが可能なセッションはローカル・リモート合わせてひとつだけである。つまり、誰かがリモートからログインしようとするとその WinXP Proマシンを操作中のユーザはログアウトを迫られる。

複数のユーザが同時にログインしてオペレーティングシステムの機能を利用することは、UNIXやその派生OSでは当たり前に出来ることであるが、Windows（サーバ向け除く）はそのマーケティングにおける性質上、「技術的には出来るけど、出来ないようにしてある」といったところだと思われる。実は以前 Windows XP SP2でこの制限が緩和され同時に2セッションまで利用出来るようになるという噂が流れたのだが、これはガセネタだったようだ。

ここからが本題である。この制限は、termsrv.dll という DLLを3バイト書き換え、いくつかのレジストリ項目を登録し、グループポリシーを修正することで外すことが出来る。

termsrv.dllは Windowsフォルダ以下の system32, ServicePackFiles/i386, system32/dllcache にそれぞれ存在している可能性がある（環境によってそれぞれ存在してしていたりしなかったりするようだ）。そこにある全ての termsrv.dllに対し、下記のような書き換えを行う（全て同じ内容のはずなので、1個書き換えてコピーすれば良い）。

0x00022A17
0x74を、0x75に変更
0x00022A69-0x00022A6A
0x7F 0x16を、0x90 0x90に変更

もちろん Windows XP Professionalが通常起動した状態では、このDLLを書き換えることは出来ない。セーフモードをうまく使うか、一旦 Linuxでブートして書き換えるなどの方法があるだろう。ここでは詳しい説明を省くが、セーフモードを使う方法については下記サイトに含まれている。
Enable Multiple Concurrent Remote Desktop Connections or Sessions in Windows XP

DLLを書き換えたら Windows XP Professionalを通常起動し、レジストリに下記のような変更を加える。

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Terminal Server\Licensing Core]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]

に、それぞれ DWORD値 "EnableConcurrentSessions"を作成し 1にセットする。

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]

に、DWORD値 "AllowMultipleTSSessions" を作成し 1にセットする。
（これは環境によっては既にそうなっているかもしれない）

レジストリの書き換えが終わったら、「ファイル名を指定して実行」から gpedit.msc （グループポリシーエディタ）を起動し、「コンピュータの構成」→「管理用テンプレート」→「Windowsコンポーネント」→「ターミナルサービス」まで降りていき、「接続数を制限する」設定を「有効」にし、最大接続数を好きな値にセットする。
次にコントロールパネルから「ユーザーアカウント」→「ユーザのログオンやログオフの方法を変更する」へ降りていき、「ユーザーの簡易切り替えを使用する」をチェックする。

上記で作業はおおかた終了である。リモートデスクトップをまだオンにしていないならば、「システムのプロパティ」→「リモート」からリモートデスクトップを有効にする。これで PCを再起動すれば、Windows XP Professionalが複数ユーザー同時ログイン可能な状態で動作する。
なおコンピュータがドメインに参加している場合、書き換えたレジストリの内容が戻ってしまう問題があるらしい。

パスワードなしのアカウントで Windows XP Professionalにリモートデスクトップ接続する ( 推奨はしない )

おまけ

Linuxでバイナリファイルを書き換える時は bvi というプログラムが便利だ。操作は viに似ており、: で行番号のかわりにアドレスを16進入力して目的のオフセットへ飛べる。ファイルを開いた時はリードオンリーモードになっているが、:set mm コマンドで書き換えが可能なモードに切り替わるので後は x や i といったように viのような使い方で書き換えを行い、終わったら :wq で上書き終了すると良い。

Xenのハイパバイザ（完全仮想化）モードで運用しているバーチャルマシンの仮想ディスクに含まれているパーティションを Linuxでマウントしたい場合は、multipath-toolsに含まれる kpartxコマンドを使う。
参考記事：ディスクイメージとパーティション

ファイル型データベースをリモートで使う

2008-06-29T23:08:00.008+09:00

普段 Macや Linuxで仕事をしている人間にとっては、Windows機で作業をするのが苦痛だ。
しかし世の中には dBASEや Microsoft Accessで作られたデータベースというものがあって、時にはそういった「ファイル型データベース」を読み書きする仕事もあったりする。

Microsoft SQL Serverのようなクライアントサーバ型データベースであれば、それがたとえ Windowsでしか動作しなくとも JDBCを使ってリモートから利用できるため手元の Macで開発作業が出来るわけだが、ファイル型データベースの場合はそうもいかない。

最近 dBASEファイルをどうしても読み書きする必要があって、仕方ないので Virtual JDBCを使って Windows機上にあるデータベースファイルをリモートからアクセス出来るようにしてみたのが下記。
（なおWindowsには dBASEの ODBCドライバが標準で搭載されている）

Windowsで作業したくないばかりにこんなことまでやるかという気もしないでもないが、それはさておき。

(a) JDBC URLとしてサーブレットのURLと vjdbcに設定したDB名を与える。
"jdbc:vjdbc:servlet:http://my-windows-host:8080/vjdbc/vjdbc,mydb"

(b) web.xmlにて vjdbcサーブレットをマッピングする。


<servlet>
  <servlet-name>VJdbcServlet</servlet-name>
  <servlet-class>
    de.simplicit.vjdbc.server.servlet.ServletCommandSink
  </servlet-class>
</servlet>

<servlet-mapping>
  <servlet-name>VJdbcServlet</servlet-name>
  <url-pattern>/vjdbc</url-pattern>
</servlet-mapping>

(c) vjdbcがリクエストを転送する先となるターゲットデータベースの設定を /WEB-INF/vjdbc-config.xmlに記述する

(d) (vjdbc-config.xml内) JDBC-ODBCブリッジのURLで ODBCデータソース名を指定
"jdbc:odbc:mydbase"

(e) Windowsの「管理ツール」→「ODBC」で dBASE用のデータソースを設定する（*.DBFファイルの置いてあるフォルダを指定）。データソース名は (d)で指定した物と合わせる。

この構成で JDBCを使って dBASEファイルへリモートアクセスが出来るようになった。
・・・なったのだが、トランザクション操作をしようとするとこの通り・・・

java.sql.SQLException: 
[Microsoft][ODBC dBase Driver]オプションの機能は実装されていません。

Windowsに標準でくっついてるようなドライバにそこまで期待すんなということですな。

ちなみに dBASEの JDBCドライバ（商用）もあって、5同時アクセスライセンスが 150ドルで買える。お金を取るくらいだからもちろんトランザクションもサポートしているに違いない。真面目に今後もdBASEと付き合っていく必要がある、かつ、ライセンス料を顧客に負担してもらえる場合はこれを使ったほうが無難だと思う（試してないけど）。

JDBC-ODBCブリッジを使ってファイル型データベースにアクセスする用途以外でも、何らかの理由でデータベースアクセスをHTTPで中継したい場合に vjdbcは役に立つだろう。

Macと Xenと VNCクライアント

2008-06-29T14:24:00.003+09:00

Xenで動作する仮想マシンの画面を表示するインターフェイスとしては、SDLとVNCの2種類がある。
SDLの場合、（特別な設定をしなければ）画面表示に X Window が用いられる。XなのでSSHを経由してリモートに画面を表示させることも出来るが、画面を閉じると仮想マシンも強制終了してしまうという凶悪な仕様なため主にリモートでヘッドレス運用をする場合は使えない。
VNCと比べた場合の利点は、（ローカルマシンで画面を表示するなら）高速だろうという点である。

いっぽう、VNCを使用する場合、仮想マシンごとに 5900番以降の空いているポートを用いて VNC接続の待ち受けが行われる（VMの設定ファイルでポート番号を固定することもできる）。
リモート運用にはこれが最も適しているのだが、ひとつ重大な問題がある。

Mac OS Xでまともに動く唯一のフリーな VNCクライアントである Chicken of the VNC (a.k.a. cotvnc) と Xenの VNCサーバの相性が悪く、使えないのだ（画面が全く表示できない又は乱れる、エラーで接続が切れる）。

cotvncが悪いのか Xenに内蔵されているVNCサーバが悪いのか（もしくは両方なのか）知らないが、Xenのメーリングリストで「cotvncでちゃんとVMの画面が表示できないよー」という投稿が過去に一度あったものの解決されずに今に至っていることや cotvncの開発が止まっていることから、もはや状況は絶望的かと思われた。
X over SSHを使って dom0上の vncviewerを動かすという手は使えるのだが、ものすごく遅いし受け付けてくれないキーがあったりするしたまにバグって切れたりするので絶望的な状況であることに変わりはなかったと言えよう。

そんな時に現れた救世主、
Redstone Software社の Vine Viewer
Vineといっても昔あった Linuxのそれとは関係ないし、Windows互換レイヤのソフトウェアでもない。

・XenのVNCサーバと接続できる
・VNC over SSHサポート（出先からのアクセスも安心）
・画面の録画ができる（QuickTime形式の動画ファイルになる）

これでバーチャルマシンの管理がしやすくなるなあ。
値段は 35ドル。

SpringでJNDIを提供する続き

2008-06-25T06:14:00.005+09:00

以前のエントリで、XBeanの成果物を拝借して Springで JNDIを提供させる方法を示したのだが、この org.apache.xbean.spring.jndi.SpringInitialContextFactoryは Beanファクトリとして ApplicationContextのバリアントを使っていないためそのままだと PropertyPlaceholderConfigurerなどを使って Bean定義ファイル内の値をパラメタ化することが出来ない。
（ApplicationContextの子孫は、BeanFactoryPostProcessorを自動処理するのだが、それ以外の BeanFactoryではプログラムコードで明示的に postProcessBeanFactoryを呼んでやらなければ処理されない）
ApplicationContextはあくまで「アプリケーションの」コンテキストであるため JNDIの提供に適用しない事自体は正しいと思うが、せめてpostProcessBeanFactoryを呼んで欲しいところだ。
この問題（？）は2005年に報告されているが完全に無視という形のようだ。こんなのただの副産物だから本来の用途にさえ使えればよくてそれ以外興味ないねということだろうか。

仕方がないのでSpringInitialContextFactoryの派生クラスを作って BeanFactoryの生成を行っているメソッドをオーバーライドし、postProcessBeanFactoryの呼び出しを追加することにした。


package net.stbbs.xbean.spring.jndi;

import java.util.Map;

import org.apache.xbean.spring.context.impl.XBeanXmlBeanFactory;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.config.BeanFactoryPostProcessor;
import org.springframework.core.io.Resource;

public class SpringInitialContextFactory extends
    org.apache.xbean.spring.jndi.SpringInitialContextFactory {

  @Override
    protected BeanFactory createContext(Resource resource) {
        BeanFactory factory = super.createContext(resource);
        Map<String,Object> postProcessors = 
          ((XBeanXmlBeanFactory)factory)
            .getBeansOfType(BeanFactoryPostProcessor.class);
        for (Map.Entry pp:postProcessors.entrySet()) {
          ((BeanFactoryPostProcessor)pp.getValue())
            .postProcessBeanFactory((XBeanXmlBeanFactory)factory);
        }
        return factory;
    }
}

jndi.propertiesは
java.naming.factory.initial=org.apache.xbean.spring.jndi.SpringInitialContextFactory
を
java.naming.factory.initial=net.stbbs.xbean.spring.jndi.SpringInitialContextFactory
に書き換えた。

DbUnitでテーブルをエクセル出力する

2008-06-25T03:19:00.005+09:00

以前のエントリで、DbUnitを使ってフィクスチャによるデータベース事前条件の定義を含むユニットテストを行う方法を示した。

事後条件については、ターゲットとなるメソッドの実行が完了した後にSimpleJdbcTemplateなどでデータベースに対しクエリを行うことでチェックすることが出来る。理想としてはそのようにしてプログラムコードだけで事後条件を自動的に検査出来るほうが良い。よく練られた多角的なテストケースが存在することにより、プログラムは修正作業によるエンバグの発生から逃れやすくなるだろう。

しかし、テストケースに山のような数のselect文やループ構文を記述している時間が惜しい時があるのも事実だ。人間が表の状態を視覚的に確認することで、（ミスの検出確率は下がるものの）事後条件のチェックにかかる時間が節約出来ることも多々ある。

ところが、基本的にフィクスチャを用いるユニットテストは各テストメソッドの実行が１つのトランザクションとなっており、成功にせよ失敗にせよテストの完了時にトランザクションはロールバックされてしまいデータベース上のテーブルは空に（正確にはテスト実行前の状態に）戻ってしまうため、テストの実行後に GUIのフロントエンドなどを用いてデータベースの内容を確認しようとしても無駄である。

DbUnitには、テーブルの内容をファイルにダンプする機能があるので、それをテスト中の任意の時点で呼び出すことでこの問題を解決出来る。下記の例では、addCommentToArticle()メソッドの実行後に users, articles, commentsという3つのテーブルをエクセルファイルに出力している。エクセルファイル上では、1つのテーブルが1つのシートに割り当てられる。


public void testAddCommentToArticle()
{
    target.addCommentToArticle(1, 2, "コメント");

    // addCommentToArticle()実行後のデータベース内容をエクセルファイルにダンプ
    IDatabaseConnection con = this.getConnection();
    IDataSet dataset = con.createDataSet(
        new String[]{"users","articles","comments"});
    OutputStream os = new FileOutputStream("addCommentToArticle.xls");
    XlsDataSet.write(dataset, os);
    os.close();
    con.close();
}

繰り返しになるが、ダンプされたエクセルデータを目視で確認し事後条件の検査をするという方法はユニットテストのあり方として理想的ではない。いうまでもなく、事後条件の検査はテストケースの中に assert文を使って記述されるべきだ。それをわかった上でどこを妥協するかは時間的制約との兼ね合いだろう。

事後条件の検査以外にもテーブルのダンプは有益な場合がある。たとえばロジックの実装者はデバッグのためにそれがあると便利なはずだ。事後条件の検査を自動で行う行わないに関わらず、テーブルのダンプを常に生成するようにしておいた方が実装者に優しいといえる。ただ、テストの最後でダンプを行うようにテストメソッドをコーディングした場合、途中のassertに引っかかるとダンプが行われないためデバッグ時には不便かもしれない。ダンプのタイミングは状況に応じて選ぶと良いだろう。

Railsとsqlite3

2008-06-22T02:42:00.002+09:00

RedmineをGentooで動かそうとしたら、"Unable to create the anonymous user"と言われて動かない。
Macだと(Railsを2.0.2に更新すれば)同じようにして動いたのにおかしいなと思ったら、どうやら RailsではSQLite 3.3.8以降をうまく扱えないらしい。
参考記事：Using SQLite3 with Rails

ところが Portageに入っているSQLite3は一番古くても 3.4.1からだったりするもので。バカー！

仕方ないので MySQLで運用する事にした。めんどくせえなあ。

スパースファイルの作り方

2008-06-15T23:31:00.003+09:00

Portageに入っている iscsitargetがアップデートされ、今使っている Xenのカーネル(2.6.20)でもビルドできるようになったので MacProの TimeMachine用にiSCSIを立ち上げることにした。

iSCSIを使っていて思ったんだけど、LVMで作った論理ボリュームをSCSIディスクとして他のホストへ提供していると、そこに作られたパーティションを udevが勝手に認識してしまい面倒なことになったりする。これを避けるため、（少々のオーバーヘッドは覚悟の上で）ホスト側でいったんファイルシステムを作成しその中のイメージファイルをディスクとして提供することにした。

しかしながら、何百ギガバイトものファイルを ddで普通に作成するのにはかなり時間がかかる。なのでここはスパース（sparse, 疎な）ファイルを使うことにしたのでその方法をメモしておく。

私はこのようにして 400GBのスパースファイルを作成した。
dd if=/dev/zero of=timemachine-for-macpro.img bs=1M seek=409600 count=0

この操作は一瞬で終わるが、ls -l でファイルサイズを表示してみると確かに400GBの長さがあることになっている。
しかしこの段階では実際にはディスク容量を消費しておらず（それは dfで確認できる）、ファイルに対し書き込みが行われるにつれ順次ディスク容量を消費していくことになる。

巨大なファイルを作成するための時間と、初期のディスク容量を節約したい向きにはスパースファイルがお勧めである。
ただし運用中にフラグメントが発生しやすいであろうと想像できるため、パフォーマンスを稼ぎたい場合には向かないだろう。

Springベースのユニットテストに DbUnitを組み合わせる方法

2008-06-08T03:46:00.004+09:00

DbUnitは、JUnitにデータベース入出力のテストを行うための各種便利機能を提供するための拡張である。
ここでは、フィクスチャのロードを行う機能にスコープを絞って DbUnitを取り上げる。
フィクスチャとは、ユニットテストの事前条件となるテストデータである。

DbUnitを使うには、クラスパスに下記のjarファイルを追加する。

dbunit-*.jar
slf4j-api-*.jar
slf4j-jcl-*.jar

フィクスチャを使うユニットテストは、各テストメソッド毎に下記のような流れで実行される。

a) トランザクション開始
↓
b) フィクスチャをデータベースにINSERT
↓
c) テスト対象メソッドの呼び出し
↓
d) 実行結果のチェック
↓
e) トランザクションをロールバック

a, e は Springの機能で自動的に行われる。
c, d はテストケースの実装者がコーディングするとして、残る b を DbUnitで行うということになる。

テストケースの各トランザクションを常にロールバックする設定にしておけば、データベースは各テストメソッドが終了するたびにテストを開始する前の状態へ戻るため、INSERTされたフィクスチャも取り消される。そのため、固定のテストデータを用いても2回目以降のテストで重複キーの問題が発生するということは無い。

前回のエントリSpringとユニットテストで解説したような、Springによって自動的にトランザクション管理が行われるように構成された、つまり

@RunWith(SpringJUnit4ClassRunner.class)
@TransactionConfiguration
@Transactional
@ContextConfiguration

といったアノテーションの付加されたテストケースをさらに DbUnitへ対応させるには、テストケースに下記のような追加を行う。

1) DataSourceBasedDBTestCaseを継承させる
2) DataSource型のプロパティを持たせ、Springでインジェクトさせる
3) protected DataSource getDataSource()メソッドを実装する (単に 2のデータソースオブジェクトを返すだけで良い)。このメソッドはDbUnitが利用する。
4) @Beforeアノテーションを付けて、public void setUp()を実装する。単に super.setUp()をコールするだけで良い。
5) protected IDataSet getDataSet()をオーバーライドする。ここには、フィクスチャとなるデータセットオブジェクトを返す処理を記述する。このメソッドはDbUnitが利用する。

注意しておきたいのは 2 のデータソースである。Springと DbUnitを一緒に使うためのデータソースは TransactionAwareDataSourceProxyでなくてはならない。
DbUnitはデータソースから取得した物理コネクションをフィクスチャのINSERTが完了した後に一度クローズしてしまう。Springのトランザクション管理下ではこれは不正な操作であり（DbUnitは Springの事など知らないのでやむを得ないのだが）、このため素のデータソースを DbUnitへ渡すとテスト本体が正常に実行できなかったりする。
Springの TransactionAwareDataSourceProxyでデータソースを包んでおけば、物理コネクションが適切な Proxyオブジェクトによって保護されるため、この問題を防ぐことができる。

デフォルトでは、DbUnitはフィクスチャをデータベースに INSERTする際にテーブルを一旦クリアしてしまう。もし接続先のデータベースがユニットテスト専用ならばこの動作は妥当だが、そうでない場合（同じデータベースを結合テストにも使用するなど）はテーブルをクリアしてほしくないだろう。ユニットテスト実行時にテーブルをクリアせずフィクスチャの INSERTだけを行うようにするには、protected DatabaseOperation getSetUpOperation() メソッドをオーバーライドして DatabaseOperation.INSERT を返すようにすると良い。
（但し、できれば結合テスト用のデータベースとユニットテスト用のデータベースは別々に設けたいところである。例えば Ruby on Railsではそのような習わしになっている）

フィクスチャは Excelで記述することが出来る（私が DbUnitを使いたいと思った唯一の理由がこれだ）。
Excelの各シートがデータベースのテーブルに対応する。シート名としてテーブル名を用いることによって、シートがテーブルと対応づけられる。
各シートの最上行にはカラム名を記載し、2行目以降に INSERTしたいデータを並べる。このようにして作成した　Excelファイルを fixtures.xls として保存したなら、先の 5番にある protected IDataSet getDataSet() の実装はこのようになるだろう。


@Override
protected IDataSet getDataSet() throws Exception {
  return new XlsDataSet(new File("fixtures.xls"));
}

HttpServletRequestについて思う事

2008-06-06T04:40:00.003+09:00

Googleウェブマスターツールなるものを使ってこのブログへ到達する人々の検索ワードなんかを調べてみると、HttpServletRequestについて調べに来ている人がかなり多いことに驚いたのでエントリを起こしてみた。というか、うちのブログに書いてある HttpServletRequestの情報って Apache CXFのサービスからサーブレットリクエストを参照する方法のメモとかごく一部の人しかわからない超ニッチな奴なんで、ガチでHttpServletRequestについて知りたくて検索した人からすればかなりガッカリというか意味不明だと思う。それじゃ申し訳ないので Googleで HttpServletRequestについて検索したとき上位に出てくるコンテンツについて思った事とか述べてみることにした。これでどう申し訳が立つのか知らないけど。

Java 2 Platform EE 1.3.1: インタフェース HttpServletRequest sdc.sun.co.jp

さすが Google先生、トップには最も妥当な物を出してくれます。

英語でもいいから最新の情報が欲しいという人は HttpServletRequest (Java EE 5)をどうぞ。そういう人はここに来ないと思うけど・・・

リクエスト情報の取得(HttpServletRequest) www.javadrive.jp

いつの記事かわからなかったのだけど Tomcat6の話と並べてあるしスクリーンショットが IE7なので最近だと思う。比較的どうでもいいことだけど、

・日本語パラメータの対応(getBytes)
・日本語パラメータの対応(setCharacterEncoding)

後者を解説するなら前者は何のために必要だったんだろう。とはいえ HttpServletRequestを単一キーワードで検索した人にとっては望みのページだろう。

HttpServletRequest - Java 入門 JSP サーブレット etc. sengoku.ath.cx

この記事も Tomcat5.5 や IE7を使って解説しているのでそんなに古くないと思われる。というか実際古くない。これも多分 HttpServletRequestを単一キーワードで検索した人にとっては望みのページかと。

JavaA2Z【HttpServletRequestとは】 www.kab-studio.biz

2005年の記事？にしては古いかな？setAttribute()でセットした値を JSP側で使うためには jsp:useBeanはもう使わず JSTLを使われたし。

@IT:Javaプログラミング・ワンポイントレクチャー：HttpServletRequestオブジェクトの役割 www.atmarkit.co.jp

2003年の記事。記事は古いが内容が役に立たなくなっているというわけでもない。が、HttpServletRequest を単一キーワードで検索した人にとっては、直接欲しい情報ではないだろう。

J2EE講座 [ リクエストの取得　HttpServletRequestインタフェース］ www.site-cooler.com

あくまで HttpServletRequestのページなので getParameter() とかの解説が無い。検索でダイレクトにこのページへ飛んでしまった人はガッカリかもしれない（このページの前の、スーパーインターフェイスたる ServletRequestの解説ページに書いてある）が、一連のページはとてもまっとうな内容。まっとうな内容だけに、「目の前にある仕事をやっつけるためだけに調べ物をしている人」向けではない。しかしそういう人でも J2EE講座 [ JSP、Servletの文字化け対策］はチェックしておいて損しないとおもう。

HttpServletRequest雑感

日本語文字列の入力エンコーディングを正す方法については setCharacterEncoding()を使いなさいということで正しいんだけど、仕事で作る Webアプリケーションだったら出来ればこういうサーブレットフィルタを使って解決したいところ（後でそのプログラムをメンテナンスする人のためにも）。

多くの入門サイトではコンテンツの文字コードを Shift_JISで扱ってるけど、マルつき数字とかキロとか昭和とかの字が化けるよーとか余計な悩みを抱えるのを避けたければ UTF-8を使うほうが良いかもしれない(データベースを使うならそれも合わせる)。周りがユニコードなんてしらねーよ、シフトJISでいいだろ！とか言う人ばかりで UTF-8なんて使わせてもらえない状況であればもう仕方ないので頑張って解決するしかないけど。ヒント：MS932、Windows-31J

しかしなんで HttpServletRequestについてみんなそんなに検索するんだろうなあ。もっと高位のフレームワークを使わないで仕事になるのかなあ（会社の方針でオープンソース禁止なのだろうか、だとしたら難儀なことだ）。むしろフレームワークを作ってる人なら HttpServletRequestについてすごくよく知りたいと思うかもしれないけど、そういう人そんなにたくさんいないだろうし。
Webアプリケーションの動作原理まで詳細に勉強したいとか、いやちょっと試してみるだけだからフレームワークみたいな大げさなのは・・・、とかいうのでなければ、サーブレット APIを直接呼び出すようなやりかたをしないで何かのフレームワークを使ったほうがいいかと。英語がだめなら Seasar2 あたりをあたってみるのがいいんじゃないかな。余計なお世話か。

MySQL: DDLとトランザクション

2008-06-04T06:31:00.002+09:00

MySQLでは（他のDBMSでもおおよそ似たようなものだと思うが）、トランザクションの途中で CREATE TABLE文や DROP TABLE文のようなDDLを実行すると強制的にコミットが行われる。これに気付かないと、ロールバックしているはずなのになんかデータが残留してる、ということが起こる（そもそもトランザクションの中でDDLを呼ばなければいけない事態を何とかすべきだが）。DDL以外でも、TRUNCATE TABLE文などでもそうなる。でも、CREATE TEMPORARY TABLEは大丈夫のようだ。

参考 12.4.3. 暗黙のコミットを引き起こすステートメント

Springとユニットテスト

2008-06-04T03:47:00.008+09:00

テストケースくらいはなるべく特定のフレームワークに依存させたくないという気持ちはあるものの、さすがに Hibernateやらといったヘヴィな奴をインスタンス化する長い道のりを手でコーディングしたり、単一責任の原則に基づいて真面目に分割されたコンポーネント群のワイヤリングを手でコーディングしたりするのはかなり厳しいものがあるので、そこは目をつぶってテストケースもやはり Springの助けを借りて実装するのが現実的だ。

なお JUnitと Springを連携させるには、spring.jarの他に spring-test.jar が必要となる。

Eclipseについてる JUnitを捨てる

Eclipseについている JUnitはちょっと古くて、Springに対応するために必要なインターフェイスJUnit4ClassRunnerが存在していない。なので Eclipseに標準で付属している JUnitをビルドパスから外し、最新の JUnitへビルドパスを通す必要がある。その場合でも "Run as"→"JUnit TestCase"はちゃんと動くので心配ない。

テストケースに Beanをインジェクトさせる

テストケースに Springサポートを適用する一番シンプルな方法は、下記のふたつのアノテーションをつけてやることである。

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration

これらのアノテーションがついたテストケースを走らせると、最初にテストケースと同じパッケージ階層とクラス名+"-context.xml"という名前を持つ Bean定義ファイルが読み込まれる。
テストケースに @Autowired （もしJava EEのアノテーションが使えるなら @Resource でも良い）の付いたプロパティがあれば、それぞれのプロパティと同じ型の Beanが自動的にインジェクトされる。


<!-- src/test/com/acme/DataImporterTest-context.xml -->
<beans>
  <!-- 中略 -->
  <bean id="dataImporter" class="com.acme.DataImporterImpl">
  <property name="dataSource" ref="dataSource"/>
  </bean>
</beans>

package com.acme;
// 中略
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class DataImporterTest {
  @Autowired
  DataImporter dataImporter;

  public void testDoImport()
  {
    dataImporter.doImport();
  }
}

これなら、テストケースの中に何らインスタンス化やワイヤリングの処理を記述しなくても良く非常に簡潔である。
読み込むBean定義ファイルを変更したり名称を指定してプロパティに Beanをインジェクトしたり（@Qualifierアノテーションを使う）も出来るので、詳しくは Spring 2.5のドキュメント 8.3.7.2. Context management and caching あたりを参照されたし。

トランザクション制御も自動化する

典型的には、データベースアクセスを行うコンポーネントに適用するテストケースの各メソッドはそれぞれがひとつのトランザクション単位として考えられるだろう。したがって、各テストメソッドの開始時点で自動的にトランザクションがBEGINされ、終了時には自動で COMMIT又は ROLLBACKが行われると便利である。
そうしたい場合は、先の @RunWith, @ContextConfigurationアノテーションに加えて下記のアノテーションをつけてやると良い。

@TransactionConfiguration
@Transactional

各テストメソッドの実行にあたり、Bean定義ファイル内で定義された transactionManagerという名前のトランザクションマネージャを勝手に使ってトランザクションの制御を行ってくれる。
（使用するトランザクションマネージャの名前は@TransactionConfigurationアノテーションのオプションで変更が可能）

デフォルトでは、各テストメソッドの終了時にはトランザクションがロールバックされるようになっている。つまりテストの実行によってデータベースの内容を変更しないということだ。ユニットテストは外部リソースの状態から独立しているべきなのでこの動作が理想的なのではあるが、どうしてもテストケースを回した後に Microsoft Accessやら Navicatやらといった GUIツールでテーブルの中身を確認してみたい場合もある。そういう時は @TransactionConfigurationアノテーションのオプションで defaultRollback=falseを与えてやるか、テストメソッドへ明示的に @Rollback(false) のようにアノテーションでロールバックを行わないことを記してやる必要がある。


<bean id="transactionManager"
  class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
  <property name="dataSource" ref="dataSource"/>
</bean>

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
@TransactionConfiguration
@Transactional
public class DataImporterTest {
  @Autowired
  DataImporter dataImporter;

  @Rollback(false)
  public void testDoImport()
  {
    dataImporter.doImport();
  }
}

気になったのだが、テストメソッドがロールバックを行わない設定になっていると、テストが失敗した（キャッチされない例外が上がった、アサーションに引っかかった）場合でもトランザクションは容赦なくコミットされてしまうようだ。中途半端なデータをデータベースに残さないよう、実装の初期段階ではロールバックを行う設定でユニットテストを行う方が良さそうである。

Beforeと After

Springによるトランザクション管理が適用されたテストケースでは、JUnitの標準的な @Before, @Afterメソッドの他に @BeforeTransaction, @AfterTransactionメソッドを持つことが出来る。
@Before, @Afterはトランザクション内で実行されるが、@BeforeTransactionはトランザクションの開始前、@AfterTransactionはトランザクションの終了後に実行される。

少しだけ記述を減らす＋α

もしテストケースが他のクラスを継承していないのであれば、@RunWith, @TransactionConfiguration, @Transactionalアノテーションを付ける代わりに AbstractTransactionalJUnit4SpringContextTests を継承させることもできる。

アノテーションの記述を省略できることに加え、このクラスにはデータベース操作のユニットテストを行う際に便利かもしれない下記のものが装備されている。
・Beanファクトリへのアクセス (applicationContext)
・ログAPIへのアクセス (logger)
・SimpleJdbcTemplateのインスタンス (simpleJdbcTemplate)
・データベース操作のテストに便利かもしれないいくつかのメソッド(countRowsInTable,deleteFromTables,executeSqlScript,setSqlScriptEncoding)

最後のはフィクスチャのロードなどに使うことを想定した機能かもしれないが、そのあたりを本格的にやるなら DbUnitを組み合わせて使うのが良いと思う。
言うまでもなく Javaは多重継承ができないので、DbUnitの DatabaseTestCaseを継承するかこのAbstractTransactionalJUnit4SpringContextTestsを継承するかの選択を迫られることになるのだが。

SpringでJNDIを提供する

2008-06-03T22:58:00.004+09:00

「え、それって<jee:jndi-lookup/> のこと？」
・・・だったらわざわざブログのエントリなぞ起こさんわい。JNDIを参照する側ではなく、提供する側の話。

Springは JNDIを参照することは出来るけど、JNDIサービス自体は提供していない。
ふつう JNDIはアプリケーションサーバが提供するものなので（ついでに言えば Java EEのサービスなので） Springの守備範囲ではないのだが、何らかの理由でユニットテストのターゲットが JNDIを参照しているとか（レガシーなSLSBを使い回してるとか、中のJRubyで activerecord-jdbc-adapterを使ってるとかね）、ユニットテスト用の Bean定義ファイル内でもデータソースの参照は JNDI経由で行いたいとか、Webアプリケーションではなくstatic public void main()から始まるスタンドアロンのプログラムなんだけどやっぱり Bean定義ファイル内でのデータソース設定は JNDIを参照する形の記述にしたいとか、そういう特殊な事情のある人またはマニアックな人は Springベースの JNDI実装が欲しくなったりもするのである。そして、やっぱりそういうものが存在する。

Springベースの JNDI実装 org.apache.xbean.spring.jndi.SpringInitialContextFactory は Apache Geronimoのサブプロジェクト XBeanの成果物である xbean-spring-*.jarに含まれている。これを拝借して自分のユニットテスト用クラスパスに追加してやろう。

JNDIの実装クラスを指定する方法には下記のようなものがある。
・システムプロパティjava.naming.factory.initial にクラス名をセットする
・クラスパスに jndi.propertiesというファイルを置き、java.naming.factory.initial=行にクラス名を記述する
どちらでも良いが Eclipseで Runする時に VM引数を設定するのは面倒なので私は後者にしている。

jndi.propertiesの内容は下記のようになる。
java.naming.factory.initial=org.apache.xbean.spring.jndi.SpringInitialContextFactory

SpringInitialContextFactoryは jndi.xmlという名前の Bean定義ファイルをクラスパス上で探しだし、それを JNDIの設定ファイルとして用いる（jndi.propertiesと同じ場所にでも置いておけば良いだろう）。この Bean定義ファイルには少なくとも、jndi という名称で org.apache.xbean.spring.jndi.DefaultContext クラスの Beanを定義しておく必要がある。空の JNDIツリーを提供するだけならばこの Beanに何らプロパティをセットする必要はないが、典型的にはここにデータソースをバインドすることになるだろう。データソースをJNDIにバインドしたければ、jndi.xmlは下記のような記述になる。例はMySQLの場合だが、DBベンダの独自な DataSource実装を使うのが嫌であれば Springの DriverManagerDataSourceなどといった汎用のDataSource実装を使えば良いと思う。
（個人的には、ことユニットテストに用いる場合などコネクションプーリングの必要ないケースに限って言うならば DataSourceの実装が DBベンダのものか Springのものかは大した問題ではないと考えている。アプリケーションの利用するDBMSが差し替わるというのは、いろんな意味でよほどのことだ）


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans">
  <bean id="dataSource"
    class="com.mysql.jdbc.jdbc2.optional.MysqlDataSource">
    <property name="url" value="jdbc:mysql://localhost/mydb"/>
    <property name="user" value="username"/>
    <property name="password" value="secret"/>
    <property name="zeroDateTimeBehavior" value="convertToNull"/>
    <property name="useUnicode" value="true"/>
    <property name="characterEncoding" value="UTF8"/>
  </bean>

  <bean id="jndi"
    class="org.apache.xbean.spring.jndi.DefaultContext">
    <property name="entries">
      <map>
        <entry key="java:/comp/env/jdbc/dataSource">
          <ref bean="dataSource"/>
        </entry>
      </map>
    </property>
  </bean>
</beans>

ずるをする

Springのトランザクション管理下で JDBCの呼び出しをしたい場合、下記のいずれかの条件を満たしている必要がある。

1)常に Springの JdbcTemplateを経由してJDBCの呼び出しを行う
2)常に SpringのDataSourceUtilsを経由してデータソースからコネクションを取得する
3)DataSourceを Springの TransactionAwareDataSourceProxyでラップし、常にそれを使う
4)JtaTransactionManagerを使う

JNDIから直接データソースを取得するように実装されているレガシーなJEEコードも Springのトランザクション管理下で動作させたい場合、Java EEコンテナ上で動作させる時は 4の方法でコンテナ管理のトランザクションマネージャとくっつけてやれば裏でうまく処理してくれそうな気がするが、Java SEベースの開発環境でユニットテストをするときはその方法が使えない。

では、TransactionAwareDataSourceProxyでラップ済みのデータソースを JNDIに登録してはどうかということで、やってみたところ一応期待通りの動作をするようだ。


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans">
  <bean id="dataSource"
    class="org.springframework.jdbc.datasource.TransactionAwareDataSourceProxy">
    <constructor-arg>
      <bean class="com.mysql.jdbc.jdbc2.optional.MysqlDataSource">
        <property name="url" value="jdbc:mysql://localhost/mydb"/>
        <property name="user" value="username"/>
        <property name="password" value="secret"/>
        <property name="zeroDateTimeBehavior" value="convertToNull"/>
        <property name="useUnicode" value="true"/>
        <property name="characterEncoding" value="UTF8"/>
      </bean>
    </constructor-arg>
  </bean>

  <bean id="jndi" class="org.apache.xbean.spring.jndi.DefaultContext">
    <property name="entries">
      <map>
        <entry key="java:/comp/env/jdbc/dataSource">
          <ref bean="dataSource"/>
        </entry>
      </map>
    </property>
  </bean>
</beans>

Springのドキュメントによると、DataSourceTransactionManagerにセットする dataSourceは TransactionAwareDataSourceProxyでは駄目・・・なんだけど、そういう場合は勝手に TransactionAwareDataSourceProxyから中の本物データソースを取り出して使うよ。ということになっていて、実際ソースを確認したところそうなっていたので、JNDIからもってきたデータソースが既に TransactionAware...でラップされていても大丈夫みたい。

JRubyで DBIを使う ( DBI / Jdbc )

2008-05-28T21:00:00.006+09:00

Javaでいうところの JDBCに相当するレイヤが Rubyにおける DBIである。

ActiveRecord用に最初から設計されたデータベースじゃないと ActiveRecordで使うのはとても厳しい。そういう場合に取り得る選択としてはひとまず ORMの使用をあきらめて SQLを用いたDBアクセスをするというのがあるが、そうするにしても JRubyから java.sql.* を使うようではなんだか負けた気分（っていうか最初から Javaで書けば？って話）なので、ここはひとつ JRubyから DBIを使ってデータベースにアクセスすることにする。

以下、$JRUBY_HOME/binに PATHが通っている前提で。

JRubyに DBIをインストール

RubyForgeから "Ruby/DBI"を探し、dbi-*.tar.gz をダウンロード・展開したら、

jruby setup.rb config --without=dbd_sqlite,dbd_sybase
jruby setup.rb setup
jruby setup.rb install

のようにする。これで JRubyに DBIがインストールされたのだが、これとは他に DBIと JDBCをブリッジするドライバが必要となる。

JDBC用のDBIドライバをインストール

RubyForgfeで "Ruby DBI-JDBC driver" を探し、dbi-jdbc.tar.gzをダウンロード・展開する。
アーカイブの中に入っていた DBD ディレクトリを $JRUBY_HOME/lib/ruby/site_ruby/1.8/ に放り込む。
結果、
$JRUBY_HOME/lib/ruby/site_ruby/1.8/DBD/Jdbc/Jdbc.rb
$JRUBY_HOME/lib/ruby/site_ruby/1.8/DBD/Jdbc/JdbcTypeConversions.rb
が存在する状態になれば OK

DBI-JDBCの使い方例

require 'dbi'

url = 'DBI:jdbc:mysql://localhost/mydb'
username = 'username'
password = 'password'
driver = 'com.mysql.jdbc.Driver'
DBI.connect(url, username, password, 'driver'=>driver) do |dbh|
  p dbh.select_all('show tables')
}

なお型変換やNULLの扱いのあたりで制限事項が色々あるため、dbi-jdbc.tar.gzに含まれているREADMEには一度目を通されたし。
JNDIからデータソースを取ってきてそこからgetConnection()する方法は用意されていないようだ。簡単なハックで出来るようになると思うけど。

DBIの API仕様については下記を参照のこと。
DBI Interface Specification Version 0.2.2 (Draft)

STBBS.NET blog

Springと一緒に Wicketを使う

Windows XP Professionalをマルチユーザー仕様に改造する

関連記事

関連サイト

おまけ

ファイル型データベースをリモートで使う

Macと Xenと VNCクライアント

SpringでJNDIを提供する続き

DbUnitでテーブルをエクセル出力する

Railsとsqlite3

スパースファイルの作り方

Springベースのユニットテストに DbUnitを組み合わせる方法

HttpServletRequestについて思う事

Java 2 Platform EE 1.3.1: インタフェース HttpServletRequest sdc.sun.co.jp

リクエスト情報の取得(HttpServletRequest) www.javadrive.jp

HttpServletRequest - Java 入門 JSP サーブレット etc. sengoku.ath.cx

JavaA2Z【HttpServletRequestとは】 www.kab-studio.biz

@IT:Javaプログラミング・ワンポイントレクチャー：HttpServletRequestオブジェクトの役割 www.atmarkit.co.jp

J2EE講座 [ リクエストの取得　HttpServletRequestインタフェース］ www.site-cooler.com

HttpServletRequest雑感

MySQL: DDLとトランザクション

Springとユニットテスト

Eclipseについてる JUnitを捨てる

テストケースに Beanをインジェクトさせる

トランザクション制御も自動化する

Beforeと After

少しだけ記述を減らす＋α

SpringでJNDIを提供する

ずるをする

JRubyで DBIを使う ( DBI / Jdbc )

JRubyに DBIをインストール

JDBC用のDBIドライバをインストール

DBI-JDBCの使い方例

STBBS.NET blog

Springと一緒に Wicketを使う

Windows XP Professionalをマルチユーザー仕様に改造する

関連記事

関連サイト

おまけ

ファイル型データベースをリモートで使う

Macと Xenと VNCクライアント

SpringでJNDIを提供する 続き

DbUnitでテーブルをエクセル出力する

Railsとsqlite3

スパースファイルの作り方

Springベースのユニットテストに DbUnitを組み合わせる方法

HttpServletRequestについて思う事

Java 2 Platform EE 1.3.1: インタフェース HttpServletRequest sdc.sun.co.jp

リクエスト情報の取得(HttpServletRequest) www.javadrive.jp

HttpServletRequest - Java 入門 JSP サーブレット etc. sengoku.ath.cx

JavaA2Z【HttpServletRequestとは】 www.kab-studio.biz

@IT:Javaプログラミング・ワンポイントレクチャー：HttpServletRequestオブジェクトの役割 www.atmarkit.co.jp

J2EE講座 [ リクエストの取得 HttpServletRequestインタフェース］ www.site-cooler.com

HttpServletRequest雑感

MySQL: DDLとトランザクション

Springとユニットテスト

Eclipseについてる JUnitを捨てる

テストケースに Beanをインジェクトさせる

トランザクション制御も自動化する

Beforeと After

少しだけ記述を減らす＋α

SpringでJNDIを提供する

ずるをする

JRubyで DBIを使う ( DBI / Jdbc )

JRubyに DBIをインストール

JDBC用のDBIドライバをインストール

DBI-JDBCの使い方例

SpringでJNDIを提供する続き

J2EE講座 [ リクエストの取得　HttpServletRequestインタフェース］ www.site-cooler.com