新S2Wicket仕様，断念
約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開発終了！とか言ってるわけではないので，勘違いのないよう。。。
