Wicketの日本ユーザグループを、「あの」世界の矢野が立ち上げた！
「ウェブ・アプリケーションの革命がここにある – Apache Wicketユーザーグループを始めます」 – 矢野勉のはてな日記
立ち上げ時の勢いに乗り遅れそうになって多少すねたが、とにかくWicket-JA、なんかすっごく嬉しい。まだサイトもないけど、早急にみんなの力を結集し、形にしたい。
Wicketは1.3.0も出たことだし、2.0へのスペックも見え始めている。JavaでWebならWicketでしょ、と普通に会話になる程までに普及させてみたい。
皆さん、ぜひぜひMLに入ってみてください。
11月11日に行われた「Seasar Conference 2007 Autumn」で、S2Wicketについてのセッションを行った。定員30人の部屋が満席になるほどの人々に来ていただき、Wicketの簡単な紹介とS2Wicketの機能や今後などについて語ることができた。
S2Wicketのセッションにいらしてくれた皆さん、心より感謝いたします。また、スタッフの皆さまにも、感謝いたします。ありがとうございました。
なお、事後アンケートを募集しているので、来場された方はぜひアンケートの回答をしていただきたい。
11月11日に行われるSeasar Conference 2007 Autumnで、「E3: S2Wicketの紹介」というセッションを行うことになった。
特にWicketは「存在は知ってるけど使ったことがない」という人がほとんどだと思うので、Wicketの簡単な紹介とWicket単体でのデモを行って、その後にS2Wicketの紹介をする予定である。なので、Wicketに関する予習をすることなくS2Wicketを把握することができるよう、敷居は低くするつもりだ。
Wicketに興味がある方には、ぜひ足を運んでいただきたい。
先日の8月10日，java-ja主催の「第一回チキチキ そろそろ Wicket について一言いっとくか」，つまりWicket勉強会が開催された。
今回も，yoshioriさんの書道から始まった。
スピーカーは5人の予定だったのだが，仕事の都合で2名が時間までにかけつけることができず。一人は実務でWicketを使っている方だったので，非常に残念だった。
トップバッターはonkさん。Wicketの基本的な紹介とデモが主な内容だった。とはいえ，nekopさんやyone098さんからのするどい質問などにより，かなり細かな動作原理まで取り上げられる結果となった。
次は，カスタムコンポーネントの作り方をyoshioriさんにプレゼンしてもらう。実は，この題目は僕がお願いしたものである。ちょっと専門的だったので，作成の手軽さは何となく伝わったとは思うが，詳細についてはWicket未経験者にとっては難しかったかもしれない。
そして僕のプレゼンは，Wicketとその仲間たち，ということで，各種Wicketを拡張するためのライブラリを簡単に紹介。技術的な内容は薄かったため，あまり質問も出ず。しかも「まき」の指令が出ていて，限りなくライトニングトーク。
上記のプレゼン資料は，SlideShareの都合上，デザインを簡略化してある。
今回の参加者は30人近かった。結構な人数である。しかも，ほとんどがSwingやEJBなど，Javaを使いこなしている方ばかり。java-jaって，ホントにコアな人が集まるコミュニティである。
JSUGの勉強会で，ustreamでの放映を行ったのだが，今回もustreamで放映を行ってみた。一通り録画もできたので，紹介しておこう。
「基本的なページ遷移の仕方がわからない」「どこでデータベース処理を行うのか」など，超基礎的な説明がなされていないことに，最後に気がついてしまった件については，今回はバタバタ感が強かったため，誠に申し訳ないのだが，ご了承いただきたい。ま，「全部Javaでやろうぜ！」というWicketの基本精神は十分伝わったと思う。昨今の複雑なOSSの組み合わせでWebアプリを作るくらいなら，Wicket一つで構築したほうが，50倍は快適にWebアプリを作ることができる。今回の勉強会は，そういった「Wicketの心意気」の伝道という点では大成功だったのではないだろうか。
来る8月10日，java-ja主催で，
「第一回チキチキ そろそろ Wicket について一言いっとくか」
と銘打ったWicket勉強会を開催する予定である。
POHP＋フルJavaなWebアプリケーションフレームワークであるWicketは，Apacheのトッププロジェクトに名を連ねるところまで来ている。しかし，Wicketを使っているという話は，残念ながらあまり聞かない。
今回のWicket勉強会では，Wicketの初級的紹介から，実際に利用したときの経験談，そしてWicketをより便利にするプロダクト群の紹介など，結構幅広い話題がスピーカーから出てきそうな予感がする。Wicketを使ったことがない方も，ぜひ参加していただいて「あ，こんなものもあるんだー」と知っていただきたいと考えている。
参加申し込みは，「第３回申込」から行うことができる。奮ってご参加いただきたい。
— 追記 2007/07/31
飲み会だけの参加でも全然オッケーです！
以前「動的プロキシが循環参照していた際のシリアライズ問題」エントリにおいて僕が解決に至らなかった問題を紹介したが，見事に問題をクリアしたお二方からトラックバックを頂いた。
「動的プロキシが循環参照していた際のシリアライズ問題」- 矢野勉のはてな日記
「循環参照問題のよりエレガントな解法」- 矢野勉のはてな日記
「次期 S2Wicket 仕様断念の原因となった動的オブジェクトの循環参照問題をおいらもみんなのために解いたった！？」- 【見覚え】koichikのひとりごと【あります】
素晴らしいというか，やっぱり世の中にはすごい人がいるんだな，と痛感し，そして感激と感動でいっぱいである。
さっそくコードを見て，S2Wicketへの適用を進めている。S2Wicketの新機能を早く離陸させることが，お二方への恩返しとなると考えている。
ありがとうございます，やんやん，koichikさん！
何ヶ月ぶりかになるが，S2Wicketをバージョンアップした。数ヶ月苦しんだ機能追加ができあがったのではなく，いくつかのバグフィックスを施したのが今回の内容。S2Wicketを使ってくれているNAGASEYASUHiTOさんからのフィードバックを元に，不具合修正を行った。
[JIRA - S2Wicket] バージョン1.2.1のChangeLog
１人でOSSを作っていると，なかなかテストや動作確認を完璧に行うことは難しく，叩いてくれる利用者がいてこそ品質の向上が図れる（残念ながらこれが現実）。そういう意味で，NAGASEYASUHiTOさんには感謝してもしきれない。パッチまで作成してくれた。ホントに，素晴らしい。
S2Wicketは，やはりS2Containerとの連携が高い信頼性で行われることがメインなタスク。キャッシュ機構などをまだ搭載していないため，改良の余地は十分に残っている。Spoonを使った新機能の実現も少々苦しんでいるため，本質的な点についてしばらくは修正を重ねていきたい。
アノテーションによってコンポーネント構築を目論んだ次期S2Wicketだが，いくつかエントリした通り，芳しくない結果に終わってしまった。助けてエントリをしてみるも，とてもありがたい「頑張ってください」エールはいくつか頂けたものの，具体的な解決策を得るまでに至らなかった。
もっと別の何かを閃くことができれば，忘れることができるだろう。しかし，思いついたことといえば，TwitterclipseだったりSearchclipseだったり。S2Wicketについては，未解決で終わった問題領域を悶々と試すだけの日々が続いている。アノテーション以外の手立てを思いついたわけでもなく，コンポーネント構築以外の新機能が発想できたわけでもない。
僕の中で，アノテーションは「実行時に解釈するもの」という考えが根底にある。もちろんバイトコードに落ちずにコンパイル時にのみ使用する目的もアノテーションにあることは知っている。ただ，そのためには何らかの解析ツールを作成して利用しなければならず，アノテーションの利便性というか，利用価値というか，そういったものが犠牲になる気がしてならなかった。
何はともあれ，
「abstractなクラスを型とするフィールドに対して，アノテーションを付与することによって何らかの実装を持つインスタンスを動的に生成してセットする」
という次期S2Wicketの命題，どうしたものか。。。
ここで一歩引いて考えると，問題発生のそもそもの原因は，サブクラスを動的クラス生成で何とか実現できないか，と考えたことである。本来静的なものなバイトコードを動的に生成することは，永続化機構によって大きな問題となることがわかった。その壁は，とてつもなく高いものだった。
結局のところ，壁はその1枚であり，動的バイトコード生成アプローチを捨てて，事前にバイトコードを準備できさえすれば問題は解決する。たったそれだけのこと。
事前にバイトコードを準備するためには，自動生成をしてしまえば良い。つまり，aptの出番である。アノテーションが記述されたソースコードをアノテーションプロセッサに処理させて，実装を持つabstractなコンポーネントクラスのサブクラスのソースコードを自動生成する。そのコードが他のコードと同等にコンパイルされてwarファイルに含まれれば，解決である。
ま，最初からそうすれば良いのはわかっていたことだが，アノテーションに対する僕の印象が，その選択肢を選択させづらくしていたということは，前述の通りだ。
aptはもちろんコマンドラインツールとして提供されているものだが，Eclipseにビルダーとして組み込んで，暗黙的にアノテーションプロセッサを走らせることができる。これをうまく使えば（ビルダーのプラグインを利用することが前提となってしまうが）先の次期S2Wicketの目的は達成されるのではないか，と今は考えるようになった。
「アノテーションプロセッサ作ってみたいだけちゃうんか」と思うことだろう。そう，その通り。
何もランタイム時の解決だけがEoDではない。ツールに頼ることもEoDなはずだ。自動生成アプローチは，それはそれで幅広い命題なので，いろいろ模索してみたい。
約2ヶ月間，Wicketをより使いやすくしようとチャレンジしてきたが，力及ばず断念することを判断した。
コンポーネントベース開発を採用しているWicketについて，コーディングの中心はコンポーネントの組み上げ処理であり，SwingやSWTなどのGUIアプリケーションと同じくらいの記述内容と記述量が求められる。コンポーネントの組み上げは「インスタンス生成」と「モデルとの関連付け」，そして「親コンポーネントへの登録」処理の連続であり，共通的に見える割には共通化が難しく，できあがったコードは非常に煩雑になる。
この問題を打開するために，コンポーネントやモデルのフィールド定義に独自のアノテーションを付加することで，上記の処理を共通の機構が肩代わりすることでコーディング量を減らし，さらにコードの定型化を図ることでIDEを作りやすくする，ということを考えた。それが「次期S2Wicketではこうなります Part2」エントリで紹介した「@WicketComponent」や「@WicketModel」アノテーションである。「@SeasarComponent」アノテーションによるS2Containerとの連係を実現するS2Wicketの拡張機能とすべく，実装を続けてきた。
ほとんどの実装は完成し，アノテーションの付加によるコンポーネント組み上げ処理の簡略化は実現できていた。しかし，超えられない壁が僕の行く手を阻んだ。
それは，「動的プロキシのシリアライズ」だ。
Wicketは，アプリケーションの状態を持ったコンポーネントツリーをHTTPセッションに格納することで，セッションレプリケーションが設定された複数アプリケーションサーバ環境による負荷分散にも対応することが可能なようになっている。つまり，Wicketのコンポーネントは全てSerializableでなければならない。
コンポーネントのもう一つの側面は，多くのコンポーネントがabstractなクラスであるということである。abstractなメソッドの多くはイベントハンドラであり，Wicketではコンポーネントを匿名クラスなどを使ってサブクラス化し，abstractなイベントハンドラメソッドを実装することでイベント処理をコーディングするスタイルとなっている。SwingやSWTのようなイベントリスナータイプなコーディングではないため，原則コンポーネントのサブクラスを作らなければイベント処理を与えることができない。
後者のサブクラス化問題は，アノテーションが付加されたフィールドの型を継承したクラスを動的プロキシ技術で実行時に生成することで解決できる。これにはCGLibやJavassistを使うことで実現を試みた。イベントハンドラメソッドの実装として，@WicketActionアノテーションに記述されたOGNL式を評価する，という処理をサブクラスに持たせることも実現できている。
そして，前者のシリアライズ問題，これが今のところ超えられない壁である。サブクラス化問題を動的プロキシ技術で解決したために，動的プロキシクラスのインスタンスをシリアライズ・デシリアライズしなければならなくなった。これは「動的プロキシをシリアライズする具体的方法」エントリで説明したような試行錯誤をすることで，一見ちゃんと実現できたように思えた。
しかし，動的プロキシ内で動的プロキシオブジェクトの参照が行われた場合に，シリアライズした代替オブジェクトがデシリアライズ時に状態を一切持っていない，という現象が発生し，5/2現在では，その解決策を見つけることができていない。シリアライズされたオブジェクトグラフのデシリアライズ時に，単純に考えればwriteReplace()メソッドで返した代替オブジェクトはreadResolve()メソッドによって全て元の形に戻って欲しかったのだが，代替オブジェクトのまま復元されることがあり，さらに代替オブジェクトに定義したフィールド値が全てnullという状態で得られるために，どうしようもない状況である。
Wicketでコンポーネントをシリアライズできないという制限は非常に問題（スケーラビリティが皆無となってしまう）であり，妥協はできない問題領域である。この壁を超えられる見込みが現状ほとんどない以上，一旦仕様や実装を１から見直しした方が良いという結論に達した（いかにも複数人で結論を出したような表現だが，僕１人）。
極々少数（限りなくゼロに近い）とは思うが，ちょっとでも期待してくれていた方には申し訳ない気持ちでいっぱいである。仕切り直しをして，新たなWicketの拡張仕様と実装を後日紹介したい。
はぁ，残念。ちなみに，S2Wicket開発終了！とか言ってるわけではないので，勘違いのないよう。。。
前のエントリで，S2Wicketの今後の方向性として，以下のコードを示した。
前回までの構想では，LinkコンポーネントのイベントハンドラとなるonClickLink()メソッドを実装する必要があった。上記の場合，イベントハンドラ内では，helloServiceオブジェクトのsay()メソッドを呼び出し，その結果をhelloModelオブジェクトのhelloプロパティにセットする，というだけの処理を行っている。何かを行う，という点ではメソッドを作成することは自然と言えば自然だが，イベント処理すらも宣言的に記述したくならないだろうか？
S2Wicketでは，Wicketコンポーネントのイベント発生時に行いたい処理を，さらに簡潔に記述できるようにする。
見ての通り，フィールド定義のみになる。その分，使用するアノテーションが派手になっている。
@WicketComponentアノテーションの中に，@WicketActionアノテーションを記述できるようにした。@WicketActionアノテーションは，method属性にイベントハンドラのメソッド名を，exp属性に実行したい処理をOGNL式で記述する。@WicketActionアノテーションを使用すれば，実行時にmethod属性で指定したメソッドが呼び出されたとき，S2Wicketはexp属性に書かれたOGNL式を評価する。
多くの場合，プレゼンテーション層で行う処理といえば，ビジネスロジック層の呼び出しとその結果の表示用モデルへのマッピングだろう。S2Wicketは，そのような単純なことを，単純な記述で可能にする。
さらに「Javaらしさが失われた」S2Wicket，あなたはどう感じるだろうか？ (^^;
Commusuke - こみゅすけ
178 | Unique Visitors |
