Cubbyのいいところ

サンプルが容易に動くのがいい。

これ重要なところだと思うんだけど、意外と何でも詰め込むサンプルが多すぎて使い物にならなかったりする。

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のほうからコピーしてきたら動いた。

２つめは必須であるはずの の中が空っぽだという指摘。ここは1つ以上が必須となっている。空にしたい場合 自体を消せばよい。

3つ目はの下にエレメントが2つあったこと。これは最大で1つしか書くことができないはず。複数書きたい場合は自体を複数書くとエラーは消えた。

このときの配備時間はwarファイルで6秒くらい、ディレクトリ配備で2秒くらいといったところ。

hotdeploy使わなくても十分高速だ。当たり前だけど、NetBeansでディレクトリ配備（デフォルト）だとhot deployは動く。F9（保存＋コンパイル）で即座に反映されるのだが、その後ブラウザを手動で表示するよりF6で再配備をかけて2秒かけるほうが楽な場合もある。10秒以上配備で時間がかかるのならHotDeploy一択なんだろうけど。もっとも再配備だとセッション関係は消えるのでこれらは使い分けたほうがいいのだが。

むかしからNetBeansは伝統的に差分配備するのでさくさく開発するのに向いてたんだよね。

これらサンプルのwarファイルだけを直接配備するならばまず動くので問題にならないのだけれども、あくまでソースを元にwarファイルを作ろうと思うと障害が多すぎた。でもバイナリ動かすだけじゃ勉強にはならんよ。

だが、それはCubbyだけはなかった。すばらしい。SAStrutsはおしい。この辺のライブラリもすべて含めて動くサンプルの親切さはSeasarプロジェクトの特徴・・・だろう。たぶん。

後期高齢者医療制度・・・ってその前に養老年金で暮らせるの？

40年すべて支払ったとして毎月6.6万円。後期高齢者医療制度で6000円天引きされるとして、6万円。安いところにすんでたとしても家賃払って水道通信光熱費等はらったら終わりじゃない？

そもそもPSE法にしろ、この制度にしろ公布はかなり前からやってるようだけれども、誰も知らなくて施行直前になってあわてるというパターンはどうにかならんものか。

とりあえず、与党衆議院は体験として月6万で一ヶ月暮らしてもらったほうがいいんじゃないの？ああ、でも法律の原因になった小泉内閣を選んだのは国民だから6000円天引きはしないとして、6.6万支給でいいや。

どーやって暮らすんだろうね。

without JavaEEのほうが重いという衝撃的事実

新しいマシンのスピードをいろいろと試してみたが、そもそも1MB程度のwarファイルのデプロイ持間はCore Duo 1.66GHzでも0〜2秒で終わっているので圧倒的な速度は体感はできなかった。

そこですでに出来上がっている世の中のサンプルコードをデプロイするとどうなるのかをテストしてみた。まずサンプルがわかりやすそうなCubbyをテストモデルに。いろんなところで開発されているだろう独自フレームワークはほぼこの内容と一致するはずだからサンプルとしてはもってこいだ。

サンプルコードそのままではNetBeansのディレクトリに展開できないのでsrcとlibを違うフォルダへ移動させて、既存のソースコードからプロジェクトの新規作成を行った。Eclipseプロジェクトを使えるようになるプラグインもあったはずだが、それは使っていない。サンプルはたぶん動いてると思う。起動時にワーニングやエラー（saxのパースエラーが出てる）がいくつかでてるけど、動作そのものは問題があるように思えない。

そこで気になったのが起動時間。デプロイそのものは2秒程度で終わってると思う。

だが、そこからアプリケーションが起動するまでが非常に遅いのだ。

新調したマシンでの結果はwar配備で12〜19秒、ディレクトリ配備で11〜17秒となった。これ、旧マシンで起動させたら30秒を余裕で超える大変な起動時間になりそうだ。あまり大規模でないプロジェクトでこの有様ということは実際に業務で扱うプロジェクトではとんでもないことになる。

これだと確かにHot Deploy、Hot Deployというのもうなずける。

たしかにwarベースのservlet以外JavaSEな環境では配備されて実行されてからはじめてコンテナの起動やセットアップを行う。つまり、本来JavaEE環境ならすでに終わっているはずの各種コンテナの初期化等がここから始まるため非常に重いのだ。つまり、DIコンテナ上ですべてセットアップする方法だと毎回アプリケーションサーバーを再起動しているに等しい。

一方JavaEE準拠の開発方法だとコンテナの起動は15秒くらいかかるものの、1度起動したら起動しっぱなしでよい。デプロイにかかる時間はほんの数秒だ。

つまり、JavaEE準拠のほうが開発効率がよいことになる。うーむ、意外だった。それとも、このサンプルは遅くなるような特徴があるのだろうか。一応coolDeployにしてもデプロイ時間は変わらないのは確認済みだが。