サンプルが容易に動くのがいい。
これ重要なところだと思うんだけど、意外と何でも詰め込むサンプルが多すぎて使い物にならなかったりする。
NetBeansからの配備時間のテストに使ったフレームワークは4つ。その中ですぐ動いたのがCubbyだけだった。
まず、Click、Wicket。この2つはサンプルがすさまじくでかく、また依存ファイルがものすごく多い。Clickのほうは依存するcayenneが2バージョンある用でどうしたらいいのかよくわからん。Wicketはとんでもない数の他のプロダクトに依存していて手作業で構築していくのが絶望的。お話にならなかった。一からプロジェクトを作る場合は問題はないのだろうけどね。
次にSAStruts。これはまずweb.xmlがおかしいので問題が起こる。それらを修正すると起動はしたものの、肝心のサンプルへとぶクリックで例外が出てる感じ。
StandardWrapperValve[default]: PWC1406: Servlet.service() for servlet default threw exception
java.lang.NullPointerException
at org.apache.jasper.compiler.TagLibraryInfoImpl.toString(TagLibraryInfoImpl.java:111)
at java.lang.String.valueOf(String.java:2827)
at java.lang.StringBuilder.append(StringBuilder.java:115)
at java.util.AbstractMap.toString(AbstractMap.java:490)
at java.lang.String.valueOf(String.java:2827)
at java.lang.StringBuffer.append(StringBuffer.java:219)
at org.seasar.extension.filter.util.RequestDumpUtil.dumpContextAttributes(RequestDumpUtil.java:86)
SAStrutsはおそらくGlassfishは未対応ということなんだろうか。・・・エラー表示されているところがフィルタだけっぽかったのでdumpフィルタを削除したら、そのままGlassfishでも動いたくさい。
ちなみにNetBeansでweb.xmlがおかしいと指摘されたのは3箇所。これらを修正すると一応動くようだ。
修正したのはまずスキーマの設定がおかしい（と思われる）ところを修正。Cubbyのほうからコピーしてきたら動いた。
２つめは必須であるはずの
3つ目は
このときの配備時間はwarファイルで6秒くらい、ディレクトリ配備で2秒くらいといったところ。
hotdeploy使わなくても十分高速だ。当たり前だけど、NetBeansでディレクトリ配備（デフォルト）だとhot deployは動く。F9（保存＋コンパイル）で即座に反映されるのだが、その後ブラウザを手動で表示するよりF6で再配備をかけて2秒かけるほうが楽な場合もある。10秒以上配備で時間がかかるのならHotDeploy一択なんだろうけど。もっとも再配備だとセッション関係は消えるのでこれらは使い分けたほうがいいのだが。
むかしからNetBeansは伝統的に差分配備するのでさくさく開発するのに向いてたんだよね。
これらサンプルのwarファイルだけを直接配備するならばまず動くので問題にならないのだけれども、あくまでソースを元にwarファイルを作ろうと思うと障害が多すぎた。でもバイナリ動かすだけじゃ勉強にはならんよ。
だが、それはCubbyだけはなかった。すばらしい。SAStrutsはおしい。この辺のライブラリもすべて含めて動くサンプルの親切さはSeasarプロジェクトの特徴・・・だろう。たぶん。
